On Fri, 20 Dec 2024 00:17:54 GMT, Daniel Gredler <dgred...@openjdk.org> wrote:
>> Soft hyphens should never render, regardless of the rendering path used
>> internally.
>>
>> This PR does not expand the categorization of "complex" characters in
>> `FontUtilities` in order to force the use of `TextLayout` rendering code
>> paths (as was discussed in JBS).
>>
>> Instead, it takes the existing (limited) format-category checks in
>> `sun.font.CMap` (a TrueType font helper class), expands it to a more general
>> / complete default-ignorable check
>> (`FontUtilities.isDefaultIgnorable(int)`), and then moves these checks out
>> of `CMap` and up a level into the `CharToGlyphMapper` classes themselves.
>>
>> The Type1 glyph mapper, the TTF glyph mapper, and the macOS glyph mapper
>> have all been updated.
>
> Daniel Gredler has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add more info about test fonts and default-ignorable chars
I am not completely comfortable with this change, as there's a policy change,
and I am not as sure as I'd like to be even though it passes all the tests that
we normally run.
Also note harfbuzz *happens* to be what we use for layout but that's internal
implementation. But I do agree consistency of layout vs non-layout paths is
important.
Meaning drawString("XXX") ought to render the same glyphs in the same way as
"new TextLayout("XXX").draw(...) in all cases.
I am approving however, as this is early in 25 and I hope any issues surface
early.
-------------
Marked as reviewed by prr (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/22670#pullrequestreview-2573495758
