Bug 15381 - Bad metric in lucidatypewriter font
Bad metric in lucidatypewriter font
Product: xorg
Classification: Unclassified
Component: Fonts/BDF
7.2 (2007.02)
Other All
: medium normal
Assigned To: Markus Kuhn
Xorg Project Team
Depends on:
  Show dependency treegraph
Reported: 2008-04-07 01:47 UTC by Jan "Yenya" Kasprzak
Modified: 2008-04-08 09:20 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

encodings-1.0.0-encodings-fontdir-fix.patch (540 bytes, patch)
2008-04-08 01:24 UTC, Matej Cepl
no flags Details | Splinter Review
font-alias-1.0.0-fonts-alias-fontdir-fix.patch (512 bytes, patch)
2008-04-08 01:24 UTC, Matej Cepl
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jan "Yenya" Kasprzak 2008-04-07 01:47:54 UTC
Description of problem:
The "Numero sign" (U+2116, №) glyph in the LucidaTypewriter font has double
width, but its metric says that it is a single-width character. This causes
incorrect rendering of the text containing this character in the
LucidaTypewriter font - tne right part of Numero sign gets overwritten by subsequently rendered characters.

Version-Release number of selected component (if applicable):
If I can map this font to the package name, I think it is (at least)
xorg-x11-fonts-100dpi-7.1-2 from Fedora Core 6, up to 
xorg-x11-fonts-100dpi-7.2-3 from Fedora 8, which is the latest one I have.
I am not sure how this maps to Product and Component names in the fd.o bugzilla.

How reproducible:

Steps to Reproduce:
$ gconftool-2 --set /apps/gnome-terminal/profiles/Default/font \
     -t string 'LucidaTypewriter 12'
$ gconftool-2 --set /apps/gnome-terminal/profiles/Default/use_system_font \
     -t bool false
$ Xvfb :5 &
123' gnome-terminal &
$ xwd -display :5 -root -out x.xwd
$ xwud -in x.xwd
Actual results:
The numero sign is rendered as a double-width character, but because the metric
says it is single-width, the adjacent character "X" overwrites part of it.

Expected results:
Either the numero sign glyph should have a single width (most other monospaced
fonts have this), or the metric should be updated to reflect the actual double
width of the character.

Note: this bug has been originally reported in Red Hat bugzilla:
- I am trying to move it upstream. In that bugzilla entry there are also several screenshots documenting this bug.
Comment 1 James Cloos 2008-04-07 12:13:05 UTC
I cannot find a U+2116 NUMERO SIGN (№) glyph in the Lucida Typewriter bdf fonts as found in the xorg git repos.  In fact, I don’t see *any* Cyrillic glyphs, and no iso8859-5 subsets get installed.

So, either Fedora patches the BDFs or this is a font substitution issue.

Do you see the character in apps which use server-side fonts?

You can test the glyph coverage of all of the versions of said fonts which are configured for server-side rendering with this:

:; xlsfonts|egrep typewriter.+10646|sort -u|xargs -n 1 xfd -fn

Leave out the «.+10646» to test each of the subsets as well, or use «.+8859-5» to test the ISO8859 Cyrillic glyphset.

Note that is is typical for character-cell targeted apps like terminal emulators to use the metrics of the first specified font to specify the character cell and, when glyph substitution occurs, to shoehorn the foreign (to the first-specified font) glyph into the cell.  This will either result in overlap or on squished glyphs if the substitute glyph is wider than the cell.  I bet gnome-terminal is grabbing the glyph from your default client-side font (typically Sans).
Comment 2 Matej Cepl 2008-04-08 01:20:38 UTC
I don't think we have patched *the fonts* of xorg-x11-fonts. This is the list of patches in our xorg-x11-fonts package:

[matej@viklef devel]$ ls *.patch

