This split from bug 160634. When a font has a “morx” table, HarfBuzz will use it for glyph substitution, so if the font has also “GSUB” table it will not be used. Font Features dialog will list the “GSUB” features in the font, but they will have no effect which is misleading, so it should not list such features. attachment 193636 [details] (from bug 160634) has a font that has both “morx” and “GSUB” and can be used for testing.
-> NEW
Totally disagree. Harfbuzz should be patched to re-enable OpenType features instead. See https://bugs.documentfoundation.org/show_bug.cgi?id=160634
OpenType and AAT have different features that complete each other: Some features are only available in OT, some only in AAT, some in both. It's up to the software to enable individual features. Disabling them all is not a good approach. According to FontForge's OT->AAT equivalence for glyph 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
Hey Y. Kawara, next time you change the status, I will ban you.
This is a Harfbuzz bug. The UI is acting correctly.
Is there any real advantage to majority of LibreOffice users to have mixed AAT and OpenType features, even if complementary? Seems very much a corner case of interest only to those font designers making it a practice in their offerings. The HarfBuzz community does not seem enthusiastic of mixing smart type features, one or the other is fine--but not in combination. So why would we for an office suite. Suppressing OTF feature when an AAT feature takes precedence seems reasonable, especially if the OTF feature is disabled as implemented in HarfBuzz libs. If HarfBuzz moves the mark, sure. Until then just suppress the feature on the LibreOffice Character dialog. +1
I gave it a try here: https://gerrit.libreoffice.org/c/core/+/174294
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0679a5cee16ae96c0d11e7d4fc1e59fb0f9cc591 tdf#163213: do not show OpenType features if the font has "morx" table It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm not sure it worths it to cherry-pick this on 24.8 but if someone thinks it does, don't hesitate to cherry-pick it! :-)
Y. Kawara: I think I understand your point of view. The patch may be reverted quite quickly (since I put the tdf in comment and it's only a 2 lines patch) if Harfbuzz changes about this point. I'm not an expert about fonts but I suppose first step would be to discuss again about this with Harfbuzz community and then propose them a patch. Let's put this one to FIXED.
Some Hiragino fonts included in MacOS have both AAT and OpenType features. This "fix" is disabling their alternate substitution feature completely. And I'm not talking about some obscure Japanese font developer like me but a major one. Right now this "fix" is pushing me to craft two different fonts, one for AAT-only software, and one for OpenType-enabled software, just for LibreOffice. Not very convenient and also hard to explain to end users. Why is Harfbuzz imposing that to font developers? AAT and OpenType *can* coexist in fonts, because fonts is mostly just data. It's up to software to enable features they like.
P.S.: Ou reasonning for including both AAT and OT is to enable alternate substitution (only available in OT) but yet keep vertical substitution (available in both AAT and OT) for AAT-only software. Our fonts are rather simple though, the Hiragino fonts have a broader set of features, I do believe they had a good reason to take this approach.
(In reply to V Stuart Foote from comment #6) > Is there any real advantage to majority of LibreOffice users to have mixed > AAT and OpenType features, even if complementary? Seems very much a corner > case of interest only to those font designers making it a practice in their > offerings. > Font developers do not develop for one particular piece of software, but for the largest as possible software base. That is exactly why AAT and OT would be both included.
(In reply to Julien Nabet from comment #9) @Julien: according to https://bugs.documentfoundation.org/show_bug.cgi?id=163213#c11, this patch resulted regressions with commercial MacOS fonts (according to the description of the mentioned font: "Hiragino is the font for Japan’s best selling smartphone. Its incredible versatility has also made it a leading choice worldwide for car navigation systems, consumer electronics, software, advertising and corporate materials. https://www.screen-hiragino.com/#page-intro). If so, this patch should be withdrawn or further developed.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/378dd9025e39f7a4e575ba09b7bde8e038fc0b26 Revert "tdf#163213: do not show OpenType features if the font has "morx" table" It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to László Németh from comment #14) > (In reply to Julien Nabet from comment #9) > ... > If so, this patch should be withdrawn or further developed. Done
(In reply to V Stuart Foote from comment #6) > Is there any real advantage to majority of LibreOffice users to have mixed > AAT and OpenType features, even if complementary? Seems very much a corner > case of interest only to those font designers making it a practice in their > offerings. According to https://bugs.documentfoundation.org/show_bug.cgi?id=163213#c11, hybrid fonts are used by major Japanese font producers, so we must support that way, like macOS does, which would be a real advantage for our users, who want to use the fonts of their operating system or vendor in LibreOffice, too. (Not to mention the fact that if we distribute such fonts, there is no need to purchase/add a separate font for macOS and other systems.)
(In reply to Y. Kawara from comment #11) > Some Hiragino fonts included in MacOS have both AAT and OpenType features. > This "fix" is disabling their alternate substitution feature completely. And > I'm not talking about some obscure Japanese font developer like me but a > major one. @Y. Kawara: If I understand correctly, there was a previously functioning font feature that was spoiled by the previous patch. This has now been withdrawn, but if we can ask for more information about this font feature, test cases, it will help in future developments.
(In reply to Julien Nabet from comment #16) > (In reply to László Németh from comment #14) > > (In reply to Julien Nabet from comment #9) > > ... > > If so, this patch should be withdrawn or further developed. > > Done @Julien: many thanks for the quick withdrawn! (I wanted to ask for more information, reporting the regression, but now it's likely enough to collect the information here for possible future developments.)
(In reply to László Németh from comment #14) > (In reply to Julien Nabet from comment #9) > > @Julien: according to > https://bugs.documentfoundation.org/show_bug.cgi?id=163213#c11, this patch > resulted regressions with commercial MacOS fonts (according to the > description of the mentioned font: "Hiragino is the font for Japan’s best > selling smartphone. Its incredible versatility has also made it a leading > choice worldwide for car navigation systems, consumer electronics, software, > advertising and corporate materials. > https://www.screen-hiragino.com/#page-intro). > > If so, this patch should be withdrawn or further developed. What stopped working exactly and it what way? Y. Kawara makes it sound like they know what they are saying, but evidently they have absolutely no idea what they are taking about. I just checked and neither of the Hiragino fonts that ship with macOS has a “morx” table. Table information for all Hiragino fonts shipped in macOS. Not a single one of them as a “morx” table: /System/Library/Fonts/Hiragino Sans GB.ttc Table information: Tag Size ------------ BASE 536 bytes CFF 12397723 bytes GPOS 1204 bytes GSUB 43900 bytes OS/2 96 bytes VORG 820 bytes cmap 509537 bytes head 54 bytes hhea 36 bytes hmtx 102846 bytes maxp 6 bytes meta 2901 bytes name 3804 bytes post 32 bytes vhea 36 bytes vmtx 116252 bytes /System/Library/Fonts/ヒラギノ明朝 ProN.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 8896220 bytes GPOS 87864 bytes GSUB 197104 bytes OS/2 96 bytes VORG 884 bytes cmap 241818 bytes head 54 bytes hhea 36 bytes hmtx 72608 bytes maxp 6 bytes meta 4091 bytes name 2796 bytes post 32 bytes vhea 36 bytes vmtx 74214 bytes /System/Library/Fonts/ヒラギノ丸ゴ ProN W4.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 8476407 bytes GPOS 72922 bytes GSUB 344728 bytes OS/2 96 bytes VORG 1044 bytes cmap 222120 bytes head 54 bytes hhea 36 bytes hmtx 73046 bytes maxp 6 bytes meta 4135 bytes name 2836 bytes post 32 bytes vhea 36 bytes vmtx 74214 bytes /System/Library/Fonts/ヒラギノ角ゴシック W0.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 3254205 bytes GPOS 61512 bytes GSUB 35446 bytes OS/2 96 bytes VORG 1044 bytes cmap 125530 bytes head 54 bytes hhea 36 bytes hmtx 38026 bytes maxp 6 bytes meta 3714 bytes name 2812 bytes post 32 bytes vhea 36 bytes vmtx 37740 bytes /System/Library/Fonts/ヒラギノ角ゴシック W1.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 6626958 bytes GPOS 77560 bytes GSUB 199058 bytes OS/2 96 bytes VORG 1148 bytes cmap 192684 bytes head 54 bytes hhea 36 bytes hmtx 81334 bytes maxp 6 bytes meta 4074 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 74238 bytes /System/Library/Fonts/ヒラギノ角ゴシック W2.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 6610930 bytes GPOS 77162 bytes GSUB 199058 bytes OS/2 96 bytes VORG 816 bytes cmap 192684 bytes head 54 bytes hhea 36 bytes hmtx 81334 bytes maxp 6 bytes meta 4074 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 74238 bytes /System/Library/Fonts/ヒラギノ角ゴシック W3.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 6719767 bytes GPOS 73560 bytes GSUB 199058 bytes OS/2 96 bytes VORG 812 bytes cmap 192684 bytes head 54 bytes hhea 36 bytes hmtx 81334 bytes maxp 6 bytes meta 4098 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 74238 bytes /System/Library/Fonts/ヒラギノ角ゴシック W4.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 6601917 bytes GPOS 74866 bytes GSUB 199058 bytes OS/2 96 bytes VORG 800 bytes cmap 192684 bytes head 54 bytes hhea 36 bytes hmtx 81334 bytes maxp 6 bytes meta 4074 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 74238 bytes /System/Library/Fonts/ヒラギノ角ゴシック W5.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 6604456 bytes GPOS 72770 bytes GSUB 199058 bytes OS/2 96 bytes VORG 824 bytes cmap 192684 bytes head 54 bytes hhea 36 bytes hmtx 81334 bytes maxp 6 bytes meta 4102 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 74238 bytes /System/Library/Fonts/ヒラギノ角ゴシック W6.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 6767323 bytes GPOS 68632 bytes GSUB 199058 bytes OS/2 96 bytes VORG 824 bytes cmap 192684 bytes head 54 bytes hhea 36 bytes hmtx 81334 bytes maxp 6 bytes meta 4102 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 74238 bytes /System/Library/Fonts/ヒラギノ角ゴシック W7.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 3322374 bytes GPOS 29720 bytes GSUB 35446 bytes OS/2 96 bytes VORG 988 bytes cmap 125530 bytes head 54 bytes hhea 36 bytes hmtx 38026 bytes maxp 6 bytes meta 3738 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 37740 bytes /System/Library/Fonts/ヒラギノ角ゴシック W8.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 3292123 bytes GPOS 27842 bytes GSUB 35446 bytes OS/2 96 bytes VORG 668 bytes cmap 125530 bytes head 54 bytes hhea 36 bytes hmtx 38026 bytes kerx 24648 bytes maxp 6 bytes meta 3738 bytes name 2680 bytes post 32 bytes vhea 36 bytes vmtx 37740 bytes /System/Library/Fonts/ヒラギノ角ゴシック W9.ttc Table information: Tag Size ------------ BASE 456 bytes CFF 3187020 bytes GPOS 26966 bytes GSUB 35446 bytes OS/2 96 bytes VORG 688 bytes cmap 125530 bytes head 54 bytes hhea 36 bytes hmtx 38026 bytes maxp 6 bytes meta 3714 bytes name 2676 bytes post 32 bytes vhea 36 bytes vmtx 37740 bytes
(In reply to خالد حسني from comment #20) > (In reply to László Németh from comment #14) > > (In reply to Julien Nabet from comment #9) > > > > @Julien: according to > > https://bugs.documentfoundation.org/show_bug.cgi?id=163213#c11, this patch > > resulted regressions with commercial MacOS fonts (according to the > > description of the mentioned font: "Hiragino is the font for Japan’s best > > selling smartphone. Its incredible versatility has also made it a leading > > choice worldwide for car navigation systems, consumer electronics, software, > > advertising and corporate materials. > > https://www.screen-hiragino.com/#page-intro). > > > > If so, this patch should be withdrawn or further developed. > > What stopped working exactly and it what way? Y. Kawara makes it sound like > they know what they are saying, but evidently they have absolutely no idea > what they are taking about. > > I just checked and neither of the Hiragino fonts that ship with macOS has a > “morx” table. > > Table information for all Hiragino fonts shipped in macOS. Not a single one > of them as a “morx” table: László: please check it.
(In reply to László Németh from comment #17) > (In reply to V Stuart Foote from comment #6) > > Is there any real advantage to majority of LibreOffice users to have mixed > > AAT and OpenType features, even if complementary? Seems very much a corner > > case of interest only to those font designers making it a practice in their > > offerings. > > According to https://bugs.documentfoundation.org/show_bug.cgi?id=163213#c11, > hybrid fonts are used by major Japanese font producers, so we must support > that way, like macOS does We do, just fine. What we can’t do, however, is support what Y. Kawara imagines should happen, which is mixing and matching morx and GSUB substitutions. There is no such a thing, you can either apply morx substitutions or GSUB substitutions, not both. What this bug is about, is hiding misleading UI that does not work and only confuses people. If the font has a morx table, morx table substitutions will be used, but the feature dialog is showing GSUB substitutions and turning these on or off has no effect. We can’t show morx substitution because we have no way to control them from HarfBuzz API.
@Khaled, Julien and all: many thanks for the quick check! I agree, that we need proof for the possible regressions here, sorry that my bad wording resulted the (early) revert of the fix. Also I agree with Julien, we can revert easily the fix, if needed, e.g. when it will become obsolete. (I write "early" because I asked about a possible HarfBuzz enhancement here: https://bugs.documentfoundation.org/show_bug.cgi?id=160634#c22).
I think a by-feature approach would work better than the current approach of disabling OT completely. I don't see how, for example, OT's alternate substitution feature could possibly clash with AAT's vertical substitution feature. In the worst case, the layout engine could decide to pick up OT's vertical substitution instead, too (if available). As I suggested in my original bug report, why not leave it up to the user to activate either AAT or OT? Giving users the choice is always the best solution in the end, instead of deciding for them. On another note, I think the UI should be kept as is for now, because with the proposed patch LO seems to not support OT features at all. Users will not suspect that the issue is presence of AAT - I would not be here at all...
(In reply to Y. Kawara from comment #24) > I think a by-feature approach would work better than the current approach of > ... Could you provide a link to a font containing the morx table? (or attach the font to the bugtracker if possible) Indeed Khaled took the time to dump info from Hiragino fonts and it's nowhere to be seen.
P.S. By leaving it up to the users I mean end users, not font makers. It could be a global option or per-file option (or both) in LO, something like "Prefer AAT over OT" with a checkbox. And the default value could be different depending on locale and/or operating system.
(In reply to Julien Nabet from comment #25) > Could you provide a link to a font containing the morx table? (or attach the > font to the bugtracker if possible) > The Hiragino fonts are not available for free but as far as I could check, version 8.2d1e2/7.11 has both AAT and OT. Maybe you can find them somewhere... Bug 160634 has a font with both AAT and OT. You could consider it a very simple, stripped version of the Hiragino fonts.