As a follow-up to this issue 2 years later, I figured out the cause now.
If you go to the font settings in Windows, remove the default Segoe UI
and install your own Segoe UI font (I downloaded it from a random site
for testing: https://www.cufonfonts.com/font/segoe-ui-4), then you will
get this issue with all the glyphs being offset by 2:
(Note that the bold text is correct as I did not replace that font variant)
This is the Windows default font and the custom font I replaced it with:
So I guess the indices for the font are not loaded from the actual font
file if it is marked as embedded if I understand the code. And the issue
is that some fonts are marked as embedded even when they are replaced
with custom versions? This should in theory happen for all fonts that
typically come with Windows, I presume at least, without having tested
others.
For reproduction, I used a VM to not mess up the system fonts somehow.
On 20/12/2024 22:53, Christopher Schnick wrote:
Yeah I am out of my element here, I can just add my thoughts.
Since the kerning / glyph spacing is using the correct glyph info (but
rendering the wrong glyph), this might be a pure display issue. You
can see that if you take a closer look at the screenshots, the glyphs
are aligned as if they were rendering the correct glyph. So it
definitely knows the correct cmap for the glyph info, it just uses the
wrong graphics.
About the printer issue, wouldn't that even be more peculiar if
installing and using some otf font would break the display (in this
case when printed) of another font? The issue states that installing
the otf font is causing that. If it was printing the otf font, then it
would be the same off-by-2 issue. If it uses a different font to
print, then the otf font is somehow still interfering with it because
without the otf font, this issue doesn't happen.
On 20/12/2024 22:43, Philip Race wrote:
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 <[email protected]> on behalf
of Andy Goryachev <[email protected]>
*Date: *Wednesday, December 4, 2024 at 09:20
*To: *Christopher Schnick <[email protected]>,
[email protected] <[email protected]>
*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 <[email protected]> on behalf
of Christopher Schnick <[email protected]>
*Date: *Monday, November 25, 2024 at 02:44
*To: *[email protected] <[email protected]>
*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)
