JDK-8269888: Thai text rendered incorrectly using some AffineTransform-derived fonts

Thu Oct 10 11:06:41 UTC 2024

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 <philip.race at oracle.com> 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 <philip.race at oracle.com> 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
> >>
> >>
>