On 6/5/19 2:11 PM, Phil Race wrote:

It *can* make a difference and in fact we have a regression test
that now passes with this fix which tests different rendering modes.
Which test is it? Why  you didn't mark it with the bug id?
However that is not a direct test for this potential difference.
You cannot say that this change *must* make a difference, it
just does. Sometimes.

That's what we need to avoid regression again when fonts are updated. Font appearance directly affects user experience. Fortunately this happens not so often but we definitely need a test that will indicate such changes before the bug is reported externally like it recently happened. I thin everyone agrees that we should not repeat this omission once again.

--Semyon


-phil.

On 6/5/19 1:40 PM, semyon.sadet...@oracle.com wrote:
Can you clarify does the change affects font metrics?

I see that it is a sub-pixel difference for each single glyph but if a long line of text can accumulate a notable difference the reg test can be provided.

--Semyon

On 6/5/19 11:43 AM, Phil Race wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8217731
webrev: http://cr.openjdk.java.net/~prr/8217731/

This is intended to "help" but cannot completely cure, with
some of the rendering differences in JDK11 vs JDK 8.
In a typical Swing app on Windows using LCD rendering
it manifests as subtle adjustments in the spacing between glyphs.
There isn't an easy regression test for this, and it is subjective
as to how bad it was before and how much this improves it,
even if you were to accept that 8 is "better" .. and not just different ..

-phil.


Reply via email to