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:
>> As I understand, stretchy U+2F/U+2211/U+27E8/U+27E9 do not have a "glue"
>> so we connect them using a rule
>> 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 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.
>  http://www.microsoft.com/typography/otspec/math.htm