Bug 130321 – Operator stretching: add hardcoded MATH data

• Component: MathML
• Status: RESOLVED WONTFIX

[Frédéric Wang (:fredw)]

I'm splitting attachment 226844 [details] for review.

The first step is to create the OpenTypeMathData class with associated hardcoded data for STIX and Latin Modern.

[Frédéric Wang (:fredw)]

Created attachment 226895 [details]
Python script to extract the MATH data from the STIX Math & Latin Modern Math fonts

[Frédéric Wang (:fredw)]

Created attachment 226896 [details]
Patch

[Frédéric Wang (:fredw)]

I discussed that with Martin, and I'd like to get feedback on the right approach. In bug 99620 comment 5, I was told to use a sorted hardcoded constant array to implement the MathML dictionary. So I did the same approach here. However, I wonder if the situation here is a bit different and if I should try to integrate a script into the build system to generate HardCodedMathData.h?

Some things to consider:

1) These hardcoded data are only expected to be used on platforms that can not read the OpenType MATH table directly. I intend to replace them with direct access to the MATH table in bug 130324, for all but the Mac port. Does anyone think it would be possible to use some font libraries to read OpenType tables on Mac?

2) STIXMath does not have italic correction yet (http://sourceforge.net/p/stixfonts/tracking/50/). So at the moment that will mean bad placement of subscripts attached to displaystyle operator (especially slanted integrals). So the hardcoded data could still be useful in that case (even for fonts that can read the MATH table). However, I think we want to recommend Latin Modern Math as the default, which gives better rendering.

3) The dependencies for the script are Python & its fontforge module.

[chris fleizach]

(In reply to comment #3)
> I discussed that with Martin, and I'd like to get feedback on the right approach. In bug 99620 comment 5, I was told to use a sorted hardcoded constant array to implement the MathML dictionary. So I did the same approach here. However, I wonder if the situation here is a bit different and if I should try to integrate a script into the build system to generate HardCodedMathData.h?

Do you foresee this data changing often (ever?)

> 
> Some things to consider:
> 
> 1) These hardcoded data are only expected to be used on platforms that can not read the OpenType MATH table directly. I intend to replace them with direct access to the MATH table in bug 130324, for all but the Mac port. Does anyone think it would be possible to use some font libraries to read OpenType tables on Mac?
> 

Do you have something in mind already? or are you asking if facilities already exist with platform API to read open type data?

> 2) STIXMath does not have italic correction yet (http://sourceforge.net/p/stixfonts/tracking/50/). So at the moment that will mean bad placement of subscripts attached to displaystyle operator (especially slanted integrals). So the hardcoded data could still be useful in that case (even for fonts that can read the MATH table). However, I think we want to recommend Latin Modern Math as the default, which gives better rendering.
> 
> 3) The dependencies for the script are Python & its fontforge module.

[chris fleizach]

Comment on attachment 226896 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=226896&action=review

> Source/WebCore/platform/graphics/SimpleFontData.h:126
> +    bool hasMathData() const { return m_hasMathData; }

doesn't seem like it's too much of a win to cache this value, and it duplicates hasMathData() in two places (here and in m_mathData->hasMathData())

> Source/WebCore/platform/graphics/opentype/OpenTypeMathData.cpp:91
> +        ASSERT(m_mathFont == STIXMath);

will this fail if your math font is 
m_mathFont = UnknownFont;
if 
m_mathFont = UnknownFont;
is an unexpected state, perhaps you should assert there as well?

> Source/WebCore/platform/graphics/opentype/OpenTypeMathData.h:47
> +    // The order of the constants must match the order of the fields defined in the MATH table.

does the value of enum also matter, or is it only the relative order that matters?

[Frédéric Wang (:fredw)]

(In reply to comment #4)

> Do you foresee this data changing often (ever?)

These data will need to be regenerated when new versions of Latin Modern Math and STIX Math are released, but I think new version of fonts do not happen so often.

Also, if that happens that will break backwards compatibility with old version of the fonts, so that hardcoded data approach is actually not desirable. That's just a first step because I could not find how to do otherwise on Mac but I hope we won't keep that in the long term. I think Apple could ensure synchronization with the font installed on Mac and the hardcoded data in WebKit but that will be a bit tedious.

> 
> > 
> > Some things to consider:
> > 
> > 1) These hardcoded data are only expected to be used on platforms that can not read the OpenType MATH table directly. I intend to replace them with direct access to the MATH table in bug 130324, for all but the Mac port. Does anyone think it would be possible to use some font libraries to read OpenType tables on Mac?
> > 
> 
> Do you have something in mind already? or are you asking if facilities already exist with platform API to read open type data?

I already know that I have an API on Linux (I tested the EFL and GTK ports) and I believe it also works on some Windows version (not tested). This is done in bug 130324 and the flag is #if USE(FREETYPE) || (PLATFORM(WIN) && (USE(CG) || USE(CAIRO)))

