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

[Joe Wells]

"Steve White" <address@hidden> writes:

> Hi, Joe!
>
> Thanks for the comments,  and thanks A LOT for the test case (can I
> put it on the web page?)

Please feel free to do so.  For information: it is derived from Markus
Kuhn's UTF-8-demo.txt, plus some stuff of my own.  Basically, I packed
the most interesting portions of UTF-8-demo.txt into 30 lines and 130
columns so that I could compare terminal fonts side by side.  I also
added a bunch of characters I personally like to use.  I suppose I
have some copyright interest in it (although so does Marcus Kuhn), so
I hereby license everyone in the world to use it as they see fit.

> It seems to me that you have three main complaints:
>
> 1) You disapprove of the increased line spacing (explained in the release 
> notes)
>     You have two applications of a certain spacing that don't work
> with the increased spacing

The word “disapprove” misses the point.  Taking 2 extra pixels
vertically per line is a complete show-stopper for me.  If the font
wastes space like that, it does not matter how nice the font is
otherwise.

An important point:  It is not completely clear how applications are
supposed to decide how much vertical space to allocate per line when
using a font.  Part of the blame here may be with xterm.  I've
previously (I think about 2 years ago) communicated with the xterm
maintainer and also the DejaVu team about this, and they seemed to
think it was unclear how things are supposed to work regarding
vertical spacing.  However, other fonts work much more nicely with
xterm, so it is clearly possible to get the nice behavior.

> 2) Combining accents don't work as you expect

Not only do combining accents not work as I expect, they are currently
completely broken and do not work as anyone should expect.  Or at
least they are completely broken in xterm.  Since all other fonts that
support combining accents that I can test right now work with xterm
(e.g., DejaVu Sans Mono, Lucida Sans Typewriter, CMU Typewriter Text),
I think it is safe to conclude that something is quite wrong inside
FreeMono.ttf.

> 3) You don't like the new glyphs for the curly quotes

It is not that I dislike the new glyphs, but rather that I *really*
*like* the old glyphs.  The old glyphs are *extremely* *clear* and
unambiguous, especially at small font sizes.  I also think the old
glyphs are good looking, but my main concern was readability.

> I would encourage you to submit individual bug reports on these. That
> way, you can track the progress of changes, and interact with the
> developers (me, at this time).

Sadly, my time is vastly overcommitted, so this message is likely the
last you will hear from me.

> (Try to be as descriptive, and avoid emotional remarks such as
> "screwed up".  It will get things done faster.)

Taking 16.5% more space vertically and also breaking line drawings is
awful.  The phrase “screwed up” is a greatly toned down version of my
true thoughts.  I'm sorry if it makes you less than happy.  I have no
intention to offend.  Maintaining freefont is a big job and I am
delighted to see what you have accomplished in your brief time doing
it.

> I don't have complete answers to all your complaints, but I have
> looked at your test case.
>
> Concerning (1): Line spacing is a big problem in this family, due to
> character ranges whose glyphs are very high and low.  Furthermore, the
> standards (to the best of my understanding), are rather weak on the
> point of line spacing (as opposed to font height, etc.) What I have
> done represents a compromise, that vastly improves the behaviour of
> the fonts for most purposes, but screws up certain applications.
>
> On the other hand, I see your problem, and intend to do something about it.

I'm delighted to hear this.  Here are some ideas:

• Document a way (if there is one) that users can tell applications to
  use this font with a smaller vertical line spacing.

• Provide a way to get a version of the font which lies about its
  vertical space or which omits the very tall glyphs, so that lines
  will take less vertical space.

> Frankly, I wasn't  aiming for xterm use.  I was primarly looking at
> text editors, web browsers, and word processors.  I did test it in
> xterm, but never even thought about line- and shape-drawing
> applications.

I have the same issue in text editors: the number of lines that can be
displayed is crucial.

