[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: Joe Wells
Subject: Re: [Freefont-bugs] a comparison of FreeMono.ttf versions of 2003-06-24 and 2008-03-24
Date: Thu, 03 Apr 2008 14:48:27 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

"Primoz PETERLIN" <address@hidden> writes:

> Hello,
> 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
> them.

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

reply via email to

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