-
Notifications
You must be signed in to change notification settings - Fork 21
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
Mark-to-mark glyph positioning incorrect #107
Comments
If anyone has an idea how to fix this issue, I'd be glad to help. Thank you. |
I have a fix, it's just working its way through internal review. |
@wezm That's great. Thanks for your efforts, Please let me know if I could be of any help. |
Reported in #107 The selection of glyph pairs for mark-to-mark positioning was too eager. For the text in question the ligature component position was not being considered which was resulting in mark-to-mark positioning being applied to marks 2 and 3 when it should not have. Considering the ligature component position corrects this. However, requiring the ligature component position to always match broke some marks in Vietnamese. The solution was the introduction of a ligature flag on RawGlyph so that a mark glyph can be tracked as a ligature. This is used during GPOS to allow mark-to-mark positioning between a pair of marks if one of them is a ligature despite having differing ligature component positions. This behaviour matches Harfbuzz: https://github.com/harfbuzz/harfbuzz/blob/09a17a086c54e5c1b1aa674bba5b5449286e1480/src/OT/Layout/GPOS/MarkMarkPosFormat1.hh#L134-L138
This is the fix 1bf2db8 I'll work on a patch release now |
Reported in #107 The selection of glyph pairs for mark-to-mark positioning was too eager. For the text in question the ligature component position was not being considered which was resulting in mark-to-mark positioning being applied to marks 2 and 3 when it should not have. Considering the ligature component position corrects this. However, requiring the ligature component position to always match broke some marks in Vietnamese. The solution was the introduction of a ligature flag on RawGlyph so that a mark glyph can be tracked as a ligature. This is used during GPOS to allow mark-to-mark positioning between a pair of marks if one of them is a ligature despite having differing ligature component positions. This behaviour matches Harfbuzz: https://github.com/harfbuzz/harfbuzz/blob/09a17a086c54e5c1b1aa674bba5b5449286e1480/src/OT/Layout/GPOS/MarkMarkPosFormat1.hh#L134-L138
0.14.2 has been published. |
Thank you. It's impressive your deep knowledge of opentype specs. even though the resources are scarce. |
Unfortunately the OpenType specs are lacking specification for this type of thing so it mostly comes down to receiving bug reports like yours and then trying to work out what should be happening.
The fix for your specific issue was when performing mark-to-mark positioning to consider the ligature component position and only perform mark-to-mark positioning when the marks are on the same ligature component. However, applying this in isolation broke a Vietnamese test we had where one of the marks was itself a ligature so I mirrored what Harfbuzz does and allowed mark-to-mark positioning across ligature components in the case where one of the marks is a ligature. |
@wezm Thanks again for your efforts. |
No worries, thanks for the clear bug report. |
Some marks in the Arabic text "ٱللَّهَ" are not positioned correctly.
Issue
The last glyph colored in "Blue" should be positioned similar to its corresponding glyph in the word below.
This is the layout details for the last glyph
// Render Settings
font_size: 72
dpi: 96
upm: 2048
font: uthmanic_hafs_v20.ttf
I will attach the data collected from allsorts in the next comment.
Looking forward to hearing from you.
Originally posted by @solomancode in #106
The text was updated successfully, but these errors were encountered: