-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8344637: Fix Page8 of manual test java/awt/print/PrinterJob/PrintTextTest.java on Linux and Windows #21980
base: master
Are you sure you want to change the base?
Conversation
👋 Welcome back gredler! A progress list of the required criteria for merging this PR into |
❗ This change is not yet ready to be integrated. |
Webrevs
|
@honkar-jdk This is the followup to PR #21716 discussed last week. Do you have time to review and possibly test on Windows or mac? The change looks good for me on Linux. |
Sure. I can check it on windows & macOS and get back to you. |
@gredler Tested on windows with print to pdf option. I noticed that the "G..y..h..." line is still being printed above instead of below as seen in the following screenshot. (Left one - without changes, center window - test window, Right one- with the fix). If you could attach a similar screenshot of your testing on linux, it would be easier to review. |
@honkar-jdk Interesting, it looks like this fixes Linux then, but not Windows (although the code change is in the shared We may need to create a separate bug in the bug tracker just for Linux page 8 and this PR, since it looks like there are still other issues to be fixed in JDK-8148334. Linux screenshot: |
@gredler MacOS looks different. There seems to be some clipping issues or bound issues when printing. In fact, I don't even see the |
@DamonGuy Brilliant, thanks for the check. This feels like it might be drawing offscreen because of incorrectly-combined transforms, like what was fixed in PR #20993 (but this would be somewhere in the Mac-specific code). @honkar-jdk I was able to dig up an old Windows laptop, and have confirmed that the page 8 issue on Windows is caused by two regressions introduced over the past decade but not caught because this is a manual test, not an automated test... I'm going to see if I can't get this test passing on both Linux and Windows. Keep an eye out for additional commits to this PR. |
@gredler Tested on windows with the latest fix. The portrait looks good but looks like the fix causes more issues in landscape mode. I'll require some time to go through the source code changes when I get a chance. Looks like you might be in the process of adding few more changes for Windows issue. Let me know once the PR is ready. Portrait Landscape |
@honkar-jdk OK, I think this PR is ready for another review on Windows. The issue you highlighted in your last comment was caused by a partial fix to the JDK-8132890 regression (which had obviously removed the font rotation component, but had less-obviously also removed the device transform rotation component). The goal is to completely fix this test on Windows and Linux, so I've updated the problem list to flag only macOS as problematic. Will we need a separate bug in the issue tracker, since this PR will not fix the macOS parts of JDK-8148334? I'm not sure whether PRs are allowed to partially fix issues (when they represent more than one bug), or whether they are expected to fully fix whatever issue they reference. @prrace This is related to two bugs that you worked on in the past: JDK-8132890 and JDK-8029204. It has been a few years, but it would be good to get your review on this as well, if you have the time. In particular, it feels like we stopped using most of the device transform in some parts of the JDK-8132890 changes (e.g. glyph position calculation), and now we're re-adding the rotation component, and I wonder if there are other parts of the device transform that we are missing, and/or whether it would be easier to go back to using the device transform in the glyph position calculation. (The code seems to work as-is, I'm just wondering if it's more complex than is necessary.) Summary of changes:
|
That's correct. I think it is better to create a new JBS bug and use the new JBS ID for this PR than using JDK-8148334. I can create a new JBS issue on your behalf.
A PR can have fix that focuses on specific issue and separate PRs can be created to address other issues. So in this case it seems reasonable to have a PR for Windows and Linux fix and create a separate one for macOS. |
@honkar-jdk I just got access to JBS today, so that's not a problem. I've created JDK-8344637 to track just the Linux and Windows fixes in this PR (scoping out macOS for now). Have you had a chance to review on Windows? |
Yes, following are the screenshots of Page8 on Windows. Both portrait and landscape look good now although I haven't looked at the other pages in detail (to verify the fix works in all cases and does not produce any side-effects/regressions). (Right-hand side page => with Fix) |
@gredler The PR title needs to be updated to the latest JBS title ( I added Page8 to be more specific). |
@honkar-jdk OK, I've updated the title. I've checked output on both Windows and Linux and I don't think there are any other issues with this test on either platform (on any page). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on windows, Pg#8 looks good. I did not notice any regressions on other pages with the fix.
Font font2 = font; | ||
if (font.isTransformed()) { | ||
AffineTransform t = font.getTransform(); | ||
if ((t.getType() & AffineTransform.TYPE_TRANSLATION) != 0) { | ||
t.setTransform(t.getScaleX(), t.getShearY(), t.getShearX(), t.getScaleY(), 0, 0); | ||
font2 = font.deriveFont(t); | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix to PathGraphics.java looks good.
A new font var is used to copy over all the transforms except translation from the original font object and use new font reference in drawString(). The translation transform is skipped since the drawString takes care of x and y positions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right, this avoids doubling of the text start position coordinates, since the glyph positions which we are about to use already include this translation component. Let me know if you see anything that should be changed, or if I can mark this conversation as resolved.
advanceTransform.rotate(devangle); // radians | ||
advanceTransform.rotate(iangle * Math.PI / 1800.0); // 1/10 degrees -> radians |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix to WPathGraphics.java is a little more intricate and certainly requires a more expert review from @prrace.
Was devangle fix added for the landscape issue observed on Pg#8 ?
A earlier comment mentions that device space rotation must not be added.
GDI advances must not include device space rotation.
See earlier comment in printGlyphVector() for details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The two angles (iangle
+ devangle
) need to be used to fix the Windows page 8 printed "GlyphVector with position adjustments" test case, here's what it looks like without these rotation angles (left side is printed and incorrect, right side is not printed and is correct):
Adding iangle
alone looks OK in the printed portrait page, but not in the printed landscape page (devangle
is zero and therefore makes no difference when printing in portrait mode, but not so for landscape mode).
This restores the rotation transformation that was being applied prior to commit 5c26723 (prior to this commit the advance transform was a copy of the device transform, with the extra iangle
rotation applied, meaning that both the device rotation and the iangle
rotation were included).
/reviewers 2 reviewer |
@honkar-jdk |
This PR fixes the issue identified in JDK-8148334 in screenshots
Page8_landscape.JPG
andPage8_portrait.JPG
.It does not address
mac_Page1.png
ormac_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 ofPrintTextTest
), 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 bydrawString(...)
via the font. The proposed fix is to providedrawString(...)
a font without any translation transform.Testing looks good on Linux, but needs to be done on Mac and Windows.
Progress
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/21980/head:pull/21980
$ git checkout pull/21980
Update a local copy of the PR:
$ git checkout pull/21980
$ git pull https://git.openjdk.org/jdk.git pull/21980/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 21980
View PR using the GUI difftool:
$ git pr show -t 21980
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/21980.diff
Using Webrev
Link to Webrev Comment