Windows default font glyphs are rendered wrong on some systems

Christopher Schnick crschnick at xpipe.io
Fri Dec 20 21:34:27 UTC 2024 

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/e8e3b6d0/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/e8e3b6d0/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/e8e3b6d0/Ls6xRvPGaI1BL10B-0001.png>

More information about the openjfx-dev mailing list