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

[Steve White]

Hi, Joe!

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

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

2) Combining accents don't work as you expect

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

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).
(Try to be as descriptive, and avoid emotional remarks such as
"screwed up".  It will get things done faster.)

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.

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.

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'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
I based my glyphs on the comma, which is consistent with Uncode.  Is
the comma also ugly?
If you can make suggestions for better glyphs, I would be glad to
entertain them.

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.
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.

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
>