Bug 163213 - Font Features dialog should not show OpenType features if the font has “morx” table
Summary: Font Features dialog should not show OpenType features if the font has “morx”...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Character-Dialog
  Show dependency treegraph
 
Reported: 2024-09-30 11:19 UTC by ⁨خالد حسني⁩
Modified: 2024-10-06 17:32 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ⁨خالد حسني⁩ 2024-09-30 11:19:28 UTC
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.
Comment 1 Buovjaga 2024-09-30 11:20:45 UTC
-> NEW
Comment 2 Y. Kawara 2024-09-30 11:32:31 UTC Comment hidden (off-topic)
Comment 3 Y. Kawara 2024-09-30 11:36:48 UTC Comment hidden (off-topic)
Comment 4 Buovjaga 2024-09-30 11:47:32 UTC
Hey Y. Kawara, next time you change the status, I will ban you.
Comment 5 Y. Kawara 2024-09-30 11:56:12 UTC Comment hidden (off-topic)
Comment 6 V Stuart Foote 2024-09-30 12:32:35 UTC
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
Comment 7 Julien Nabet 2024-09-30 17:56:47 UTC
I gave it a try here:
https://gerrit.libreoffice.org/c/core/+/174294
Comment 8 Commit Notification 2024-09-30 20:33:04 UTC
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.
Comment 9 Julien Nabet 2024-09-30 20:34:08 UTC
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! :-)
Comment 10 Julien Nabet 2024-09-30 20:39:56 UTC
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.
Comment 11 Y. Kawara 2024-10-02 17:15:16 UTC Comment hidden (no-value)
Comment 12 Y. Kawara 2024-10-02 17:29:03 UTC Comment hidden (no-value)
Comment 13 Y. Kawara 2024-10-02 17:59:38 UTC Comment hidden (no-value)
Comment 14 László Németh 2024-10-03 17:26:48 UTC
(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.
Comment 15 Commit Notification 2024-10-03 17:31:12 UTC
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.
Comment 16 Julien Nabet 2024-10-03 17:32:03 UTC
(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
Comment 17 László Németh 2024-10-03 17:41:23 UTC
(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.)
Comment 18 László Németh 2024-10-03 17:45:55 UTC
(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.
Comment 19 László Németh 2024-10-03 17:48:01 UTC
(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.)
Comment 20 ⁨خالد حسني⁩ 2024-10-03 18:03:04 UTC
(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
Comment 21 Buovjaga 2024-10-03 18:12:20 UTC
(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.
Comment 22 ⁨خالد حسني⁩ 2024-10-03 18:23:00 UTC
(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.
Comment 23 László Németh 2024-10-03 21:13:22 UTC
@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).
Comment 24 Y. Kawara 2024-10-06 17:17:49 UTC
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...
Comment 25 Julien Nabet 2024-10-06 17:21:57 UTC
(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.
Comment 26 Y. Kawara 2024-10-06 17:24:50 UTC
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.
Comment 27 Y. Kawara 2024-10-06 17:32:19 UTC
(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.