[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [I18n]Re: XLFD subsetting and bdftruncate
- To: i18n at XFree86 dot Org
- Subject: Re: [I18n]Re: XLFD subsetting and bdftruncate
- From: Juliusz Chroboczek <jec at dcs dot ed dot ac dot uk>
- Date: 23 Jan 2002 17:39:01 +0000
- Cc: developer at arabeyes dot org
MK> What is going on here? I suspect nothing has actually changed since I
MK> did my tests a few years ago, it is just that Juliusz's example XLFDs
MK> contained wildcards at the right place, whereas I always used the full
MK> XLFD as it stands in the BDF file. What difference does that make
MK> in the font mechanics of the X server?
Short answer: everything is working correctly.
Medium-short answer: don't use overspecified XLFDs.
Long answer: it's an interesting interaction between a rounding error
and the server's fallback mechanics.
First, note that 13 pixels at 75 dpi is exactly 12.5268 points. Thus,
the BDF font contains an inconsistent XLFD.
If you open a bitmap font without subsetting, the point size and
average width are taken from the BDF. If you subset it, they are
recomputed (think average width).
The fonts subsystem will use fallbacks. For example, if you request
-*-*-*-*-*-*-13-*-75-75-*-60-iso8859-1
the fonts subsystem will find a 13 pixel font with average width 60.
The way this works is that it will open all 13 point fonts in turn,
until it finally finds one whose computed average width is 60.
When you propose your (incorrect) XLFD, the server politely opens the
font with subsetting, computes the point size, and finds that it's 125
rather than your incorrect 120. It therefore gives up, and searches
for a different font.
Why is ends up serving the full font rather than failing altogether
puzzles me somewhat, but I'll let you work it out for yourself.
Juliusz