Bug 130327 - Support arbitrary number of parts for GlyphAssembly
Summary: Support arbitrary number of parts for GlyphAssembly
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: MathML (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 130322 155434
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-17 03:15 PDT by Frédéric Wang (:fredw)
Modified: 2016-06-28 11:17 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Wang (:fredw) 2014-03-17 03:15:40 PDT
Bug 130322 allows to use the data from the GlyphAssembly table. A RenderMathMLOperator::getGlyphAssemblyFallFack function provides a fallback to the format currently supported by RenderMathMLOperator (top/extension/bottom and middle pieces).

However, the GlyphAssembly is more general. In particular it can contain arbitrary number of pieces. Although, I don't think there are MATH fonts that need more that what is currently supported by RenderMathMLOperator, it would be nice to allow the general format.
Comment 1 Frédéric Wang (:fredw) 2016-06-28 11:17:53 PDT
The number of repetition *for each* extender part was limited to 128 in bug 155434.

If we support an arbitrary number of parts (thus extender parts) then the limit should instead be set on the number of glyphs *for the whole assembly*.

This blog post explains how to implement generic support for the GlyphAssembly sub-table and in particular to calculate (before painting) the number N of glyphs necessary (and so to set a limit N_max): http://frederic-wang.fr/opentype-math-in-harfbuzz.html

When the limit is exceeded, we currently just leave a big gap. In bug 155434 comment 6 it was suggested to evenly distribute the gaps. I would instead suggest to just limit the number N of glyphs (and as a consequence to limit the stretch size) before painting them.

The blog post gives a reference to an implementation in progress for HarfBuzz. I think it makes sense to use the text drawing (MathOperator class) as well as MATH table parsing (OpenTypeMathData class) from such library. In particular for WebKit ports using HarfBuzz (such as GTK) we should probably consider reusing HarfBuzz's MATH support when ready.