Alternate substitution from OpenType (OT) GSUB table does not work when Adobe Advance Typography (AAT)'s morx and feat tables are present. It is available in the font features, but it does not work. It works fine in Inkscape. For your information, AAT does not have an alternate substitution feature. AAT and OT have different features, some overlapping, some not, sometimes with some degree of difference. Font making software like FontForge allows font makers to include both sets of features for better support across platforms, and leaves it up to software to pick up features from any set. It seems LibreOffice is getting confused with this, but since AAT does not have an alternate subsitution feature, it should really not look into AAT... For copyright reasons I cannot provide the original font that spurred this bug report, but I have prepared a special font named "Four" as a test case. I am attaching two versions. In both of these versions, there is a total of 7 characters: ・U+0034 (4) ・U+300C（「） ・U+300D（」） ・U+56DB (四) ・U+FE41（﹁） ・U+FE41（﹂） ・an alternate version of U+0034, encoded at the very end of the font, that displays as "four" In both versions, alternate substitution feature works as follows: ・U+0034 (4) provides two alternates: ・alternate version of U+0034 ・U+56DB (四) As explained above, AAT does not have an alternate substitution feature, so vertical substitution feature (very normal for Japanese fonts) has been added to make FontForge add AAT tables. Vertical substitution is available from both OT and AAT. This should not be considered when testing, but I include it for clarity: ・U+300C（「） gets replaced by U+FE41（﹁） ・U+300D（」） gets replaced by U+FE41（﹂） Four.ttf was generated from Four.sfd, with "Mac" option turned on, as a result, AAT tables were added from the presentence of a vertical subsitution feature. Four_noAAT.ttf was generated from Four_noAAT.ttf, with "Mac" option turned off. As a result, no AAT table was added. Expected result (can be checked with Four_noAAT): In the font dialog select font, and click "feature" next to the language box. There is an "Access all alternates" dropdown menu, that allows to select any of the substitutions. Two substitutions are available. Even without applying, you can see that the substitution will work. Actual result (can be checked with Four): In the font dialog select font, and click "feature" next to the language box. There is an "Access all alternates" dropdown menu, that allows to select any of the substitutions. Two substitutions are available. The subsitution does nothing. Alternate substitution should work in both Four_noAAT and Four. I am also including the original FontForge files, as well as ttx-uncompressed table data. P.S.: Vertical subsitution works regardless of presence or not of AAT. P.S.: FontForge has got good documentation about difference between AAT and OT: https://fontforge.org/docs/techref/gposgsub.html#gposgsub-conversion
Created attachment 193636 [details] Test font generated from Four.sfd, with "Mac" option turned on (affected by this bug).
Created attachment 193637 [details] Test font generated from Four_noAAT.sfd, with "Mac" option turned off (not affected by this bug).
Created attachment 193638 [details] FontForge data for Four.ttf
Created attachment 193639 [details] FontForge data for Four_noAAT.ttf
Created attachment 193640 [details] TTX data for Four.ttf
Created attachment 193641 [details] TTX data for Four_noAAT.ttf
Two typos in my bug description: U+FE41（﹂） → U+FE42（﹂） Four_noAAT.ttf was generated from Four_noAAT.ttf ↓ Four_noAAT.ttf was generated from Four_noAAT.sfd
Thanks for the detailed report. Khaled, I thought you might be able to grep this issue about 100 times quicker than me. What do you think?
If the font has a morx table HarfBuzz will use it for glyph substitution and will not look at GSUB table at all, since the two tables are exclusive, you can use one or the other but not both at the same time (one belongs to Apple Advanced Typography shaping model, and the other to OpenType shaping model). So if the font has a morx table but the alternate substitution feature is in GSUB table then the alternate substitution feature will be considered missing and will not be applied since the GSUB table is not consulted at all. I suggest to not include AAT tables at all.
Sorry, but it is a bug. The feature is available in the UI (shows there are 4 alternates) but does nothing. "So if the font has a morx table but the alternate substitution feature is in GSUB table then the alternate substitution feature will be considered missing and will not be applied since the GSUB table is not consulted at all." I think this is a good description of the bug, from where things can be worked on. It is not impossible to take a different approach. Again, it works fine in Inkscape.
To the previous message I would like to stress that there is a good reason to both have ATT and GSUB tables, as not all features exist in both sets, as seen from the N/A features described there: https://fontforge.org/docs/techref/gposgsub.html#gposgsub-conversion In that sense, I think LibreOffice UI's (and Inkscape's) approach at reading tables and enabling features is correct.
Sorry, I meant AAT and OpenType tables.
Is this bug due to HarfBuzz? If that's the case I might look into it and see what I can do, sometime in June.
Manual of HarfBuzz says "If a font has an AAT morx table, then it is used for substitutions; if not, but there is a GSUB table, then the GSUB table is used." According to FontForge's OT->AAT equivalence for substitution: Single -> Non-Contextual Glyph Multiple -> N/A N/A -> Glyph Insertion Alternate -> N/A Ligature -> Ligature N/A -> Contextual Glyph Chaining / Chaining Context -> N/A Reverse Chaining Context -> N/A N/A -> Indic Rearrangement That boils down to 9 unique types of substitutions, some only available in OT, some only in AAT, some in both OT and AAT. A preference for AAT becomes problematic if the right side of the list above has "N/A". In my test case, I use Alternate type, which is only available in OT. Removing AAT tables completely as suggested would make it impossible to use those substitution types that have N/A on the left side.
As this can be dealt with in HarfBuzz, let's close as notourbug for lack of a better status.
So, if I understand well the situation, although AAT and OpenType are not mutually exclusive by any of their standards, Japanese font designers will be forced to make two different set of fonts to provide support for legacy software AND LibreOffice, all of this due to the wit of an arabic support software designer refusing to touch his code?
And yes, I meant stubbornness, not wit. I took time to detail the problem and I can say it is very frustrating to hit such a wall.
Jonathan might have an opinion on this as well. Sorry I can't help further and don't know enough about the topic to weigh in.
HarfBuzz author here. - The reporters attitude is quite disturbing: "all of this due to the wit of an arabic support software designer refusing to touch his code?" borders on racism. - Mixing AAT and OpenType features is gray area. The two systems were NOT designed to be combined. Just don't do it. - Possibly relevant: https://github.com/harfbuzz/harfbuzz/issues/2124 - That it works in Inkscape is probably because of different HarfBuzz versions. - We probably should NOT list any substitutes if morx is present. That would "fix" your problem.
The issue here is that Harfbuzz is considering ATT and OT as a whole instead of looking at the individual features. It may be a convenient programming shortcut, but it forces font makers to creates two different fonts, one for OT-enabled software, and one for ATT-only software (mostly mac). Quite annoying to have to explain we are doing that because of LibreOffice...
(In reply to Y. Kawara from comment #0) > It works fine in Inkscape. My testing shows otherwise. With “Inkscape 1.3.2 (091e20e, 2023-11-25)” neither “aalt”, not “vrt2” features work with “Four” font, while they work with “Four_noAAT”. You will have to actually prove your claim that this font works anywhere the way you think it should work, before making wild accusations and showing a complete lack of understanding of how fonts work.
@Y. Kawara: many thanks for the detailed report! @Khaled, Behdad and all: many thanks for your feedback and analyses! According to the available information, this is NOTOURBUG in our bug triage*, and thanks to the first-hand information given by Behdad Esfahbod, this is NOTABUG (again, according to the available information: Khaled Hosny made a serious effort to understand the significance of the report, which would indeed indicate a bug.) This does not mean that this is not a real user needs! Covering all possible font features are very important for us – this is the story of Graphite (part of HartBuzz): supporting font features missing in OpenType and AAT. So it seems for me, this is a real enhancement request (of HarfBuzz). Moreover, calling the subject of the problem "gray area" by the lead HarfBuzz developer seems to be encouraging for a possible development of an optional HarfBuzz feature. We are all volunteers, who can be motivated by demonstrating the importance of the problem or maybe by paid to enhance the software. But we (Y. Kawara, Khaled, Behdad and me) are also font enthusiasts, so we have a very strong common ground. @Behdad, Khaled: Can you imagine an optional HarfBuzz feature for this – as I understand from the available information – very special enhancement request? If yes, can you suggest a method to contact the available HarfBuzz developers, like https://www.documentfoundation.org/certified-developers/ for LibreOffice, who could help solve this problem? *HarfBuzz is really an external (third-party) library, regularly updated in our code base (https://github.com/LibreOffice/core/tree/master/external/harfbuzz).
The bug I have reported is still present, despite the Harfbuzz developpers closing it. Harfbuzz attitude at segregating AAT and OT is not viable. Fonts have had both AAT and OT features in the past, and will continue doing so. As I wrote in the "other" bug (and the comment was muted), fonts are not developped for one piece of software, but for multi-software, multiplatforming in mind. It is sad that this is happening because currently LibreOffice is the most accessible software to check fonts, and features are turned off without any warning or explanation. This will just create confusion.
As far as I could check, version 8.2d1e2 of the Hiragino fonts, made by Screen and bundled in MacOS contain both AAT and OT features. And they have a quite extensive range of features, including tons of alternate substitutions (traditional and modern forms of kanji). The fonts I have attached to this bug report is a very simple representation of them.
Just an idea here though, if OT and AAT absolutely have to be segregated, why not let users decide which to be used? Or let the language info do so, for example? In my specific case I would rather see AAT being desactivated instead of OT.