[Top][All Lists]

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

Re: [Freefont-bugs] a comparison of FreeMono.ttf versions of 2003-06-24

From: Primoz PETERLIN
Subject: Re: [Freefont-bugs] a comparison of FreeMono.ttf versions of 2003-06-24 and 2008-03-24
Date: Thu, 3 Apr 2008 10:43:53 +0200


2008/4/2, Joe Wells <address@hidden>:
>  • The vertical spacing is screwed up (at least in xterm).  This causes
>   two problems:
>   ‣ Each line takes up too much vertical space, so fewer lines can be
>     displayed, which is a big problem on short screens.
>   ‣ Characters that are supposed to combine vertically like "⎪"
>     (U+23AA, CURLY BRACKET EXTENSION) have gaps between them.
>   For the
>   same reason, I have previously refused to upgrade to FreeFont.ttf
>   versions of 2003-10-08 and 2006-01-26.  Due to this problem, right
>   now upgrading would actually be a downgrade.

As you have correctly observed, this change to the worse has happened
well before Steve's management. At some point in the history,
FontForge decided - probably motivated by a stricter conformance to
the TrueType specifications - that when converting to TrueType, it
will write into the font the actual height of the font instead of the
declared one (i.e., from -200 to 800 units in case of FreeMono). Since
we have several glyphs reaching beyond the declared limits, this
actually prevents the glyphs from overlapping. On the other hand,
since the characters used in vertical combining reach exactly to the
limits and not beyond, this also means that they have gaps between

>  • Something awful is happening with combining accents.  You can see in
>   the screenshot in the test line "STARGΛ̊TE SG-1, a = v̇ = r̈, a⃑ ⊥ b⃑"
>   that the combining accents (when they are drawn at all) are all
>   positioned one character cell to the left of where they should be.
>   This was working in the font as of 5 years ago, so presumably this
>   is a bug introduced since then.

I believe this also has to do something with the change of
specifications in the meantime. The combining characters have negative
horizontal coordinates, i.e., they are not drawn inside the character
cell, but in the place where the previous character would be, when the
text is typeset. This seemed like a good idea back in 2003, as it
resulted in the intended result, but apparently it no longer conforms
to the specifications.

Best wishes, Primož

reply via email to

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