[OpenJDK 2D-Dev] Possible solution for font-rendering issues in Windows
Phil Race
philip.race at oracle.com
Tue May 14 15:58:33 UTC 2019
It was very deliberate that advances from the JDK's rasteriser was used
because many
applications were very sensitive to metrics. This was back in the T2K
days and it just
carried over to freetype. It worked out just fine with T2K but not so
much with freetype
I don't think I want to just take a patch which switches to GDI either,
so I wouldn't
bother preparing one. I need to take a big look at the whole picture
when I get time.
-phil
On 5/14/19 4:46 AM, Dmitry Batrak wrote:
> 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
> <mailto:harvey at actenum.com>> wrote:
>
>
>
> On Sun, Apr 28, 2019 at 1:05 PM Phil Race <philip.race at oracle.com
> <mailto: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 <mailto: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/054b177f/attachment-0001.html>
More information about the 2d-dev
mailing list