Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Backport to 5.0.0 #108

Closed
wants to merge 18 commits into from
Closed

Backport to 5.0.0 #108

wants to merge 18 commits into from

Conversation

LaurenzV
Copy link
Collaborator

@LaurenzV LaurenzV commented Jun 14, 2024

Status Commit message HB
🟢 [tt-font] Apply VVAR.vOrg variation to VORG origin Link Implemented in ttf-parser. I manually verified that harfbuzz/harfbuzz#1694 is now resolved for us as well.
🟡 [glyf] Change side-bearing rounding Link not relevant I think? since we don't support phantom points yet
🟡 Fix LookupFlag negation Link I believe this shoulddnt affect us?
🟡 [use-table] Port to using packtab Link Unfortunately packtab seems to generate c++ code (and it's also been updated in the meanwhile)... so for now I've decided to switch to a manual implementation, hopegully when the port is done we can port the packTab code to work with rust. But see the discussion below.
🟢 [GPOS] Adjust mark attachment on multiple substitution some more Link
🟡 [reorg] Move Coverage Link ttf-parser stuff I guess?
🟢 [arabic] Pause after calt only if no rclt Link
🟡 [aat/morx] Implement language-specific forms Link Where exactly can I find this ltag in our port?
🟡 [aat/morx] Add test for previous commit Link
🟡 Add hb_language_matches() Link
🟢 [arabic] Make more features F_MANUAL_ZWJ Link
🟢 [GPOS/Cursive] Fix breaking of parent-child attachment Link
🟢 [hebrew] Implement Jerusalem mark reordering Link
🟢 [hebrew] Comment Link
🟢 Add tests for multiple cursive positioning Link
🟢 [hebrew] Break out of reordering loop when pattern found Link
🟢 [GPOS/CursivePos] Fix unsafe-to-break marking Link
🟡 [layout] Reduce number of closure rounds Link we dont have this right?

@RazrFalcon
Copy link
Collaborator

How the new USE table works? Have you simply ported C code to Rust? Because the new Python script produces C, right?

@LaurenzV
Copy link
Collaborator Author

Yeah exactly, they have a python package that somehow encodes the data more compactly, and it generates C code. I think we can rewrite it to produce Rust, but I noticed that they change the script again in the future so for now I think it's easier to do it by hand, it only changes a couple of times anyway.

@behdad
Copy link
Member

behdad commented Jun 15, 2024

Adding Rust output to packtab sounds like it should take 20min. I'd be happy to take that.

https://github.com/harfbuzz/packtab/blob/3eb74c28bc92379156156234fa7d11d63e27cd75/Lib/packTab/__init__.py#L194

@LaurenzV
Copy link
Collaborator Author

That would be great if possible!

@LaurenzV
Copy link
Collaborator Author

@RazrFalcon Alright, so the main thing missing now is avar2. Would you prefer me to try implement it in ttf-parser as suggested by Behdad, or should I rather focus on backporting more commits for now?

@LaurenzV
Copy link
Collaborator Author

And I've added a note about the ones I was uncertain about again at the top.

@RazrFalcon
Copy link
Collaborator

I think we can skip avar2 for now. We could mention it in the README, that this harfbuzz feature is not supported.

To my understanding avar2 is not part of the TrueType spec. It might become one, but not for now. So we can ignore it as an extreme edge case. We have other things to do in the mean time...

Of course if you're interested in implementing avar2 - go ahead.

@LaurenzV
Copy link
Collaborator Author

I'll add it in the README.

@LaurenzV LaurenzV marked this pull request as ready for review June 16, 2024 15:25
@LaurenzV
Copy link
Collaborator Author

Okay, so apart from the orange points mentioned above that I was unsure about, the rest should be done.

@LaurenzV
Copy link
Collaborator Author

Closing in favor of #109, which contains all commits here + until 5.3.1.

@LaurenzV LaurenzV closed this Jun 16, 2024
@RazrFalcon
Copy link
Collaborator

Why not merge it as 5.0.0?

@LaurenzV
Copy link
Collaborator Author

I mean... we can if you want, but since I already ported until 5.3.1 might as well merge that, no? The commits from 5.0.0 are in there as well, but if you prefer it that way I will reopen one just for 5.0.0.

@RazrFalcon
Copy link
Collaborator

I guess I would prefer smaller patches in the future. Easier to review.
But yeah, I was just confused why have you merged two PRs into one.

@LaurenzV
Copy link
Collaborator Author

Okok, I'll keep that in mind for the future.

@LaurenzV LaurenzV deleted the 5.0.0 branch June 19, 2024 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants