Windows default font glyphs are rendered wrong on some systems

Philip Race philip.race at oracle.com
Fri Dec 20 21:43:31 UTC 2024 

The OTF bug is about printing. Disregard that. It is a case where the 
printer font is not the same as the font used on screen.

I hear what you say but I can't imagine what code would add any value to 
a glyph id. There's no use case for that.
Glyph ids need to be obtained by mapping via the font cmap. They are 
just an opaque value you then use to then
map into a table to get the image/outline.
You can't assume ANYTHING about the relationship between glyph ids.
Glyph ID for 'A' could be 23 .. id for 'B' could be 17 .. etc

-phil.


On 12/20/24 1:34 PM, Christopher Schnick wrote:
>
> I'm not a font wizard, the only a consistent thing about this issue is 
> that the glyph indices are always off by 2. The linked otf bug tracker 
> issue has that same issue, and that is using a completely different font.
>
> If I had to debug this, I would probably think of something where some 
> rare condition is true for the affected systems where some part of the 
> code does a +1 on the glyph index to adjust for something but should 
> instead do a -1. And since that condition seems to be very rare, 
> normal testing doesn't catch that.
>
> On 20/12/2024 22:24, Philip Race wrote:
>> There's some hard-coding of names to files in WindowsFontMap.java
>> Maybe that's part of it, but its very much a guess.
>> It would be interesting to try a build which excludes using that pure 
>> "optimization"
>>
>> -phil.
>>
>>
>> On 12/20/24 1:12 PM, Philip Race wrote:
>>> That just looks like prism.verbose output
>>> I see someone suggested prism.debugfonts but I don't see that any 
>>> results were ever provided.
>>>
>>> -phil.
>>>
>>>
>>> On 12/20/24 1:08 PM, Christopher Schnick wrote:
>>>>
>>>> Hey Phil,
>>>>
>>>> the linked GitHub comment has debugfonts output hidden in the 
>>>> comment. It looks like this:
>>>>
>>>> Prism pipeline init order: d3d sw
>>>> Using Double Precision Marlin Rasterizer
>>>> Using dirty region optimizations
>>>> Not using texture mask for primitives
>>>> Not forcing power of 2 sizes for textures
>>>> Using hardware CLAMP_TO_ZERO mode
>>>> Opting in for HiDPI pixel scaling
>>>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline
>>>> Loading D3D native library ...
>>>>         succeeded.
>>>> D3DPipelineManager: Created D3D9Ex device
>>>> Direct3D initialization succeeded
>>>> (X) Got class = class com.sun.prism.d3d.D3DPipeline
>>>> Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline
>>>> Maximum supported texture size: 16384
>>>> Maximum texture size clamped to 4096
>>>> OS Information:
>>>>         Windows version 10.0 build 22631
>>>> D3D Driver Information:
>>>>         Intel(R) Iris(R) Xe Graphics
>>>>         \\.\DISPLAY1
>>>>         Driver igd10iumd64.dll, version 30.0.101.3118
>>>>         Pixel Shader version 3.0
>>>>         Device : ven_8086, dev_46A8, subsys_00631414
>>>>         Max Multisamples supported: 4
>>>>  vsync: true vpipe: true
>>>> Loading FontFactory com.sun.javafx.font.directwrite.DWFactory
>>>> Subpixel: enabled
>>>> No match for name null in C:\WINDOWS\Fonts\segoeui.ttf
>>>> No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf
>>>> new alphas with length = 16384
>>>> new alphas with length = 20480
>>>> new alphas with length = 61440
>>>>
>>>> The comment also contains information about the system and fonts.
>>>>
>>>> On 20/12/2024 22:02, Philip Race wrote:
>>>>> Very odd. Possibilities :
>>>>> - font mixup :  the glyph ID is for a different font.
>>>>> - cmap bug : the incorrect glyph ID is used for the codepoint.
>>>>> - the font is a unicode variable font something goes wrong as a 
>>>>> result - I doubt this one as the IDs should be the same.
>>>>> - something else  :-)
>>>>>
>>>>> Is the D3D pipeline being used ?
>>>>> What's the user locale as shown by windows ?
>>>>>
>>>>> To get some idea of what fonts are being used they could run with 
>>>>> -Dprism.debugfonts=true
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 12/20/24 12:48 PM, Christopher Schnick wrote:
>>>>>>
>>>>>> So as a follow-up to this, this is a general JavaFX issue and not 
>>>>>> related to a certain application. You can find references to this 
>>>>>> on reddit: 
>>>>>> https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ 
>>>>>> and on GitHub with some verbose and debugfonts output: 
>>>>>> https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 
>>>>>> . It also seems related to this issue: 
>>>>>> https://bugs.openjdk.org/browse/JDK-8242617
>>>>>>
>>>>>> On 04/12/2024 18:43, Christopher Schnick wrote:
>>>>>>>
>>>>>>> I'm not able to reproduce it, but some of my users are. If 
>>>>>>> anyone who knows the font renderer maybe wants additional 
>>>>>>> information or has some ideas on what the users can try to 
>>>>>>> either fix or diagnose the root cause, I can relay that request 
>>>>>>> to them.
>>>>>>>
>>>>>>> I can ask them to try other JavaFX applications, but either way 
>>>>>>> how that goes, it doesn't show the cause.
>>>>>>>
>>>>>>> On 04/12/2024 18:37, Andy Goryachev wrote:
>>>>>>>>
>>>>>>>> I might suggest trying to run some other JavaFX application 
>>>>>>>> using the same setup.  Or better yet, if you can come up with a 
>>>>>>>> short reproducer, please file a bug.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> -andy
>>>>>>>>
>>>>>>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
>>>>>>>> Andy Goryachev <andy.goryachev at oracle.com>
>>>>>>>> *Date: *Wednesday, December 4, 2024 at 09:20
>>>>>>>> *To: *Christopher Schnick <crschnick at xpipe.io>, 
>>>>>>>> openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>>>>>>> *Subject: *Re: Windows default font glyphs are rendered wrong 
>>>>>>>> on some systems
>>>>>>>>
>>>>>>>> I've never seen this...  what is the font that causes the issue?
>>>>>>>>
>>>>>>>> -andy
>>>>>>>>
>>>>>>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
>>>>>>>> Christopher Schnick <crschnick at xpipe.io>
>>>>>>>> *Date: *Monday, November 25, 2024 at 02:44
>>>>>>>> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>>>>>>> *Subject: *Windows default font glyphs are rendered wrong on 
>>>>>>>> some systems
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> for some of our users, the font glyphs of the default Windows 
>>>>>>>> font are wrong by an offset of +2. E.g. the letter D is 
>>>>>>>> rendered as F, the symbol - is rendered as /, and so on ... 
>>>>>>>> However, the glyph spacings and kernings are using the correct 
>>>>>>>> values for the original letter, only the actual glyph itself is 
>>>>>>>> wrong. This is happening on the latest 24-ea build on Windows 
>>>>>>>> 11, but also occurred on version 21 a while ago. I wasn't able 
>>>>>>>> to reproduce it myself, only some users were.
>>>>>>>>
>>>>>>>> This has happened now for multiple users of our application, so 
>>>>>>>> I figured to report it (Didn't find this in the bug tracker).
>>>>>>>>
>>>>>>>> Here is there issue, next to how it should look like:
>>>>>>>>
>>>>>>>> (It is in danish because the user played around with the 
>>>>>>>> language settings to troubleshoot)
>>>>>>>>
>>>>>>>> There was no explicit -fx-font set, so the application uses the 
>>>>>>>> default one. When the users change to using -fx-font: Roboto, 
>>>>>>>> which is bundled with our application, the glyphs are rendered 
>>>>>>>> normally. So this issue is specific to certain fonts.
>>>>>>>>
>>>>>>>> If there's any additional information required, I can relay 
>>>>>>>> that request to our affected users.
>>>>>>>>
>>>>>>>>
>>>>>>>> Best
>>>>>>>> Christopher Schnick
>>>>>>>>
>>>>>>>> (I resent this mail as it got stuck in the moderation queue for 
>>>>>>>> being too big due to me accidentally pasting the screenshot as 
>>>>>>>> a .bmp)
>>>>>>>>
>>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241220/e272822a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s.png
Type: image/png
Size: 81374 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241220/e272822a/s-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ls6xRvPGaI1BL10B.png
Type: image/png
Size: 69609 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20241220/e272822a/Ls6xRvPGaI1BL10B-0001.png>

More information about the openjfx-dev mailing list