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

[Steve White]

Joe,

On Sun, Apr 6, 2008 at 1:08 AM, Joe Wells <address@hidden> wrote:
> "Steve White" <address@hidden> writes:
>  >
>  > As I said, you have an application that doesn't work with the changes
>  > in question.
>  > That's enough for me.
>
>  Viewing things on a screen is just an "application"?  Are you saying
>  you are only concerned with printing on paper?  Sorry, but I am
>  confused.
>
Viewing things in an xterm is an application.  In terms of users, very
few users do this.  Mostly they use GUI applicatons.  It's true, have
a look around.

Line-drawing in an xterm is a quite specific application.

I am working toward making FreeMono better suited for xterm applications.

>  Is it possible to get a version of the font that lies about its height
>  for use by people who don't mind tall glyphs getting truncated?  Or is
>  there some way to lie after the .ttf file is created?
>
Near as I can tell, xterm checks the max and min points of the glyphs
in the font.
It doesn't seem to use the OS/2 height parameters, as most other
applications do (in different ways, unfortunately.)

There is a misty memory of an xterm parameter called "minspace".  Near
as I can tell, it would be used like this:
xterm -fa monospace-11:minspace=true
But I have tried it, and I have never seen it work.

And, to repeat the obvious: FreeFont is...free.  You can edit to your liking.

>  >>  > 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.
>
>  This is interesting!
>
>  I just tested again with DejaVu Sans Mono.  Here is the screenshot:
>
>
>  You can see that Λ̊, v̇, and r̈ are handled correctly, while a⃑ and b⃑ are
>  not (presumably because the combining character ⃑ is missing from the
>  font).
>
>  I ran xterm under strace and verified that it only accessed these two
>  font files:
>
>   open("/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf", O_RDONLY) = 
> 6
>   open("/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Bold.ttf", 
> O_RDONLY) = 6
>
>  (Although this may have changed in recent xterm versions, I know that
>  in my (older) xterm version that it is not capable of mixing fonts
>  together, so there is anyway no possibility of it getting supporting
>  characters from other fonts.)
>
>  On my system (Ubuntu Dapper Drake), the above-mentioned .ttf files are
>  from DejaVu version 2.5
>
That is indeed interesting.  I'll have to get the newer DejaVu, and
see what they're doing.

I have the dejavu 2.19 packages...  Hey...my system is Gutsy.  How
come you have newer DejaVu?

>  So maybe more recent versions of DejaVu have the same problem.
>
>  I seem to remember having precisely this discussion with the xterm
>  maintainer a couple of years ago.  I do not precisely remember the
>  resolution of the issue.  I seem to remember that he agreed that xterm
>  should not consider the presence of 0-width characters to spoil
>  whether a font is fixed-width.
>
It seems reasonable to me.  But I'm sure some people have not
considered this point when writing their apps.

It will be a judment call in the end...if I can get away with 0-width
glyphs in enough of the apps I consider important, I'll implement the
combining diacriticals.  But it will take some time to test.

>  >>  • 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.
>
>  Are you saying you in fact know of a way that users can tell
>  applications to use this font with smaller vertical line spacing?
>
I know ways in many applications.

In CSS-savvy web browsers, you can set the line height to 1, which
makes them pay attention just to the height parameters in the font.
In word processors, there is always a line height adjustment.

In xterm, as I have said, I don't have a solution.  But as I have
said, I'm doing what I can to fix the font.  It will take time.

I'm also working on docs, but that also takes time.

>  On my system, URW Nimbus Mono comes in the gsfonts package and it is
>  available under the name "Nimbus Mono L".  For your amusement, here is
>  the truly awe-inspiringly awful screenshot of the test with this font:
>
> Unfortunately, as you can see, Nimbus Mono L has quite bad problems
>  with using too much vertical space, and has a quite small character
>  repertoire.
>
Sorry about the vertical space.  I had assumed the scarcity of
characters would deliver narrow line spacing, but I was wrong.  Beats
me.

>  >>  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.
>
>  Well, I will continue to seek a font with decent Unicode coverage
>  (including the Greek alphabet, math symbols, superscripts, subscripts,
>  and combining accents) that displays nicely in a terminal window.
>
Stay tuned!