Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#71300 - [jre-openjdk] broken text rendering / font dependencies

Attached to Project: Arch Linux
Opened by ux (ubitux) - Saturday, 19 June 2021, 17:23 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Thursday, 14 October 2021, 21:53 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Since at least OpenJDK 15, the text rendering seems to have gotten even worse than before.

Attached is a 50 lines .java test sample (run it with `javac && java BugText`).

`broken.png` is the output with the `noto-fonts` package installed (it actually seems to select while `ok.png` is the what we get without `noto-fonts` installed.

What differs between these outputs is the first line (plain style) which seems to use a mix of font: in particular, it seems to fallback on /usr/share/fonts/noto/NotoSansDevanagariUI-Thin.ttf for the digits (and maybe parenthesis) and it's using a bold while it shouldn't.

I'm ignoring for now the glitches on the 2nd line (M and N in particular), or the broken bold for many characters on the last line (the '1', and a few caps). But it is important to note that on Debian (Sid) none of these issues is present and it actually renders great on all lines. This makes me believe there is a font mis-configuration somewhere in the distribution/environment.

This is reproducible with OpenJDK 15 and 16, but not reproducible with OpenJDK 11 (still ugly but not broken).

In practice, this impacts at least Ghidra (see `ghidra.png`) or random app such as StyledPad (`java -jar /usr/lib/jvm/java-16-openjdk/demo/jfc/Stylepad/Stylepad.jar` -- see styledpad.png where "f00b4r" is written and the bold disabled).
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Thursday, 14 October 2021, 21:53 GMT
Reason for closing:  Upstream
Additional comments about closing:  2021-06-23: A task closure has been requested. Reason for request: Upstream issue
Comment by ux (ubitux) - Saturday, 19 June 2021, 17:26 GMT
Here is a screenshot on Debian.
Comment by Levente Polyak (anthraxx) - Sunday, 20 June 2021, 19:19 GMT
Don't see how this is a java packaging issue though. For me the fonts look crisp and sharp without gliches. I expect you need to do some font setup wizardry
If it turns out to be a jdk issue, you will need to create an upstream ticket to sort this out.
Comment by ux (ubitux) - Sunday, 20 June 2021, 23:03 GMT
I think It's related to java packaging because depending on the set of fonts installed java can be broken or not. Do you have ttf-dejavu installed? Same question with noto-fonts. If I drop ttf-dejavu from my system, it's somehow much better. Same with dropping noto-fonts.
Comment by ux (ubitux) - Wednesday, 23 June 2021, 10:04 GMT Comment by ux (ubitux) - Wednesday, 23 June 2021, 22:13 GMT
BTW, I confirmed that the regression was introduced by fontconfig in 0f9040406cae2b3c574110acd925867c4a987a37. See for more information.