freefont-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freefont-bugs] Large rectangle with stretchy U+2F/U+2211/U+27E8/U+2


From: Frédéric Wang
Subject: Re: [Freefont-bugs] Large rectangle with stretchy U+2F/U+2211/U+27E8/U+27E9 and GNUFreeFont
Date: Fri, 17 Apr 2015 17:34:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0

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 via email to

[Prev in Thread] Current Thread [Next in Thread]