I have no ideas if the Mac port of WebKit can handle that and don't have a Mac to test anyway. However, for Gecko I've been able to read the OpenType MATH table using Harfbuzz (used on Mac too). I believe Blink is migrating to Harfbuzz on all platforms and I wonder if there are similar plans for the Mac port of WebKit. Or perhaps anyone knows how to do that with the current Mac API available?

[chris fleizach]

(In reply to comment #6)
> (In reply to comment #4)
> 
> > Do you foresee this data changing often (ever?)
> 
> These data will need to be regenerated when new versions of Latin Modern Math and STIX Math are released, but I think new version of fonts do not happen so often.
> 
> Also, if that happens that will break backwards compatibility with old version of the fonts, so that hardcoded data approach is actually not desirable. That's just a first step because I could not find how to do otherwise on Mac but I hope we won't keep that in the long term. I think Apple could ensure synchronization with the font installed on Mac and the hardcoded data in WebKit but that will be a bit tedious.
> 
> > 
> > > 
> > > Some things to consider:
> > > 
> > > 1) These hardcoded data are only expected to be used on platforms that can not read the OpenType MATH table directly. I intend to replace them with direct access to the MATH table in bug 130324, for all but the Mac port. Does anyone think it would be possible to use some font libraries to read OpenType tables on Mac?
> > > 
> > 
> > Do you have something in mind already? or are you asking if facilities already exist with platform API to read open type data?
> 
> I already know that I have an API on Linux (I tested the EFL and GTK ports) and I believe it also works on some Windows version (not tested). This is done in bug 130324 and the flag is #if USE(FREETYPE) || (PLATFORM(WIN) && (USE(CG) || USE(CAIRO)))
> 
> I have no ideas if the Mac port of WebKit can handle that and don't have a Mac to test anyway. However, for Gecko I've been able to read the OpenType MATH table using Harfbuzz (used on Mac too). I believe Blink is migrating to Harfbuzz on all platforms and I wonder if there are similar plans for the Mac port of WebKit. Or perhaps anyone knows how to do that with the current Mac API available?

Are you going to attempt the Mac side of this? Or do we need to open a bug to track doing that work

[Frédéric Wang (:fredw)]

(In reply to comment #7)
> Are you going to attempt the Mac side of this? Or do we need to open a bug to track doing that work

If we can read the table on Mac, then I think we can forget about hardcoded data, WONTFIX the bug and merge the remaining changes into bug 130324. I'll try to read more about the Mac API first.

The implementation of FontPlatformData::openTypeTable in Mac is actually orthogonal to the MATH font support and could be done in a separate bug. As I understand, this is what is preventing OPENTYPE_VERTICAL to be enabled on Mac and so is causing some test failures. See
https://bugs.webkit.org/show_bug.cgi?id=51450
http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/TestExpectations#L542

[Frédéric Wang (:fredw)]

Created attachment 227391 [details]
Attempt to implement FontPlatformData::openTypeTable on Mac

[Frédéric Wang (:fredw)]

Created attachment 227395 [details]
Attempt 2 to implement FontPlatformData::openTypeTable on Mac

[Frédéric Wang (:fredw)]

Created attachment 227396 [details]
Attempt 3 to implement FontPlatformData::openTypeTable on Mac

[Frédéric Wang (:fredw)]

Created attachment 227397 [details]
Attempt 4 to implement FontPlatformData::openTypeTable on Mac

[chris fleizach]

Comment on attachment 227397 [details]
Attempt 4 to implement FontPlatformData::openTypeTable on Mac

View in context: https://bugs.webkit.org/attachment.cgi?id=227397&action=review

> Source/WebCore/platform/graphics/FontPlatformData.cpp:30
> +#if OS(DARWIN)

OS(DARWIN) might be correct, but my first guess would have been to use
PLATFORM(COCOA)

> Source/WebCore/platform/graphics/FontPlatformData.cpp:32
> +#include <ApplicationServices/ApplicationServices.h>

I think you want to import <CoreGraphics/CGFont.h>
for this usage. That should make it work on iOS as well

> Source/WebCore/platform/graphics/FontPlatformData.cpp:181
> +    CFDataRef data = CGFontCopyTableForTag(font, table);

no need to store CGFontRef font

if (CFDataRef data = CGFont(cgFont(), table))
    return SharedBuffer...

return nullptr;

[Frédéric Wang (:fredw)]

(In reply to comment #13)
> (From update of attachment 227397 [details])

Thanks for the comment. I've moved the changes to bug 130572. And I'll WONTFIX bug 130321 if it turns out that we finally don't need these hardcoded data.

[Frédéric Wang (:fredw)]

WONTFIX since we will directly read the MATH table.