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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

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

Jonathan Kew
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


Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

Khaled Hosny
In reply to this post by Frédéric Wang
On Fri, Apr 17, 2015 at 05:07:31PM +0200, 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

AFAIK, The only times TeX (and by extension OpenType math implemenation)
use rules is for radical and fraction bars, everything else is done
using glyph variants and/or repeatable parts. If the font does not
provide the required glyphs no stretching happens.

Regards,
Khaled

Reply | Threaded
Open this post in threaded view
|

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

Khaled Hosny
On Fri, Apr 17, 2015 at 05:29:39PM +0200, Khaled Hosny wrote:

> On Fri, Apr 17, 2015 at 05:07:31PM +0200, 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
>
> AFAIK, The only times TeX (and by extension OpenType math implemenation)
> use rules is for radical and fraction bars, everything else is done
> using glyph variants and/or repeatable parts. If the font does not
> provide the required glyphs no stretching happens.

The p.225 of TeXbook referenced in the code talks about how plain TeX
fakes stretchy over and under braces since TeX did not support
horizontal stretching, so IMO this has no place in an implemntation that
does not suffer from this limitation.

Regards,
Khaled