Re: [font-metrics-api] font data versus typographic layout results

Hi,

As promised on the DPUB TC last week, I wanted to add more details on the
use case of mathematical layout.

For good mathematical layout, you need tight bounding boxes for all of the
characters being used.  (For completeness: i.e., each character has an
individual height and depth that it uses, so that an "x" and a "k" have
different heights, and an "x" and a "y" have different depths.)

The ascent and descent in Alan's proposal appear to be the font-wide ascent
and descent values, which would give the same value for the "x" and "k" and
the "x" and "y", and so would not be suitable.  For example, in TeX,
\sqrt{x} and \sqrt{k} have the square-root symbol positioned differently;
but, e.g., in Firefox's native MathML support (which used font-wide height
and depth values), they square root over the x is too high.



Similar issues arise for positioning of super- and subscripts, and so on. Taken
in isolation, this difference appears negligible but they quickly add up
enough to disrupt the layout.

MathJax also uses the width of the characters (which can be inferred from
taking measurements of the container elements), but also uses left- and
right-bearing (they are also given in terms of advance-width versus
width).  These indicate where the actual ink is for the glyph, which can
extend outside the width (the most extreme example is an integral sign
which often extends far to the right of the width, so that the integrand
will be spaced properly).  The character can also have left- and
right-bearing that falls inside the width (i.e., the width can have spacing
built into it).  MathJax needs to know the actual width without that
spacing in several instances, including when positioning accents (hat,
tilde, arrow etc) over characters (to get the centering correct), and when
creating horizontal stretchy characters from multiple parts (so that the
overlaps are handled properly).  The width value inferred from measurement
is not enough to do this.

The proposal to provide metrics for a given line box are not going to help
MathJax in this, as they appear to be font-wide (if I put only an "x" in
the line box and get is measurements, and then a "y" from the same font, I
expect that I will get the same values for both), and they don't include
all the data that is needed (the left- and right-bearing).

As Chris says, we would have to use the line box values to infer the
metrics that we actually need, and that is both fragile and expensive (it
causes reflow currently).  MathJax already does this in some situations,
and it is one of the major sources of performance problems.

Again, this is only meant to supply more details for this use case. As
mentioned earlier, Alan's proposal would also provide some benefits for
math layout (the baseline information in particular).

Best regards,
Peter





On Fri, Aug 14, 2015 at 4:26 PM, Alan Stearns <stearns@adobe.com> wrote:

> On 8/14/15, 4:46 AM, "Chris Lilley" <chris@w3.org> wrote:
>
> >Hello Alan, Peter
> >
> >(again apologies for the delayed reply)
> >
> >Thursday, July 30, 2015, 4:23:09 PM, you wrote:
> >
> >> On 7/30/15, 7:15 AM, "Peter Krautzberger"
> >><peter.krautzberger@mathjax.org>
> >>>It looks like this would provide some global font metrics, but not the
> >>>metrics of individual characters/strings. Is that correct?
> >>>
> >>>That would be helpful, particularly the baseline information, but it
> >>>would not be sufficient for a use case like mathematical layout.
> >
> >> Not global - it’s giving the results from the first line box.
> >
> >Would there be a way to iterate over the line boxes, under your
> >proposal?
>
> There are ways of iterating through fragments in the box tree API.
>
> >
> >>  But you are
> >> correct, this would not be sufficient for mathematical layout. It’s a
> >>step
> >> towards what you need, satisfying simpler use cases.
> >
> >I agree it might satisfy simpler use cases, but unless it is
> >extensible to cover the mathematical layout use case it is not a step
> >towards enabling it - it is a step in a different direction that does
> >not address the use case.
>
> I’m assuming we’ll come up with something like a DeadRange that also
> supports returning some DeadFontMetrics. With sufficiently small ranges
> you can sample the typographic layout results for single glyphs, which is
> another step closer to what’s needed for mathematical layout. We’d need to
> add width or advance information, which would be a simple addition to
> DeadFontMetrics. I expect there will be a few more things to add, but I
> think there’s a way to get to everything that’s needed for mathematical
> layout.
>
> Thanks,
>
> Alan
>
>