Re: BDF Considered Harmful?
On Fri, Mar 13, 2009 at 12:45 AM, Stefano Zacchiroli <zack@debian.org> wrote:
> On Thu, Mar 12, 2009 at 01:19:47AM -0700, Paul Hardy wrote:
>> The only advantage is in preserving all information if (and only if)
>> the original font is in BDF format. It seemed harmless to me if the
>
> That's not an advantage per se. Either you know that some of that
> information are useful for the target user (and no, I don't consider
> editing the font file to read a comment to be useful) or this whole
> discussion is pointless. If it is not broken, don't fix it.
>
>> A BDF file can contain any number of properties describing the font
>> in the header, for example CAP_HEIGHT and X_HEIGHT. Maybe there's
>> no harm in losing this information through format conversion. I
>
> This is a precise example of what we need to no. That "Maybe" needs to
> be clarified.
>
A BDF file contains a section beginning with STARTPROPERTIES and
ending with ENDPROPERTIES. There are common properties and
vendor-specific properties (which are allowable). You can see the
list of standard X11R6 properties here:
http://lesstif.sourceforge.net/doc/super-ux/g1ae04e/chap5.html#pg8
The standard X11R6 values of what can appear between STARPROPERTIES /
ENDPROPERTIES labels (in BNF) are XFontProp ::= FOUNDRY | FAMLY_NAME |
WEIGHT_NAME | SLANT | SETWIDTH_NAME | ADD_STYLE_NAME | PIXEL_SIZE |
POINT_SIZE | RESOLUTION_X | RESOLUTION_Y | SPACING | AVERAGE_WIDTH |
CHARSET_REGISTRY | CHARSET_ENCODING | QUAD_WIDTH | RESOLUTION |
MIN_SPACE | NORM_SPACE | MAX_SPACE | END_SPACE | SUPERSCRIPT_X |
SUPERSCRIPT_Y | SUBSCRIPT_X | SUBSCRIPT_Y | UNDERLINE_POSITION |
UNDERLINE_THICKNESS | STRIKEOUT_ASCENT | STRIKEOUT_DESCENT |
ITALIC_ANGLE | X_HEIGHT | WEIGHT | FACE_NAME | FIJLL-NAME | FONT |
COPYRIGHT | AVG_CAPITAL WIDTH | AVG_LOWERCASE_WIDTH |
RELATIVE_SETWIDTH | RELATIVE_WEIGHT | CAP_HEIGHT | SUPERSCRIPT_ SIZE |
FIGURE_WIDTH | SUBSCRIPT_SIZE | SMALL_CAP_SIZE | NOTICE | DESTINATION
| FONT_TYPE | FONT | VERSION | RASTERIZER_ NAME | RASTERIZER_VERSION |
RAW_ASCENT | RAW_DESCENT | RAW_* | AXIS_NAME | AXIS_LIMIT | AXIS_TYPES
Many of those properties don't translate into anything in the PCF
version by bdftopcf. As long as we have the original BDF versions of
fonts in source packages though, at least we're not discarding any
information.
> Also, in your initial mail it seems to me that you reach the
> conclusion that plain .bdf.gz does not work in all cases. If this is
> so, we have another reason for this discussion to be pointless.
> Or am I missing something?
>
A .bdf font file works perfectly on Debian (and I've been testing the
last unifont.bdf file that I generated, which is enormous), but a
gzipped .bdf.gz version doesn't work. Also, unifont.pcf and
unifont.pcf.gz work fine. So it seemed like a small change might be
possible to allow uncompressing a .bdf.gz file in the same way that
.pcf.gz files are uncompressed when loading the font.
The traditional reasons for loading PCF instead of BDF fonts have been
that PCF fonts were smaller (because they were binary) and that they
took less time to load than a BDF font.
A BDF font is mostly hexadecimal glyph maps, which gives it about a
2:1 ratio in size to the binary PCF format. If gzipped BDF fonts are
supported, then there's no advantage in size for PCF. Also, because
currently a BDF font must be converted to a PCF font for installation
in Debian as per Debian Policy, we are (hopefully) preserving two
copies of a font (BDF and PCF) even though the original BDF version
could be used on its own.
As for loading time, it might have made a difference in the days when
computers were 100 times slower than they are today, but I don't
notice any delay loading the gigantic unifont.bdf font. It is
possible this could still make a difference on embedded systems for a
font that goes beyond the old standard 256 code points though.
There is one thing that is broken in bitmapped fonts under various
applications in X11R6, whether BDF or PCF, and it would be nice to fix
it: Unicode combining characters are not properly supported. A
combining character should be superimposed on the character it
precedes. Multiple combining characters can be used in a row. I
tried getting them working with BDF and PCF versions of Unifont, and
nothing I tried worked (following advice of authors of font software
as to what might work although with no guarantees). I recently
learned from Markus Kuhn that the problem is lack of support in X11R6
applications, and not in the bitmapped fonts themselves.
I did get combining characters working properly in the TTF version,
unifont.ttf. To do that I typed in a list of the 975 Unicode
combining characters in the Basic Multilingual Plane. I just recently
added the 45 combining characters contained in higher Unicode planes
to this list. The full file of all 1020 Unicode 5.1 combining
character code points, one per line in hexadecimal, is at
http://unifoundry.com/combining-5.1.dat
I am placing that file in the public domain in hopes that it will help
anyone trying to provide Unicode combining character support in Debian
and elsewhere.
If the consensus is that it is not worth allowing .bdf or .bdf.gz
fonts to be installed in a font directory, so be it. At least the
pros and cons will have been considered.
Paul Hardy
GPG Key ID: E6E6E390
Reply to: