On Sun, Apr 28, 2019 at 1:05 PM Phil Race <philip.r...@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.r...@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.