> Complaint (2) may be a case of me completely failing to understand how
> combining characters are supposed to work in a monospace font.  I was
> hoping to achieve glyphs that appeared over the preceding one, and
> took up no space themselves.  But I never got it to work (and I
> thought the old version wasn't working either).

I'm not sure in precisely which version of FreeMono.ttf combining
accents stopped working.

> I'll have another look at this, with your examples.
>
> With regard to (3),  the old glyphs were incorrect, and made the font
> useless for many of its stated purposes.
> See bug#18300, https://savannah.gnu.org/bugs/index.php?18300

Arrgh, that bug report contains bad news for me.  So the left double
quote mark is _required_ to have this shape?!?!  That sucks.  They
should have made a separate Unicode character for the German right
double quote mark.  I suppose the only way I will be able to get
decent behavior will be to switch exclusively to using DOUBLE
HIGH-REVERSED-9 QUOTATION MARK for English and abandon LEFT DOUBLE
QUOTATION MARK forever.  But that will only work for text I write
myself; the text I get from others will have the poor display.  This
sucks.  Arrgh.  (Not your fault!  My complaint is with Unicode.)

> I based my glyphs on the comma, which is consistent with Uncode.  Is
> the comma also ugly?

In fact, it seems that alternate names for the characters in the
standard are DOUBLE TURNED COMMA QUOTATION MARK and DOUBLE COMMA
QUOTATION MARK, so you are (unfortunately in my opinion!) correct.  ☹
:-(

> If you can make suggestions for better glyphs, I would be glad to
> entertain them.

No, it seems the problem is with the standard.

It would be nice if there was some way that people like me could
select the nice glyphs and not get the standard glyphs.

> You went on to talk about hinting and anti-aliasing.  This is not so
> much a font issue.  The font can turn these processes off
> (accidentally), but there is little a font developer can do about it.

Actually, the solution is probably to do the hinting by hand.  The
problem is that this is very labor intensive and requires extremely
specialized expertise from the person doing the hinting.  The reason
why proprietary commercial fonts have nice hinting for all their
characters is that they pay people to do this kind of drudge work.

> They depend very heavily on the algorithms used by the various
> releases of the various graphics packages of the various operating
> systems.  The newer FontForge does a better job of auto-hinting than
> previous versions; this may be part of the change you see.

I can only hope that autohinting will get better.  However, I suspect
that some characters will always need to be hinted by hand.

-- 
With my best regards,

Joe

> Cheers!
>
>
>
> On Wed, Apr 2, 2008 at 6:40 PM, Joe Wells <address@hidden> wrote:
>> To compare the latest FreeMono.ttf with earlier versions, I have run
>>  the command
>>
>>   xterm -title FreeMono-8 -geometry 130x32+0+0 -fa FreeMono-8 +fbx -e sh -c 
>> "echo ${ESC}%GFreeMono-8; head -n 30 UTF-8-font-test-sample.txt; sleep 99999"
>>
>>  with the versions of FreeMono.ttf of 2008-03-24 (latest release) and
>>  2003-06-24 (five years ago).  (The variable ESC holds a string of
>>  length 1 whose sole character is the escape character.)
>>
>>  I was running on a LCD with (I believe) rgb subpixel order with
>>  subpixel aliasing turned on.
>>
>>  Screenshots are attached below, as is the sample text file I used.
>>
>>  Here are some quick observations:
>>
>>  • More characters are included.  Hurray!
>>
>>  • Hinting is a bit nicer in the latest fonts.  I can see many
>>   individual characters (like I, N, 1, 4, etc.) that have better
>>   subpixel aliasing and come out looking black instead of colored.
>>
>>   I'm pleased to see this progress and I think the maintainers deserve
>>   congratulations.
>>
>>  • There are still plenty of characters that get bad subpixel aliasing
>>   and therefore show up with colored fringes.  Examples include ℝ, ░,
>>   ⊪, etc.  I guess there is lots of work to do here with hinting.
>>   (Can the autohinter handle these decently?)
>>
>>  • 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.
>>
>>   This problem does not occur in the font as of 5 years ago, as you
>>   can see for yourself in the screenshot.  (I think the problems in
>>   the older screenshot are caused by xterm drawing the line-drawing
>>   characters instead of using what is in the font.)
>>
>>   By itself, this is a big enough reason to keep using the old font.
>>   The number of lines that will fit on a screen is a primary criteria
>>   used when selecting a font for terminal windows, and the ability to
>>   display line drawings correctly is also very significant.  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.
>>
>>  • The older glyphs for the quote characters (i.e., ', ", ", ') are
>>   much nicer for a screen font.  It would be nice to be able to get
>>   the old glyphs somehow.
>>
>>  • 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.
>>
>>  For what it is worth, I am running Ubuntu 6.06 LTS ("Dapper Drake")
>>  and I think all packages involved in this test are the latest
>>  available for Ubuntu 6.06.
>>
>>  I hope this report is helpful.
>>
>>  Joe Wells
>>


-- 
Heriot-Watt University is a Scottish charity
registered under charity number SC000278