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

[Philip Race]

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