On Wed, 1 Apr 2026 10:45:37 GMT, Prasanta Sadhukhan <[email protected]> wrote:
>> `PrintTextTest` is currently failing for macOS. The biggest remaining issue >> is that the printed Page 8 does not match the on-screen Page 8, because a >> font with an `AffineTransform` with translation and rotation is used, and >> the translation component is not treated correctly during printing. >> >> This issue is an offshoot of >> [JDK-8148334](https://bugs.openjdk.org/browse/JDK-8148334), which tracks >> success of this test case across all platforms. >> >> There are two main aspects to this bug. First, if the font contains a >> transform with a translation component, `SunGraphics2D.checkFontInfo(...)` >> extracts the translation component into the `FontInfo` and then clears the >> translation component from the transform. However, the way it was being >> cleared does not work when there is a rotation component. Second, the three >> drawing methods in `CTextPipe` were ignoring this translation component. >> Both aspects are fixed here. >> >> I've also fixed a small typo in the JavaDoc for >> `AffineTransform.getMatrix(...)` which confused me during the debugging of >> this issue. >> >> I've tested locally on Windows, Linux and mac, but `SunGraphics2D` is shared >> across all platforms, and that part of the change could have some subtle >> interactions with other parts of the code that my tests haven't caught, so >> we may want a full CI test run prior to approval. >> >> After this fix, it looks like there is only one smaller issue with >> `PrintTextTest` remaining on macOS: on pages 3 and 4, the physical font >> selected by the test (at least on my machine -- it's just looping through >> available fonts and selecting the first one available, so the selected >> physical font may be different on other machines) draws with different char >> advances vs the expected char advances, so the lines printed under the text >> are longer than the text. This seems to be font-specific, as some physical >> fonts look fine and others don't, but will require more research. > > src/java.desktop/share/classes/java/awt/geom/AffineTransform.java line 1140: > >> 1138: * { m00 m10 m01 m11 m02 m12 }. >> 1139: * An array of 4 doubles can also be specified, in which case only >> the >> 1140: * first four elements representing the non-translation > > will this change not require a CSR as its public API? I don't think so, based on the [CSR FAQ](https://wiki.openjdk.org/spaces/csr/pages/32342047/CSR+FAQs). I might be wrong though, I don't have a lot of CSR experience. > Q: If the text of the javadoc of a public exported API is changing, is a CSR > request needed? > > A: A CSR request is required if the specification of a public exported API. > Not all javadoc updates are specification changes. For example, typo fixes > and rephrasings that do not alter the semantics of the API in question do not > require CSR review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30244#discussion_r3021574881
