8219641: java/awt/font/Rotate/RotatedTextTest.java fails on Linux: Test failed for angle 15.0

[ArnoZeller]

The test fails on newer SLES versions that have RobotoSlab-Regular.ttf as default font. I suggest to try getting a DejaVu font as default on Linux because it is known to work without issues.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8219641: java/awt/font/Rotate/RotatedTextTest.java fails on Linux: Test failed for angle 15.0 (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15780/head:pull/15780
$ git checkout pull/15780

Update a local copy of the PR:
$ git checkout pull/15780
$ git pull https://git.openjdk.org/jdk.git pull/15780/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15780

View PR using the GUI difftool:
$ git pr show -t 15780

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15780.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back azeller! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@ArnoZeller The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (ccda0253)

[RealCLanger]

To me this looks pragmatic. I made a few suggestions for cleanup of the coding.

[RealCLanger]

Suggested change

	String os = System.getProperty("os.name").toLowerCase();
	boolean isLinux = System.getProperty("os.name").toLowerCase().startsWith("linux");
	Font fnt = isLinux ? new Font("DejaVu Serif", Font.PLAIN, 12) : new Font(Font.SERIF, Font.PLAIN, 12);

[RealCLanger]

Suggested change

	System.out.println(fnt);
	System.out.println("Using font: " + fnt);

[MBaesken]

You could use Platform.isLinux() .

[aivanov-jdk]

What is the root cause for the test failing with RobotoSlab-Regular.ttf?

It doesn't look right to me to change the font without understanding why the test fails with it. Is it a bug in the JDK? Is it a bug in test?

[MBaesken]

Hi Alexey, there is a bit of discussion here https://bugs.openjdk.org/browse/JDK-8219641
see the older comment ....

The RobotoSlab-Regular.ttf: "Roboto Slab" "Regular" from /usr/share/fonts/truetype/RobotoSlab-Regular.ttf is indeed causing the trouble.
fc-match shows this one as the preferred font for serif so probably thats why it shows up too when tracing is enabled.

user@sles15-x86_64_machine:> fc-match serif
RobotoSlab-Regular.ttf: "Roboto Slab" "Regular"

The test RotatedTextTest shows a small width difference in the rotation (but the test assumes the width difference is 0 and fails). I wonder if the test can really assume a width difference 0 , is this really what we can expect for all fonts on the various distros ?
I worked around the issue by changing the defaults stored in $HOME/.java/fonts//fcinfo-1-.... where I replaced Roboto Slab by the good old
DejaVu Serif fileName=/usr/share/fonts/truetype/DejaVuSerif.ttf ; then the width difference is gone and the test passes .
Is there a better way to change the font than adjusting $HOME/.java/fonts//fcinfo-1-.... ?
And can we really assume a width-difference == 0 in the rotation process ?

[aivanov-jdk]

The test RotatedTextTest shows a small width difference in the rotation (but the test assumes the width difference is 0 and fails). I wonder if the test can really assume a width difference 0 , is this really what we can expect for all fonts on the various distros ?

Perhaps, the test should allow for some small differences in widths. It could still be a bug in JDK where rounding isn't handled precisely.

By choosing a different default font we may mask a problem.

[prrace]

The bug report has "Angle: 15, width diff: -4"
Over the length of the string "The quick brown fox jumps over the lazy dog" that could be the occasional rounding difference
and there is a comment in the bug report claiming (suggesting?) that's the issue.
It is a bit tricky to know what error to allow because if you have a case where all the glyphs are rounded differently it could be 1 pixel per glyph .. much more than "4".
Even Deja Vu Sans might reproduce this given the right (or wrong) string.

The JDK rounding code has been stable for a while now and changing that could cause problems elsewhere.
And I'm not sure we can 100% guarantee no difference in all cases, because the rasteriser has a say in this too, and
likely that's where the difference is coming from here and the rounding then exacerbates the difference.

Drawing and measuring the string using fractional metrics and floating point with a tolerance might have been a
better bet here but that's more surgery on the test.

[ArnoZeller]

The bug report has "Angle: 15, width diff: -4" Over the length of the string "The quick brown fox jumps over the lazy dog" that could be the occasional rounding difference and there is a comment in the bug report claiming (suggesting?) that's the issue. It is a bit tricky to know what error to allow because if you have a case where all the glyphs are rounded differently it could be 1 pixel per glyph .. much more than "4". Even Deja Vu Sans might reproduce this given the right (or wrong) string.

So, I guess it would be ok to change the test to allow a small difference? The question then is "What is valid allowed difference?"
Do you think 5 could be fine? Up to now we only have seen 4 :-)?

[aivanov-jdk]

The bug report has "Angle: 15, width diff: -4" Over the length of the string "The quick brown fox jumps over the lazy dog" that could be the occasional rounding difference and there is a comment in the bug report claiming (suggesting?) that's the issue. It is a bit tricky to know what error to allow because if you have a case where all the glyphs are rounded differently it could be 1 pixel per glyph .. much more than "4". Even Deja Vu Sans might reproduce this given the right (or wrong) string.

So, I guess it would be ok to change the test to allow a small difference? The question then is "What is valid allowed difference?" Do you think 5 could be fine? Up to now we only have seen 4 :-)?

It looks 5 wouldn't be enough.

On Ubuntu, using the Roboto font, I get width diff: -13. With the Roboto Slab font, the test does not fail me. I attached the images and logs to the JBS issue.

[prrace]

Sounds like (1) we don't have any reasonable idea of a small error to allow and (2) we don't know that this test isn't just getting lucky with the fonts for which it does pass. So I am not comfortable with either solution.

And looking at the image we have a badly wandering baseline which seems like rounding (from somewhere) is partly to blame.

I'd really like to dig into the specifics of what's happening here for the advances of the code points here - and see what they are before truncation (ie what is the 26.6 value) as well as afterwards. I don't know what we'll find but I'd like to make a more informed decision.

[ArnoZeller]

I'd really like to dig into the specifics of what's happening here for the advances of the code points here - and see what they are before truncation (ie what is the 26.6 value) as well as afterwards. I don't know what we'll find but I'd like to make a more informed decision.

That sounds reasonable to me - I suspected it to be just an issue with some fonts and small differences, but it now looks like a bigger thing. I will close this PR.