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
Lookup flags in fonts with no GDEF table #2647
Comments
Sounds related to the GDEF change we made and reverted. The carrying-forward of the flags is wrong... |
That is with 2.7.1 where the offending commit is reverted, unless you mean the old behavior was also wrong. |
Hmm, if I add a |
(Core Text and Uniscribe don’t make the ligatures when |
Yes. |
Simon found problems with pre-2.7.0 HB-no-GDEF. We tried to address, broke others. Even then there's more issues. I'll try to write them down here soon. |
Let's revive this issue and figure out what needs to be fixed. |
Fixed by #3365 ? |
Does not seem so. |
Can you send me the font in question please? |
Nevermind. Got it. |
I think I know what to do. |
Basically, what they are doing, I suppose, is that when matching ligatures (and context, etc) other than the first item, ignore IgnoreBase and IgnoreLigature... lol. We do the same during mark-attachment lookups. |
Do not respect IgnoreBaseGlyphs and IgnoreLigatures when matching input, lookahead, and backtrack. Makes five tests fail; four of them in aots. One in our mark-attachment. I think this matches what other shapers do though. We should test more. Fixes #2647
Do not respect IgnoreBaseGlyphs and IgnoreLigatures in the matcher. Makes five tests fail; four of them in aots. One in our mark-attachment. I think this matches what other shapers do though. We should test more. Fixes #2647
Do we actually have evidence that Uniscribe does this? |
I'm leaning towards closing this. |
I have no more information to add and since apparently it is only this font and IMHO that is a badly built one, lets close. |
This problem is not limited to B Nazanin. I have the same problem with Arial and Tahoma:
I am using Ubuntu 22.04. The same problem is visible with Arial and the latest version of harfbuzz:
|
This is not the same issue. The old corefonts are broken, I get the same failure in with DirectWrite as well. Newer versions of the fonts are fine. |
To be clear, the fonts have ligature lookups for the mark ligatures that set both ignore base and ignore ligatures lookup flags, so HarfBuzz is doing what the fonts asked for. |
So the difference is that Arial has a GDEF table, but B Nazanin does not. So again I think the issue is that HarfBuzz is synthesizing glyph classes when GDEF table is absent and DirectWrite is apparently not doing that. |
Re-opening to see if we actually want to follow MS implementation here or not. |
Apparently the answer is no, it does not do this. |
With: diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index 0806abb7d..29c2ec2f9 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -137,8 +137,8 @@ hb_ot_shape_planner_t::compile (hb_ot_shape_plan_t &plan,
* Decide who provides glyph classes. GDEF or Unicode.
*/
- if (!hb_ot_layout_has_glyph_classes (face))
- plan.fallback_glyph_classes = true;
+ //if (!hb_ot_layout_has_glyph_classes (face))
+ // plan.fallback_glyph_classes = true;
/*
* Decide who does substitutions. GSUB, morx, or fallback. The B* fonts stop making the incorrect mark ligature. |
I opened MicrosoftDocs/typography-issues#954 for spec clarification. |
From the Uniscribe API limitations also I have deduced that they can't be doing this. |
At least not for positioning. |
I'm thinking about blacklisting the GPOS of these fonts. Where can we find them all? |
FWIW we intentionally nuke the GDEF of these fonts, up to Windows 8. Wonder if we should do the same to their GPOS. |
This is one way to handle this: Only synthesize glyph classes if font doesn't have GDEF and doesn't have GPOS. diff --git a/src/hb-ot-shape.cc b/src/hb-ot-shape.cc
index 3da317a5c..5c68bee21 100644
--- a/src/hb-ot-shape.cc
+++ b/src/hb-ot-shape.cc
@@ -137,7 +137,8 @@ hb_ot_shape_planner_t::compile (hb_ot_shape_plan_t &plan,
* Decide who provides glyph classes. GDEF or Unicode.
*/
- if (!hb_ot_layout_has_glyph_classes (face))
+ if (!hb_ot_layout_has_glyph_classes (face) &&
+ !hb_ot_layout_has_positioning (face))
plan.fallback_glyph_classes = true;
/* One test fails though. Need to investigate. I haven't checked that it actually fixes the case at hand. |
One of the failing tests is in Thai and we fail to zero mark advances, I suppose because there is no mark attachment in the GPOS. This change seems fragile at this point in time :(. |
Humm. The other failing test is Latin. It does have mark attachment, so I'm surprised why marks are not getting zero advances. Investigating. |
Oh. Because we don't synthesize, we now are not applying mark attachment either. |
Blocklisting the GPOS of the affected fonts sounds like the best option to me. Where can we get all these fonts? |
I only know the fonts attached to the LO issue above (https://bugs.documentfoundation.org/show_bug.cgi?id=135778) |
... and there is the font in #2888 |
Someone reports an issue in LibreOffice about some Iranian fonts like B Nazanin (fonts attached in the LIbreOffice issue).
Basically the font has mark ligatures for shadda and the lookups has ignore base and ignore ligatures set (which makes no sense), which causes HarfBuzz to correctly skip bases and make ligature between shadda and fathatan in strings like:
Oddly enough, both Uniscribe and Core Text ignore the lookup flags and don’t for the ligatures.
As it turns out, the font has no
GDEF
table, so HarfBuzz synthesizes one and use it here.It is a rather odd font, and I HarfBuzz synthesis of a GDEF table actually matches what the spec is saying (emphasis mine):
But it might be an interoperability issue that we might want to consider (my 2¢ is to 🤷🏽 and declare it working as designed).
The text was updated successfully, but these errors were encountered: