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 <har...@actenum.com
<mailto:har...@actenum.com>> wrote:
On Sun, Apr 28, 2019 at 1:05 PM Phil Race <philip.r...@oracle.com
<mailto: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 <mailto: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.
Best regards,
Dmitry Batrak
