JDK-8214702 : Wrong text position for whitespaced string in printing Swing text
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u14,7,8,9,10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-12-03
  • Updated: 2020-02-18
  • Resolved: 2019-05-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 7 JDK 8 Other
11.0.5-oracleFixed 13 b24Fixed 14Fixed 7u241Fixed 8u231Fixed openjdk8u232Fixed
Description
PrinterJob.print() doesn't seem to calculate whitespaces correctly. 
A string beginning with multiple whitespaces is displayed properly in Swing 
component.  However, when printing, the start position of the line changes, 
according to the number of whitespaces.
Comments
Fix request (8u): Needed for parity with Oracle 8u231 == OpenJDK 8u232. Patch applies cleanly. Included test passes.
12-08-2019
Fix request (11u): Requesting backport of this fix for parity with Oracle 11.0.5. Patch applies cleanly. Will be regression tested in SAP's test system.
04-07-2019
The newest revision: webrev: http://cr.openjdk.java.net/~psadhukhan/8214702/webrev.3/ review: http://mail.openjdk.java.net/pipermail/swing-dev/2019-April/009580.html
17-04-2019
Going by the assumption that if there is a problem in text layout, it will affect other awt text rendering too, I tried to see if there is a problem in incorrect screenWidth. Proposed 3 patches to rectify screenWidth in SwingUtilities2.java as can be seen in http://mail.openjdk.java.net/pipermail /swing-dev/2019-February/009429.html but it was mentioned that the proposed fix might regress swing printing clip texts. It was suggested by Phil that "we need to look at breaking the text into the leading spaces + the rest of the trimmed string and using the screen advance of the leading spaces to position the rest of the justified text" but testing reveals that even without leading spaces, the printed output is not justified correctly (the screenshot of which can be seen in above mail archive). So, now it seems the problem lies entirely in awt text layout and it needs subject matter expertise of that area.
22-03-2019
Tested on jdk1.6.0_171 on windows10, I could see the alignment of the texts is not correct (attached print-output-jdk6.pdf) during printing compared to console display However, the alignment differs from jdk9b114 ((attached print-output-jdk9b114.pdf)) due to JDK-8076545:Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display which is still being observed even now in jdk12.
06-12-2018
Comment from submitter : ===== PrinterJob.print() doesn't seem to calculate whitespaces correctly. A string beginning with multiple whitespaces is displayed properly in Swing component. However, when printing, the start position of the line changes, according to the number of whitespaces. For example, it looks in Swing AAAA AAAABBBB AAAABBBBCCCC But, it looks in a printed document AAAA AAAABBBB AAAABBBBCCCC The issue is observed from 6u14 and above. I appears that it might be a regression from the fix of JDK-6760148: Certain fonts are not correctly soft wrapped when using JTextComponent.print(). The fix for JDK-6760148 was integrated into 6u14 and the underlying issue is not reproducible in JDK 6u13 and below. ==== Well .. PrinterJob.print() doesn't calculate white spaces .. this is more likely a bug in Swing if it is caused by JDK-6760148 I see there is supposed to be a test case. Someone needs to add it here.
05-12-2018
Says above it is from 6u14 (at least) on so I don't think we are calling that a regression in the days when the current shipping release is 11. Where's the test case ? Statements are not sufficient.
05-12-2018