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
HarfBuzz applies morx as part of AAT, which in some fonts differs from GSUB and isn’t applied on Windows #653
Comments
Please provide a full sample that fails. Ligatures without code points work fine in the first font I tried, Cambria Bold (ffb → unmapped ligature glyph), and even the issue you link references Zapfino as an example of a font with lots of such ligatures that work just fine. |
You're right, the Cambria TTF without unicode code points seem to work. I'll try to find the specific thing that is broken, maybe it's only with OTF-fonts. I will add an example later. |
Most fonts seem to work in both TTF and OTF, I could not check the Zapfino, I think it's not freely available. But here is another one by Zapf and it does not work as expected, it does work correctly on Windows font preview, though. The expected ligature in word
|
Thanks! However, I cannot produce the ligature you mention with the given font in |
The font contains both HarfBuzz supports both OpenType and AAT and picks Overall, it is all the fonts fault here, but if replicating Windows behavior is a must, you probably need to stop sending AAT tables to HarfBuzz when it asks for them, since it currently has no API to prefer OpenType layout over AAT one. |
(I removed the AAT tables using |
Thanks! Wow. Ideally, I guess we’d like libass to mimic Windows most of the time but also to continue supporting Mac-only fonts (such as Zapfino IIRC). I suppose we could do something like: expose That said, @TS40, your samples seem to assume libass-specific (VSFilter-incompatible) functionality anyway, and in that case Windows compatibility isn’t exactly a concern in the first place and it’s all the more tempting to stick to HarfBuzz’s typical behaviour. Indeed, where Windows/VSFilter compatibility is a concern, #136 actually tells us to disable ligatures entirely, except when #237 re-enables them. |
@astiob Thank you for looking into this! I think, we can close this then. @khaledhosny Thank you very much for the detailed analysis, that makes it very clear! \documentclass[a4paper]{article}
\usepackage{fontspec}
\setmainfont{LOV.Gilgengart.otf}
\begin{document}
test
\end{document} and it looks the same as in Windows font preview. But probably some preprocessing is happening there. |
This might be a good case for differentiating between memory fonts and provider fonts (i.e. maybe only provider fonts on non-windows should get the non-vsfilter behavior). |
That is also a good point! |
It has it but it is not used by default, better try XeTeX or pass |
The other main AAT table is |
I forgot |
@khaledhosny You are right, with XeTeX I get the behaviour that I also see with @astiob Probably the best would be to compare if there exists AAT and GSUB and if so if they differ and then print a warning. Unfortunately I'm not a C programmer so I can't really commit here. But now that I know the problem I'm ok with the FontForge font conversion workaround. |
I assume that if it were simple to compare them, there wouldn’t be two of them in the first place… They’re probably completely different inside. |
(Updated)
Currently, some ligatures in some fonts are not taken, although they work in other applications like Windows font preview.
This is related.
Workaround: Open the font with FontForge, scroll to the last row, for each glyph without a code point: assign one starting at for example 100.000. After this, it will work flawless. Updates to the ligature tables are not needed, since the glyphs before where adressed by name not by value.
A first solution to this could be to print out a warning to the console (easiest approach: if at least one glyph exists that has no unicode value assigned, better approach: if at least one glyph exists that has no unicode value assigned and is refered to in the
liga
table: warn), took me some time to find out what was the problem.The text was updated successfully, but these errors were encountered: