Understood. I did run across a comment in the bug tracker for a different bug, JDK-8148334, [1] that seems to indicate that `test/jdk/java/awt/print/PrinterJob/PrintTextTest.java` might be able to replicate the issue. I'd like to try reverting the JDK-8145901 fix [2] locally and running that test to check, but I'm having issues running the test. It uses `@run main/manual=yesno PrintTextTest`, which based on JDK-8274456 [3] and corresponding commit [4] it looks like may no longer be supported? However, the jtreg FAQ [5] does not mention any deprecation of `yesno`. Will I need to convert this test to `@run main/manual PrintTextTest`, the pattern which most recent tests seem to use?
Here's what I'm seeing right now: > ../jtreg-7.4/bin/jtreg -jdk:build/linux-x86_64-server-release/images/jdk/ -w > build/jtreg/work -r build/jtreg/report -verbose:error -manual > test/jdk/java/awt/print/PrinterJob/PrintTextTest.java > -------------------------------------------------- > TEST: java/awt/print/PrinterJob/PrintTextTest.java > TEST JDK: > /home/daniel/openjdk-src/jdk/build/linux-x86_64-server-release/images/jdk > > TEST RESULT: Error. Parse Exception: Arguments to `manual' option not > supported: yesno > -------------------------------------------------- > Test results: error: 1 > Report written to > /home/daniel/openjdk-src/jdk/build/jtreg/report/html/report.html > Results written to /home/daniel/openjdk-src/jdk/build/jtreg/work > Error: Some tests failed or other problems occurred. --- [1] https://bugs.openjdk.org/browse/JDK-8148334 [2] https://github.com/openjdk/jdk/commit/5935292ae022e970bd4075de4d704719f3b05575 [3] https://bugs.openjdk.org/browse/JDK-8274456 [4] https://github.com/openjdk/jdk/commit/d57fb6f684eac5a7e68842dcf3284309e3867521 [5] https://openjdk.org/jtreg/faq.html --- On Wed, Oct 9, 2024 at 5:48 PM Philip Race <[email protected]> wrote: > > That test was from an internal SQE test suite, and there's nothing I > have to open source. > But it was reproducible with just things like printing a JTable and > unrelated to Thai/complex text. > It is a painful issue where Swing needs to be told to layout text at > printer resolution when "printing the UI contents". > If you don't, then glyphs overlap, even for simple Latin "abc" text. Or > if they don't overlap the string is clipped. > So unrelated. > > -phil > > On 10/9/24 6:09 AM, Daniel Gredler wrote: > > Hi Phil, > > > > I've noticed that quite a few AWT / client lib tests have been open > > sourced over the past few weeks. That's great for those of us trying > > to contribute from outside of Oracle, so thanks for that! > > > > I wanted to follow up on this Thai rendering bug and check to see > > whether the tests for JDK-8145901 have been (or will be) open sourced > > as part of this effort. I'd still like to try to fix this bug at some > > point, and a fix would require less coordination if those tests were > > available publicly. > > > > Thanks! > > > > Daniel > > > > > > > > > > On Wed, Sep 8, 2021 at 8:39 PM Philip Race <[email protected]> wrote: > >> JDK-8145901 isn't accessible because some confidential information is in > >> the description and attachments .. > >> and in fact it was JCK failure so we need to be careful not to regress that > >> But I guess you found the changeset for it. > >> > >> The problem we were trying to solve there was > >> === > >> The font interface supplied to harfbuzz is setting the point size (scale) > >> based on the device size font. When printing, this is scaled from the > >> user size font by (typically) around 4X. > >> So when performing a kerning adjustment the affected glyphs are > >> moved accordingly. > >> > >> But advances are being provided in user space and so the kerning > >> adjustment is too great relative to the advances. > >> ==== > >> > >> I'd need to spend some time refreshing my memory on this 5 yr old issue > >> so I can't say offhand that what you propose won't need fix up elsewhere. > >> > >> But I can say that testing this will need to do on screen rendering as > >> well as > >> printing of kerned and ligatured text under various tranforms .. inc. > >> rotations, scales, > >> > >> -phil. > >> > >> > >> On 9/7/21 4:43 PM, Daniel Gredler wrote: > >> > >> Hi all, > >> > >> I'm trying to figure out a fix for JDK-8269888 [1]. The font that I'm using > >> to replicate the issue, Google Noto Sans Thai Regular [2], uses the GPOS > >> table internally. It looks like the GPOS adjustment in HB is a two-step > >> process, where HB first sets the glyph position x_offset using anchor data > >> from the GPOS table [3], and then adjusts that x_offset using existing > >> x_advance data [4], all coordinated via the > >> HB_BUFFER_SCRATCH_FLAG_HAS_GPOS_ATTACHMENT scratch flag. > >> > >> Internally, OpenJDK is using the font_funcs virtual method functionality > >> [5] to customize most of the font property callbacks [6]. Java provides > >> users two ways to customize the size of a font: you can set the pt size, or > >> you can set an affine transform (scale, rotate, shear, translate, etc). > >> When you use the pt size approach, OpenJDK calls hb_font_set_scale with the > >> appropriate pt size [7]. However, when a scaling affine transform is used, > >> the pt size is technically unchanged, and a value of 1pt is used. Usually > >> this works fine, because Java's font_funcs callbacks are providing scaled > >> origin and advance numbers back to HB, but this breaks the two-step GPOS > >> attachment logic: the first step is not aware of the scaling applied by the > >> OpenJDK font_funcs callbacks (especially the > >> hb_font_get_glyph_h_advance_func_t), but the second step uses a scaled > >> advance value provided by an OpenJDK callback. In practice, at e.g. x50 > >> scaling, this means that the first step sets the x_offset to a relatively > >> small value (e.g. 32899), but the second step adjusts the x_offset by a > >> relatively large value (e.g. 1612184). > >> > >> A possible fix would be for OpenJDK to take the affine transform scale into > >> account when setting the font size via hb_font_set_scale, and the HarfBuzz > >> team has confirmed that this seems like the sensible approach [8]. In fact, > >> it seems like prior to 2016 this was indeed the case [9], but the logic was > >> changed to fix JDK-8145901 (Printed content is overlapping). JDK-8145901 > >> doesn't seem to be public in the bug tracker, and I'm not sure where to > >> find the HB_NODEVTX trigger used to request initialization of devScale in > >> HBShaper.c, so I'm not sure how to fix JDK-8269888 without risking a > >> regression on JDK-8145901. Is devScale still needed? Can we use xPtSize and > >> yPtSize (instead of ptSize*devScale) in _hb_jdk_font_create() and > >> _hb_jdk_ct_font_create()? I've confirmed that using xPtSize and yPtSize > >> fixes the Thai text rendering use case, at least. > >> > >> Thanks! > >> > >> Daniel > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8269888 > >> [2] https://www.google.com/get/noto/#sans-thai > >> [3] > >> https://github.com/harfbuzz/harfbuzz/blob/bbeb3a62b0efbb598d8683f7c4b6cc7069a58aeb/src/hb-ot-layout-gpos-table.hh#L708 > >> [4] > >> https://github.com/harfbuzz/harfbuzz/blob/bbeb3a62b0efbb598d8683f7c4b6cc7069a58aeb/src/hb-ot-layout-gpos-table.hh#L2922 > >> [5] https://harfbuzz.github.io/fonts-and-faces-custom-functions.html > >> [6] > >> https://github.com/openjdk/jdk/blob/005d8a7fca8b4d9519d2bde0a7cdbbece1cd3981/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc#L271 > >> [7] > >> https://github.com/openjdk/jdk/blob/005d8a7fca8b4d9519d2bde0a7cdbbece1cd3981/src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc#L422 > >> [8] https://github.com/harfbuzz/harfbuzz/discussions/3191 > >> [9] > >> https://github.com/openjdk/jdk/commit/5935292ae022e970bd4075de4d704719f3b05575#diff-6a155985752d3cc5ca8a74d4bf51c899d80ea0337e30029a4fafe856893456f3L327-L328 > >> > >> >
