On Tue, 10 Dec 2024 20:09:09 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 and TTF glyph mappers have been updated, but the macOS glyph mapper > has not been updated. One thing this fix does is change the logic which we have today FROM - Let the font have first say. If it maps the code point, use what the font provides, the font should know what it is doing. And only map to zero if the font does not support the code point TO - Never mind what the font says, these are always invisible and zero width. I have no easy way to know how this is going to work out in practice. Is there a particular reason you adopted this model ? Also there are some changes in the code points being checked for. Eg you added 0x200B .. you no longer check for 0x2028-0x2029 you added a check for 0x2060-0x2069 The additions probably make sense but I'm not sure why you removed some .. it is not explained. Perhaps because unicode does not designate it a "Format" character .. but we should still be treating it as invisible. It would be helpful to add comments say what the characters are in the range, as there is now a lot ! If it is a range like 0x2060-0x206F, then a summary of the 16 code points would be enough Also, I'd like you to say something about the embedded fonts in the test. Superficially, it appears you generated these from scratch using fontforge and the glyphs all display as a simple line. But I do need to understand the complete provenance of these. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22670#issuecomment-2552460091
