On Thu, 6 Jun 2024 20:24:07 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> I see, PrismFontFactory:164 getNativeFactoryName(). >> It would be nice to place platform-specific code in a package bearing the >> platform name, or at least mention this in a class-level comment, but I >> guess it's too late. >> >> It means the scope is already limited to macOS, we are good. > > I'm having some doubts about the solution still. It is mentioned that this > problem can occur in text containing both LTR and RTL text together, however, > as far as I can see, a `TextRun` never contains a mix of text directions. > Can you clarify this? > > Also in RTL text, I'm guessing "trailing" spaces are in fact what we call > leading spaces in LTR text, ie. trailing spaces in a RTL text sample would > be: ` قطة` > > I'm guessing that CT (Core Text) returns the positions of all the trailing > spaces as negative values, not just the first, and the first glyph (seen from > the left) with an offset of 0. Since the CT framework can also handle > alignments, but FX is not making use of this, I think all calculations are > done with the standard left alignment. It would make sense for spaces that > "fall off" the left end (because they're "trailing") to have negative values. > Similarly, if you did LTR text for `cat ` with a right alignment, all > glyphs would have negative values, except the two trailing spaces that would > have positive values. > > So I'm curious to see what happens if you have more than one trailing space > (eg. ` قطة`) and what `CTRunGetPositions` returns then. Yes, I am also curious about the exact meaning of these negative values. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1468#discussion_r1630411969