(that's checkout from fedora CVS). And the patches contain just what the name suggests (fixing of paths):

[matej@viklef devel]$ wc -l *.patch
  11 encodings-1.0.0-encodings-fontdir-fix.patch
  11 font-alias-1.0.0-fonts-alias-fontdir-fix.patch
  22 celkem
[matej@viklef devel]$ 

Now to the lucidatypewriter font itself. We are using these upstream sources:

[matej@viklef devel]$ grep ^Source.*lucidatypewriter xorg-x11-fonts.spec 
Source18: ftp://ftp.x.org/pub/individual/font/font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2
Source19: ftp://ftp.x.org/pub/individual/font/font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2
[matej@viklef devel]$ 

with these MD5 checksums

c44d3f730564da465993e9292a33c235  font-bh-lucidatypewriter-100dpi-1.0.0.tar.bz2
fdd9be5b9db94ef363a33e39b7977e2b  font-bh-lucidatypewriter-75dpi-1.0.0.tar.bz2

Comment 3 Matej Cepl 2008-04-08 01:24:08 UTC
Created attachment 15753 [details] [review]

Just to be sure there is no misinformation, this is the first Fedora patch of xorg-x11-fonts
Comment 4 Matej Cepl 2008-04-08 01:24:43 UTC
Created attachment 15754 [details] [review]

and this is the second
Comment 5 Matej Cepl 2008-04-08 01:28:15 UTC
(In reply to comment #1)
> I cannot find a U+2116 NUMERO SIGN (№) glyph in the Lucida Typewriter bdf
> fonts as found in the xorg git repos.  In fact, I don’t see *any* Cyrillic
> glyphs, and no iso8859-5 subsets get installed.

I cannot claim to be an Unicode expert, but why do you think U+2116 is a Cyrilic glyph? I found it in http://www.unicode.org/charts/PDF/U2100.pdf (Letterlike Symbols).
Comment 6 Jan "Yenya" Kasprzak 2008-04-08 02:19:11 UTC
As for the comment #1: You are probably right - I am not able to reproduce this problem with xterm (I don't see a NUMERO SIGN glyph when I paste it to
xterm -fn '-*-lucidatypewriter-*-r-*-*-14-*-*-*-*-*-iso10646-1').

So it is probably a font substitution problem then. However, the problem is that with this font, gnome-terminal uses other double-width characters (like Hiragana or Kanji) correctly, just the U+2116 character is the problem.

So which other component should I fill this bug against?

I would also like to know which font is used for substituting characters here: I have tried to change the gnome-terminal's font to the following fonts I have, and all of them display the NUMERO SIGN as a character with single-width metric _and_ glyph:

Bitstream Vera Sans Mono
DejaVu LGC Sans Mono
DejaVu Sans Mono
Liberation Mono
Luxi Mono
Nimbus Mono L

The following two settings display the problem:

Miriam Mono CLM

Comment 7 Markus Kuhn 2008-04-08 03:21:06 UTC
I prepared the *-ISO10646-1 BDF fonts in


You can easily confirm yourself that all the glyphs in these BDF files are fixed-width:

  $ cd font/bh-lucidatypewriter-100dpi/
  $ grep DWIDTH *.bdf | sort -u
  lutBS08.bdf:DWIDTH 7 0
  lutBS10.bdf:DWIDTH 8 0
  lutBS12.bdf:DWIDTH 10 0
  lutBS14.bdf:DWIDTH 12 0
  lutBS18.bdf:DWIDTH 15 0
  lutBS19.bdf:DWIDTH 16 0
  lutBS24.bdf:DWIDTH 20 0
  lutRS08.bdf:DWIDTH 7 0
  lutRS10.bdf:DWIDTH 8 0
  lutRS12.bdf:DWIDTH 10 0
  lutRS14.bdf:DWIDTH 12 0
  lutRS18.bdf:DWIDTH 15 0
  lutRS19.bdf:DWIDTH 16 0
  lutRS24.bdf:DWIDTH 20 0

As you can see, there is only a single pixel-width value (DWITDH attribute) associated with any glyph within in each of these fonts.

What happened here is that some modern terminal emulators have very little respect for the notion of a fixed-width font. They behave more like web browsers and cobble together a Unicode repertoire as complete as possible from whatever font they can get hold of, independent of the resulting glyph size. I know that konsole does that by default under openSUSE, and I suspect that gnome-terminal is not much better. I'll leave it to other to decide whether that is a "bug" or merely a "controversial feature". Ask the developers of your favorite terminal emulators for advice; there may well be configuration options to change the font-selection strategy.

Xterm has a IMHO much more sane font-selection semantics here and will only load two fixed fonts at a time (not counting bold), one single-width and one double-width for CJK. Preferably, use a font that contains the full glyph repertoire that you regularly need. The BDF versions of LucidaTypewriter obviously do not fulfill your repertoire requirements.
Comment 8 James Cloos 2008-04-08 09:20:58 UTC
(In reply to comment #5)

I called it a Cyrillic character because that is where it is most commonly used/found.  Note its inclusion in eg the ISO 8859-5 and MacCyrillic sets.

(In reply to comment #6)

Fontconfig supports the FC_DEBUG environmental and libXft has XFT_DEBUG.
Set those to integers to turn on various debug outputs.

The relevant #defines are:

#define XFT_DBG_OPEN    1
#define XFT_DBG_OPENV   2
#define XFT_DBG_RENDER  4
#define XFT_DBG_DRAW    8
#define XFT_DBG_REF     16
#define XFT_DBG_GLYPH   32
#define XFT_DBG_GLYPHV  64
#define XFT_DBG_CACHE   128
#define XFT_DBG_CACHEV  256
#define XFT_DBG_MEMORY  512


#define FC_DBG_MATCH    1
#define FC_DBG_MATCHV   2
#define FC_DBG_EDIT     4
#define FC_DBG_FONTSET  8
#define FC_DBG_CACHE    16
#define FC_DBG_CACHEV   32
#define FC_DBG_PARSE    64
#define FC_DBG_SCAN     128
#define FC_DBG_SCANV    256
#define FC_DBG_MEMORY   512
#define FC_DBG_CONFIG   1024
#define FC_DBG_LANGSET  2048
#define FC_DBG_OBJTYPES 4096

AND together the debugs you want.

Again, I suspect you are getting U+2116 from the Sans alias.

(It is possible you may need to recompile fontconfig and/or libXft to enable said DEBUG support; I get it by default from the Gentoo ebuilds but I think I recall some previous conversations indicating that it wasn't compiled in by default on (some of) the rpm and deb dists.)