Backport to 6.0.0

[LaurenzV]

Luckily for us, lots of commits that don't apply to us! But a couple of things I wasn't 100% sure about, again:

Status	Commit message	HB
🟢	[indic] Order left-matras inside-out	Link
🟢	[GPOS.PairPos] Adjust unsafe-to-break for non-zero ValueFormat2	Link
🟢	[indic-table] Minor adjust empty lines	Link
🟡	[gsubgpos] Optimize set-digest initialization	Link	im not sure about these, but as far as I can tell we don't have anything related to digest, right? Is this only necessary for the whole accelerators story?
🟡	[layout] Use a buffer digest for GPOS to skip whole lookups	Link
🟡	[layout] Use buffer-digest for GSUB as well	Link
🟡	[buffer] Add .digest() and use	Link
🟢	[layout] Only update buffer digest if buffer changed by a pause	Link
🟢	[layout] Comment	Link
🟢	[thai] Use smaller type for arrays	Link
🟡	[gsubgpos] Skippy-iter: Prefer correctness to performance	Link	I did translate those, but I'm not sure if the casting is optimal, would like to get some feedback on that
🟡	[gsubgpos] Comment	Link
🟡	[gsubgpos] No logic-change minor rewrite	Link
🟡	[gsubgpos] Conditionalize skippy on unsafe-to-concat	Link
🟡	[skippy-iter] Fix two logic errors	Link
🟢	[PairPos] Another attempt at fixing unsafe-to-break with ValueFormat2	Link
🟢	[indic] Support <U+0A02	Link
🟢	COLRv1: use ClipBoxes for extents	Link
🟢	[COLR] Return false from get_extents if table version not 1	Link
🟡	[COLR] Apply variations in get_extent	Link	from what I can tell harfbuzz always floors in this case? should we do the same or just use the round function as I did?

[RazrFalcon]

[gsubgpos] Optimize set-digest initialization | im not sure about these, but as far as I can tell we don't have anything related to digest, right? Is this only necessary for the whole accelerators story?

Yes, we do not have hb_set_digest_t. Don't remember why.

[gsubgpos] Skippy-iter: Prefer correctness to performance | I did translate those, but I'm not sure if the casting is optimal, would like to get some feedback on that

Not gonna lie, as long as tests are passing - I'm fine with it.

[COLR] Apply variations in get_extent | from what I can tell harfbuzz always floors in this case? should we do the same or just use the round function as I did?

We cannot floor/ceil/round in ttf-parser because of no_std. So as long as it doesn't affect tests - it's fine. Afaik we have a couple of "failing" tests already due to different rounding. This is sort of inevitable. Float precision is as an implementation detail.

[LaurenzV]

Okay! Then I guess this should be it (unless I should change the 1 - 1 thing)!

Looking at the commit history it seems like a lot of future commits are about "irrelevant" stuff (e.g. WASM API and the draw API), so I'm optimistic, but I don't want to jinx it either.

[behdad]

[gsubgpos] Optimize set-digest initialization | im not sure about these, but as far as I can tell we don't have anything related to digest, right? Is this only necessary for the whole accelerators story?

Yes, we do not have hb_set_digest_t. Don't remember why.

That object is worth porting, since it's a major optimization. It's not too much effort.

[LaurenzV]

That object is worth porting, since it's a major optimization. It's not too much effort.

How about I open an issue for it, so we don't forget about it? The thing is that right now I think the main priority (at least for me) is to get the current code and logic we have synced up with the newest harfbuzz, because what matters most for rustybuzz is correctness. Once we are synced up, we can always work on porting the other optimizations / missing features to rustybuzz, right? 😄

But I will let @RazrFalcon decide.

[behdad]

That object is worth porting, since it's a major optimization. It's not too much effort.

How about I open an issue for it, so we don't forget about it? The thing is that right now I think the main priority (at least for me) is to get the current code and logic we have synced up with the newest harfbuzz, because what matters most for rustybuzz is correctness. Once we are synced up, we can always work on porting the other optimizations / missing features to rustybuzz, right? 😄

Sounds good to me. I might even work on it as a way to find my way around Rust!

[RazrFalcon]

I do not mind adding hb_set_digest_t, as long as someone is willing to implement it.

[behdad]

@LaurenzV Did you figure out the COLRv1 clipping thing?

[LaurenzV]

Yeah, I just forgot that the test font doesn't contain any actual emojis but only other Unicode codepoints. 😅 It works as expected with the right input.