RFR: 8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows [v7]

[Phil Race]

On Wed, 20 Nov 2024 19:07:28 GMT, Daniel Gredler <dgredler at openjdk.org> wrote:

>> This PR fixes the issue identified in JDK-8148334 in screenshots `Page8_landscape.JPG` and `Page8_portrait.JPG`.
>> 
>> It does not address `mac_Page1.png` or `mac_Page8.png`, which I'm not even sure are still issues (I have no access to a Mac).
>> 
>> The method in question, `PathGraphics.printedSimpleGlyphVector(...)` is quite complex, with many special cases being handled in different ways. In this specific scenario (page 8 of `PrintTextTest`), all special case checks fail, and we fall through all the way to the final handling block, which draws the individual characters one by one. It looks like the problem is that the font transform translation is applied twice, once via the glyph positions, and again by `drawString(...)` via the font. The proposed fix is to provide `drawString(...)` a font without any translation transform.
>> 
>> Testing looks good on Linux, but needs to be done on Mac and Windows.
>
> Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add additional issue ID to PrintTextTest bug list

I've tested the fix on Mac, Linux and Windows.
It is painstaking comparing all the pages on-screen and off-screen to be sure not to overlook something.
I had to pause the test timer to review it all before the test timed out.

There are a couple of before and after things to note (ie pre-existing problems, which remain an issue)
Eg on Linux Page 3, "drawChars(char[]" prints as "drawChars(   char[]"
I don't know where the extra space came from.
but I should note I am viewing this in a Postscript viewer, not on a printer and it is the same before and after.

On windows, pages 12 / 13 - using the Japanese font - on screen uses embedded bitmaps so
the size doesn't scale smoothly line to line. It 'jumps' when the next bitmap size is selected.
The printing case size increases smoothly because bitmaps aren't used there.
This is a small, pre-existing anomaly and the instructions have a comment that text does not
scale linearly screen to printer, so that is not necessarily a bug and the on-screen case
is actually what you might want to change, but not at the cost of losing the bitmaps ..
But the difference is pretty extreme in this case. We may need to re-visit this.

macOS is still a problem.
Notably every page has an issue with the glyphvector positioning case being wildly wrong.
But again, pre-existing. I didn't see anything  get worse with this change.

So I'm approving the fix, although the *pre-existing* problems on windows and linux may mean
that some tester might consider the anomalies there worth a new bug report.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21980#pullrequestreview-2576742178