[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
Re: [Freefont-bugs] a comparison of FreeMono.ttf versions of 2003-06-24 and 2008-03-24
Thu, 03 Apr 2008 14:48:27 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
"Primoz PETERLIN" <address@hidden> writes:
> 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
There are two issues here:
① Whatever the height of the font is, the glyphs for line-drawing
characters should correctly combine vertically. (It would be nice
if FontForge would automatically check this for line-drawing
② It would be _really_ useful if the font was not as high vertically
so that more lines can be displayed when the font is used in
terminal windows. I would be happy if the font lied about its
height to achieve this, because I am unlikely to ever see the glyphs
that use the full height. If I occasionally do see these glyphs, I
would rather see them overlapping a bit than have every line on the
screen take 2 extra pixels vertically. Is there a way to achieve
what I want? For example, can I somehow lie to Xft about the height
of the font when I tell xterm to use this font? Or do I need to
embed the lie inside the .ttf file?
>> • 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.
It sounds like you are saying FontForge now generates different
contents in the .ttf file for the same original source. I suppose
then that this is just on ordinary bug to be fixed.
Thanks for replying to my message!
Heriot-Watt University is a Scottish charity
registered under charity number SC000278