[Pkg-fonts-devel] UW ttyp0 - a multiscript monospaced bitmap font family

Jonas Smedegaard dr at jones.dk
Thu Jul 14 13:49:02 UTC 2016

Quoting Bjørn Mork (2016-07-13 23:04:11)
> Jonas Smedegaard <dr at jones.dk> writes:
> > Your recommendation carry more weight if elaborating more.
> >
> >   * Which alternatives did you compare against and found inferior?
> >   * Which criteria did you focus in in your comparison?
> The 3 best candidates were misc-fixed, adobe-courier and terminus.  I
> didn't set up any well defined criteria, but fired up a number of xterms
> with different fonts and tried out typical operations I do in terminals
> (ls -l, git log -p, dmesg).  Then I made a subjective decision based on
> "feeling good".
> Now I must admit that I don't have the faintest idea about some of the
> numbers in the font names, but I try to keep weight and size pretty
> similar when comparing.

The naming scheme is called "X Logical Font Description" (XLFD): 

> I found "courier" much to wide.

Courier is wide by design, I believe.  Not my style either.

> "terminus" is also a bit wide. It has larger glyphs filling their 
> boxes, but this doesn't make it more legible.  On the contrary.
> The "fixed" glyphs are very low, with lots of space between each line. 
> This makes the text look like it is squeezed flat.  And the extra 
> space is only breaking it up for me, making me read line by line 
> instead of whole paragraphs.  The "fixed" font shows the Japanese name 
> in my "git log -p" test, and that's a nice bonus.
> But I still end up with "ttyp0" as the best one.  It is as compact as 
> "fixed", but with a much better balance between space and letters.  It 
> doesn't do the Japanese name, but I can live without that.  I can see 
> it in emacs :)

Great reflections!  You have done far more detailed inspections than me.

Now if I want to do similar investigation as you, I can choose to avoid 
duplicating your work, to deliberately repeat if what I want is to 
double-check if I agree with your findings.  Point is I understand 
better what led to your conclusions :-)

> > Here's my prioritized list of criteria:
> >
> >   * Speed: Rendering of vector-based fonts is too slow for me.
> >   * Conservative: No slashed zero for me
> >   * Legibility: I like my fonts crisp and relatively large.
> >   * Coverage: I have a glyph fetish but only really need latin chars.
> >
> > I have so far settled for terminus-18, but am curious to learn more how 
> > it compares to alternatives by both objective and subjective measures.
> I'm not as structured as you, but trying to come up with a list:
>  - Legibility: I want to take a quick glimpse at e.g. a code block in 
>    a terminal window, and immediately notice the bug in there
>  - Legibility: The text "breaks up" for me if there is too much space
>    between characters or lines
>  - Compact: No need to waste desktop space

Good points!  The first two I appreciate too, just haven't taken the 
needed time to proper experiment with yet.

As for your third point (and _first_ on my list, just forgotten above): 
Has to be large enough to not stress my eyes too much.  For my eyes, and 
the (typically 14" laptop) screens I use, and Terminus font, that means 
18x18 pixel size.

I like compact too so would love to find a font not stressing my eyes at 
16px or smaller sizes.

> I don't care so much about speed.  I don't think I'll ever notice much 
> difference.

Let me elaborate on my interest in speed: I use a tab window manager, 
and often switch between multiple fullscreen windows - e.g. one with my 
curses-based email program and another with my curses-based editor.

I noticed that depending on choice of terminal emulator and font, 
redrawing when switching screen was done either "instantly" or visibly 
"drawing lines" for up to several seconds.

What I use now is something¹ like this:

  urxvt -fn terminus-18 -fb terminus-bold-18

which gives me that "instant" redraw.

¹ I also save memory by using urxvtcd, and I declare fonts by use of a 
file below /etc/X11/Xresources containing "Rxvt*font: terminus-18" and 
"Rxvt*boldFont: terminus-bold-18".

> As for coverage: I work mostly in latin1, but sometimes need to cut 
> and paste some Chinese or Japanese names (for e.g. tags in kernel 
> changelog entries).  So the ability to view letters I don't 
> necessarily read or understand is on my wishlist.  But it is not the 
> highest priority.  Most of the time you get it right if you cut and 
> paste a few squares instead ;)

Our coverage needs are similar.  Others clearly have different needs, 
however - and ideally I would like to identify and map variety of needs 
for automating optimized setups of Debian. E.g. users in Taiwan would 
probably prioritize a) legibility of CJK glyphs, and b) traditional 
chinese over other CJK glyph flavors. Users in India might favor 
OpenType-based rendering over network-capable bitmaps due to its support 
for dynamic composition of glyphs (Vasudev or others: please correct me 
if wrong!).

Not sure about xterm, but Urxvt supports declaring not only a single 
font to use but a prioritized lookup table.

I have (just now) extended my setup to cover "exotic" glyphs, like this:

  urxvt -fn terminus-18,-efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1 -fb terminus-bold-18,-efont-fixed-bold-r-normal--16-160-75-75-c-80-iso10646-1

According to "OPEN ISSUES" in /usr/share/doc/xfonts-unifont/README.gz, 
CJK users might include xfonts-wqy.

Not sure why but I couldn't make unifont work as a final fallback 
(pixelated but almost full Unicode coverage).

By the way: "man 7 urxvt" mentions how urxvt was written particularly to 
fine-tune font choices - and that the author finds Terminus "quite bad" 
but useful for his use as "bold" font only.

> >> > What I found that seemed reasonably active maintained and 
> >> > comparative (i.e. not slashdot-style) was 
> >> > https://github.com/powerline/fonts which doesn't even mention tty0.
> >> 
> >> Yes, there are lots of such good lists.  The problem for me was that 
> >> they "only" recommend Xft solutions.  Which is natural since most use 
> >> cases are limited to the client and server running on the same host.
> >
> > Your ruling out Xft sounds like our needs are related.  I am eager to 
> > learn more!
> I don't know if I'm able to describe it in words.  It's an extremely
> subjective "this looks good to me". terminus is an usable alternative.
> I want to fit as much as possible into a relatively small 14" laptop
> screen. So terminus-16 would be the size I preferred with a 2560x1440
> resolution.  And that is sort of usable.  But I think
> -uw-ttyp0-medium-r-*-16-*-iso10646-1 is even better.  It looks less
> "messy". I think some of that comes from different digit design, where
> terminus digits have more "square" corners.  And the terminus 0 looks
> similar to Ø instead of O.  I believe the / only add noise in a small
> font.  Details.
> In a way, all the terminus glyphs seems to be constructed as "rectangles
> with rounded corners.  Look at the V for example.  It's almost U in
> terminus, while it is two straight lines in ttyp0. Being a complete
> amateur here, but I'd say that emphasizing the natural differences
> between glyphs helps a lot if you want to make a font that is easy to
> read. I understand that you have to apply some common pattern to make a
> font a font, but there is a very fine line between applying the common
> pattern and making every glyph look the same...
> FWIW:  I am using Inconsolata-12 in emacs, where I don't mind freetype.
> I'd use it in terminals too, if I only did local terminals.

With rxvt-unicode I beleive you could list Inconsolata first, and it 
would simply be skipped for environments where not available, like this:

urxvt -fn Xft:Inconsolata:pixelsize=16:autohint=true,-uw-ttyp0-medium-r-*-16-*-iso10646-1,terminus-16,-efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1 

...or an equivalent Xresources file.

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20160714/b007f88a/attachment.sig>

More information about the Pkg-fonts-devel mailing list