[OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows

Tue May 14 11:46:38 UTC 2019

Hello,

> I'm speculating here, but perhaps the issue is that glyphs are being
positioned using Freetype while the actual glyph rendering is using GDI,
and there is a disagreement between the two systems re: kerning?
> The issue does seem to be limited to the kerning between glyphs and not
the actual rendering of glyphs themselves.

That's true. On Windows, LCD-antialiased glyphs are generated via GDI, but
glyph advances are taken from FreeType. Rendering in newer FreeType seems
to differ more from GDI rendering, so the result started looking worse.
We've fixed this problem in JetBrains Runtime by keeping GDI-provided
advances (for non-fractional-metrics case). If it's a sensible approach
(I'm not sure I understand why advances from FreeType were used in the
first place), I can prepare corresponding patch for inclusion in OpenJDK.

On Mon, Apr 29, 2019 at 5:01 AM Peter Harvey <harvey at actenum.com> wrote:

>
>
> On Sun, Apr 28, 2019 at 1:05 PM Phil Race <philip.race at oracle.com> wrote:
>
>> One thing to add is that Swing on Windows will use LCD text in all cases
>> I can think of and that is rendered by Windows/GDI not free type.
>> Line and glyph spacing may still be affected (come from freetype) but not
>> the glyph image itself.
>> So it would have to be some custom rendering in another mode using 2D
>> directly to get freetype glyph images in b&w or grayscale.
>>
>
> I'm speculating here, but perhaps the issue is that glyphs are being
> positioned using Freetype while the actual glyph rendering is using GDI,
> and there is a disagreement between the two systems re: kerning? The issue
> does seem to be limited to the kerning between glyphs and not the actual
> rendering of glyphs themselves.
>
>
> On Apr 28, 2019, at 10:14 AM, Philip Race <philip.race at oracle.com> wrote:
>>
>> On 4/28/19, 8:25 AM, Peter Harvey wrote:
>>
>> From what I can tell, Freetype 2.7 contained a change in hint processing
>> that led to poorer quality font rendering on Windows. Any OpenJDK
>> distribution using Freetype 2.7 or higher (ie. most distributions) will
>> have poorer quality font rendering on Windows. I may have found a solution
>> to this issue but I am unable to add comments to the relevant bugs:
>>
>>    https://bugs.openjdk.java.net/browse/JDK-8217731
>>    https://bugs.openjdk.java.net/browse/JDK-8208377
>>    https://bugs.openjdk.java.net/browse/JDK-8214538
>>
>> As a temporary workaround, users of OpenJDK distributions can force
>> pre-2.7 font rendering by simply setting an environment variable:
>>
>>    FREETYPE_PROPERTIES=truetype:interpreter-version=35
>>
>> I've tested this workaround on OpenJDK distributions from Amazon, Oracle,
>> and AdoptOpenJDK.
>>
>>
>> Do you mean you specifically tested out exactly the issues & scenarios
>> listed in the above bug reports and found them all 100% reverted & cured ?
>> If not, please detail what exactly you see in each case when applying the
>> property vs previous JDKs.
>> What version of Windows did you test, and did you test anything other
>> than Windows ?
>>
>>
> I have only tested on Windows 10 Home 1803, with no font scaling enabled.
> My initial tests were performed using a desktop application, many OpenJDK
> distributions, and visually comparing the poor kerning when using Tahoma.
>
> I have now produced a screenshot using sample text and 12 different
> OpenJDK distributions. I have highlighted the font kerning issues in a
> zoomed/cropped image:
>   https://imgur.com/a/a9R0oBi
>   https://imgur.com/a/BAZNJg6
>
> Each window in the above screenshot represents a different OpenJDK
> distribution running on my Windows environment with or without the
> FREETYPE_PROPERTIES environment variable specified:
>
>    - the sample text is "Activity dwedwedwedwe" though kerning issues can
>    be seen throughout most text within the dialog
>    - the first JLabels use the default font, while the last three JLabels
>    use 10pt, 11pt, and 12pt Tahoma
>    - the left-side windows do not have FREETYPE_PROPERTIES specified
>    - the right-side windows have FREETYPE_PROPERTIES specified
>    - the first 8 OpenJDK distributions all show kerning issues which are
>    fixed by setting FREETYPE_PROPERTIES
>    - the last 4 OpenJDK distributions don't show kerning issues at all
>    and are not affected by  setting FREETYPE_PROPERTIES
>
> As shown in the screenshot, setting the FREETYPE_PROPERTIES environment
> variable appears to fix the kinds of kerning issues described in
> JDK-8217731 and JDK-8214538. I have not checked if it fixes the line
> spacing issue described in JDK-8217731, but I doubt it. JDK-8208377 looks
> to be unrelated and that is my mistake.
>
> If you need to replicate the test, the code is below:
>
> import javax.swing.BorderFactory;
> import javax.swing.BoxLayout;
> import javax.swing.JFrame;
> import javax.swing.JLabel;
> import javax.swing.JPanel;
> import java.awt.Font;
>
> public class TestSwingTexts {
> public static void main(String[] args) {
> JFrame frame = new JFrame();
>
> JPanel panel = new JPanel();
> panel.setLayout(new BoxLayout(panel, BoxLayout.Y_AXIS));
>
> System.out.println(System.getProperties());
>
> JLabel vendor = new JLabel(
> System.getProperty("java.vm.vendor") + " " +
> System.getProperty("java.runtime.version") + " "
> + (System.getenv("FREETYPE_PROPERTIES") == null ? "without fix" : "with
> fix"));
>
> JLabel label1 = new JLabel("Activity its dwedwedwedwe");
> JLabel label2 = new JLabel("Activity its dwedwedwedwe");
> JLabel label3 = new JLabel("Activity its dwedwedwedwe");
> JLabel label4 = new JLabel("Activity its dwedwedwedwe");
> label2.setFont(new Font("Tahoma", Font.PLAIN, 10));
> label3.setFont(new Font("Tahoma", Font.PLAIN, 11));
> label4.setFont(new Font("Tahoma", Font.PLAIN, 12));
>
> panel.add(vendor);
> panel.add(label1);
> panel.add(label2);
> panel.add(label3);
> panel.add(label4);
> panel.setBorder(BorderFactory.createEmptyBorder(5, 5, 5, 5));
> frame.add(panel);
>
> frame.pack();
> frame.setLocationRelativeTo(null);
> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> frame.setVisible(true);
> }
> }
>
>
> Note that AdoptOpenJDK's distribution for Java 8 didn't require the
>> workaround because it appears to be using Freetype 2.5.3. A quick Google
>> for "truetype:interpreter-version=35" shows plenty of people in other
>> open-source communities (eg. Wine, Fedora) which encourage this workaround
>> for other software.
>>
>> A more permanent solution would be to change the default build process
>> for OpenJDK to set "truetype:interpreter-version=35" as the default when
>> compiling Freetype.
>>
>>
>> I have read freetype notes on this and it isn't clear whether we want to
>> go against what it does by default.
>> And in any case, Oracle JDK switched from T2K to freetype in 11 so there
>> can be differences due to that too.
>>
>> It may be that Windows is the only platform on which this reversion is a
>> good idea.
>> And in any case, on Linux + Solaris (not sure about other Unix-like
>> distros) OpenJDK
>> currently uses the system freetype so a JDK build change for freetype
>> wouldn't help.
>>
>>
> After reading a little more, I would suggest keeping the latest Freetype
> but compiling it using truetype:interpreter-version=35 to fix the kerning
> issues.
>
> Regards,
> Peter.
>
>

Best regards,
Dmitry Batrak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20190514/8be7898e/attachment-0001.html>