shaping returns incorrect flags with CoreText

[kovidgoyal]

hb-shape --show-flags --cluster-level=1 /System/Library/Fonts/Menlo.ttc abcd
[a=0+1233#1|b=1+1233#1|c=2+1233#1|d=3+1233#1]

As you can see the unsafe to break flag is set incorrectly. This is with harfbuzz compiled with --enable-coretext=yes. The same font if run with a version of harfbuzz compiled with --enable-coretext=no gives, the correct shape (using FreeType for font loading).

[a=0+1233|b=1+1233|c=2+1233|d=3+1233]

[behdad]

Thanks for the report. Yes and no! First, no shaper other than the ot shaper currently set unsafe-to-break. Ouch!

However, we cannot know for any of the other backends, since the underlying systems do not provide such API, so our safe bet is to mark all positions (except for first) unafe-to-break... I'll go ahead and do that.

cc @drott FYI

[kovidgoyal]

Sorry, I'm not very familiar with harfbuzz. Are you saying that it is the correct behavior to always set unafe to break? So your change will cause the flag to be set even with --enable-coretext=no

[khaledhosny]

When shaping with Core Text, HarfBuzz has no way to know if breaking after a glyph requires re-shaping or not, so it errors to the safe side and says you must always re-shape.

The difference between --enable-coretext=no and --enable-coretext=false must be because the font is shaped with OpenType shaper (HarfBuzz’s internal shaper) when Core Text is disabled, which only happens for fonts that has AAT table, other fonts should always be shaped by the OpenType shaper.

[kovidgoyal]

So If I use --shaper=ot am I guaranteed that it will always use the OpenType shaper, even for fonts with AAT tables. From my testing that would appear to be the case, but it would be nice to be certain.

[kovidgoyal]

Also, it seems to me that since the vast majority of glyphs are safe to break after, the default value of the flag when the information is not available should be zero. Or there should be a way to query harfbuzz to see if the value fo the flag can be relied upon or not.

[khaledhosny]

So If I use --shaper=ot am I guaranteed that it will always use the OpenType shaper, even for fonts with AAT tables.

Yes. But if the fonts have no OpenType layout tables the shaping might be broken (e.g. the AAT Indic fonts that ship with Mac, or even ligatures and kerning in the Latin fonts).

Also, it seems to me that since the vast majority of glyphs are safe to break after, the default value of the flag when the information is not available should be zero.

That is not a question about the default but whether HarfBuzz knows that it is safe to break between two glyphs without re-shaping or not. If HarfBuzz said it is safe but it weren’t, you would get wrong results after line breaking, but currently you just lose an optimization opportunity, but the result is still correct.

Or there should be a way to query harfbuzz to see if the value fo the flag can be relied upon or not.

What are you using this flag for?

[kovidgoyal]

I am using it for divding text into cells in a terminal emulator. The logic that works the best for me is this line:

https://github.com/kovidgoyal/kitty/blob/master/kitty/fonts.c#L464

Basically I determine that a glyph belongs in the current cell or not based on whether either the unsafe to break flags is set or the cluster number is the same as the previous cluster number.

[khaledhosny]

I don’t think this is what this flag is for; it is for determining whether the text should be re-shapped after breaking the line at a given glyph or not. Safe to break means re-shaping is not required, unsafe means re-shaping is not required. What you are looking for is probably Unicode grapheme clusters, which is text property not glyph one.

[khaledhosny]

@behdad may be this flag should have been named RESHAPE_AFTER_BREAKING or something.

[kovidgoyal]

Well if the text does not need to be reshaped after breaking the line at a given glyph, then it means the next glyph belongs to the next cell. Being able to break a line basically means that the glyphs are disjoint. Which is exactly the information I need.

And given that harfbuzz (as far as I can tell) has no way to unambiguously map glyphs back to the characters that they came from, I can see no other way to do this. A sequence of unicode codepoints ABCD after shaping becomes an arbitrary number of (possibly re-ordered) glyphs. So how do you suggest I discover which glyph correspnds to the boundary between AB and CD?

[khaledhosny]

Well if the text does not need to be reshaped after breaking the line at a given glyph, then it means the next glyph belongs to the next cell.

Not necessarily, if there is contextual substitution, for example, the glyphs will be marked unsafe to break even though they belong to different cells in a terminal:

$ hb-shape --show-flags --cluster-level=1 "Brill Roman 2.06 051.ttf" ἌΥΒ
[uni1F0C.caps=0+523|Upsilon.capsdialytika=1+538#1|Beta=2+533#1]

Being able to break a line basically means that the glyphs are disjoint.

This glyph does not tell you you can or cannot break here, this has to be determined by the client following whatever line breaking strategy it uses, the flag merely tell whether the client should re-shape after breaking or not.

And given that harfbuzz (as far as I can tell) has no way to unambiguously map glyphs back to the characters that they came from, I can see no other way to do this.

That is what the cluster field in the glyph info is for, it maps to the index of the code unit in the input string.

[kovidgoyal]

On Sun, Nov 12, 2017 at 10:29:04AM +0000, Khaled Hosny wrote: > And given that harfbuzz (as far as I can tell) has no way to unambiguously map glyphs back to the characters that they came from, I can see no other way to do this. That is what the `cluster` field in the glyph info is for, it maps to the index of the input code unit in the input text.

Really, the only discussion I could find for clusters is here: https://www.mail-archive.com/harfbuzz@lists.freedesktop.org/msg04698.html And from this paragraph on re-ordering: Another common operation in the more complex shapers is when things reorder. In those cases, to maintain monotone clusters, HB merges the clusters of everything in the reordering sequencec. Eg: A,B,C,D,E 0,1,2,3,4 if D is reordered before B, then we get: A,D,B,C,E 0,1,1,1,4 this is clearly not ideal, but the only sesible way to maintain monotone indices and the true relationship between glyphs and characters. This implies (at least as far as I understand it) that glyph0 maps to A, glyph1,glyph2,glyph3 map to B and glyph4 maps to three characters C D E. So that does not seem like a very reliable way to map from glyphs to characters either.

[khaledhosny]

See https://behdad.github.io/harfbuzz/harfbuzz-Buffers.html#hb-glyph-info-t-struct

It is a very reliable way (the only way actually), or how do you think interactive users of HarfBuzz handle things like text selection, copying, line breaking and so on?

When glyphs are merged into one cluster this means there is no sensible way to tell which glyph belongs to which character and you have to treat the sequence of glyphs as one units that maps to the characters from that cluster to the cluster - 1 of the first glyph with a different cluster.

[kovidgoyal]

In my experience, they dont. The number of bugs I have seen with selection with complex scripts is not funny.

But hey, you are the maintainers of harfbuzz, if you say one should use cluster indices only, then I am happy to follow your recommendation and if things break, I can simply point people that complain to this thread :)