Large rectangle with stretchy U+2F/U+2211/U+27E8/U+27E9 and GNUFreeFont

[Frédéric Wang]

Hi all,

Here is a testcase with a dev version of GNUFreeFont:
http://fred-wang.github.io/MathFonts/GNUFreeFont/

As I understand, stretchy U+2F/U+2211/U+27E8/U+27E9 do not have a "glue"
so we connect them using a rule

https://dxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLChar.cpp#855

but the rule thickness has the width of the parts, which leads to these
ugly large rectangles.

What do you think? Is it a bug due to our limited implementation of the
MathVariants table (bug 963147)? Or is it incorrect for a font to
specify a stretchy operator construction without any extender?


--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

[Frédéric Wang]

Thank you for your reply, Jonathan.

So I think GNUFreeFont should remove these constructions and perhaps
group them into one largest size variant.

Le 17/04/2015 17:29, Jonathan Kew a écrit :

> On 17/4/15 16:07, Frédéric Wang wrote:
>> Hi all,
>>
>> Here is a testcase with a dev version of GNUFreeFont:
>> http://fred-wang.github.io/MathFonts/GNUFreeFont/
>>
>> As I understand, stretchy U+2F/U+2211/U+27E8/U+27E9 do not have a "glue"
>> so we connect them using a rule
>>
>> https://dxr.mozilla.org/mozilla-central/source/layout/mathml/nsMathMLChar.cpp#855
>>
>>
>> but the rule thickness has the width of the parts, which leads to these
>> ugly large rectangles.
>

> I don't see how a rule of *any* thickness would look good in the
> middle of a character such as / or ∑. See below...

>
>>
>> What do you think? Is it a bug due to our limited implementation of the
>> MathVariants table (bug 963147)? Or is it incorrect for a font to
>> specify a stretchy operator construction without any extender?
>

> ISTM this is incorrect. The spec[1] says that glyph assemblies are
> used by:
>
> 1. Assemble all parts by overlapping connectors by maximum amount, and
> removing all extenders. This gives the smallest possible result.
>
> 2. Determine how much extra width/height can be distributed into all
> connections between neighboring parts. If that is enough to achieve
> the size goal, extend each connection equally by changing overlaps of
> connectors to finish the job.
>
> 3. If all connections have been extended to minimum overlap and
> further growth is needed, add one of each extender, and repeat the
> process from the first step.
>
> Step 3 here implies that at least one extender glyph should exist in
> the assembly. Otherwise, it cannot be extended beyond the maximum size
> achieved by step 2.
>
> Note also that extension can only happen, AFAICT, in a straight
> vertical or horizontal line. It doesn't look possible to extend
> diagonals; and therefore only variant glyphs, not extensible
> assemblies, should be used for characters such as slash or Sigma.
>
> JK
>
>
> [1] http://www.microsoft.com/typography/otspec/math.htm
>
>


--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic