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

[Steve White]

Joe,

On Fri, Apr 4, 2008 at 5:13 PM, Joe Wells <address@hidden> wrote:
> "Steve White" <address@hidden> writes:
>
>  > 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.
>
As I said, you have an application that doesn't work with the changes
in question.
That's enough for me.

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

It is unfortunately quite unclear, and this is not only my opinion.
It is clearly the fault of the people who invented the standards.
They fouled it up.

>  However, other fonts work much more nicely with
>  xterm, so it is clearly possible to get the nice behavior.
>
That's right.  As I have explained elsewhere, the root of the problem
is that several ranges of characters in FreeFont have very high and
very low glyphs.  This plus the above-lamented foul-up puts us in a
difficult position.

The goal of the FreeFont project is to incorporate as many useful
Unicode ranges as possible.
If it is important for these ranges to be in FreeFont, it is important
that they should display properly.  The most effective way of
consistently setting a narrow line height for the font has the effect
of truncating these glyphs in many applications.

I don't have an immediate solution.  My feeling is, all characters in
a font should fit into some reasonable bounds.  But even many accented
Latin characters don't.

>  > 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 just tried this.

In my xterms, on my Ubuntu gutsy system, DejaVu Sans Mono also doesn't
work on your combining diacriticals test.  I opened it up with
FontForge.  It works the same way FreeFont does.
Lucida Sans Typewriter doesn't have combining diacriticals in the
range in your example.  Something is probably pulling these out of
other fonts on your system.  (However, it does contain glyphs of zero
width: combining marks in Hebrew, it seems...)
I don't have CMU Typerwriter Text...
I have a Windows system...and here's Courier New.  And it seems to
have glyphs of all uniform width, and it doesn't work with your
example.

And...your example also doesn't work with FreeFont of the last 2006 release.
But it does work with the 2003 release.

So now it is clear to me what is going on.  The combining diacritic
glyphs in the 2003 release are of zero width, as in the Serif and Sans
faces.  The more recent releases have glyphs all of a single width.

I can make combining diacritcs work by making them zero width, as in
the other faces.  But a decision was made years ago in FreeFont that
this was a bad idea, that unless the characters were all the same
width, it would not be regarded as a fixed-width font by many
applications that require fixed-width fonts.

It has occurred to me that these applications may accept a font that
has all characters of a single width, except perhaps a few of width 0.
 But this will take some testing to determine.

>  Sadly, my time is vastly overcommitted, so this message is likely the
>  last you will hear from me.
>
I'm overcommitted too.  But this is one of my little commitments, for now.

>  • Document a way (if there is one) that users can tell applications to
>   use this font with a smaller vertical line spacing.
>
If you look at the bug pages, you will see that I document like crazy.
 I'm also working on an overhaul of the main pages.  It will all be
there.

>  • 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.
>
There is URW Nimbus Mono, on which the Latin ranges of FreeMono are based.

>  I have the same issue in text editors: the number of lines that can be 
> displayed is crucial.
>
That is an interesting viewpoint, and I take it seriously.
But once again, compactness isn't the main goal of this project.

Thanks again!  Hope you find more time soon!