Re: BDF Considered Harmful?
On Wed, Mar 11, 2009 at 3:21 PM, Stefano Zacchiroli <email@example.com> wrote:
> On Wed, Mar 11, 2009 at 01:14:03PM +0100, Bill Allombert wrote:
>> I fail to see the difference between a BDF-to-PCF converter and a C compiler
>> that will discard comments from the C source files. Yet we do not generally
>> ship C source code in binary packages.
> This is not the right analogy. A C source file by itself cannot be run
> without having been compiled while, AFAICT from the given description,
> a BDF "source" file can be.
> A question I have and that hasn't been addressed by the original
> request is: what is the advantage to have BDF files in binary
> packages? Comments and copyright notices don't look like a real
> advantage to me.
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
savings in size was nonexistent, with both BDF and PCF files gzipped.
Steve Langasek brought up something I hadn't considered, that PCF's
table-based format could be more efficient in general than alternative
font formats. A BDF font does have to be read serially from beginning
to end; there are no handy table offsets to jump from one glyph to the
next. That might not be an issue with the speed of modern computers,
especially if the BDF font in question only has on the order of 256
If it is sufficient to have copyright information in the Debian
copyright file, then so be it. I was also concerned about other
things that might be dropped. 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 don't know what all the implications
are. The list of BDF properties isn't fixed, so bdftopcf is likely to
discard some of such information during conversion.
The bdftopcf utility calls a function in bdfread.c to mainly load
glyph bitmaps, then calls another function to write them out as a PCF
file. The source code that reads a BDF font contains this
/* 5/31/89 (ef) -- hack, hack, hack. what *am* I supposed to do with */
/* 0 width characters? */
I ran into this trying to track down why Unicode combining marks
weren't overlapping preceding characters properly in BDF or PCF
versions of the unifont package; I only got the TrueType version
working. (Disclaimer: I'm not at home now, and not anywhere near my
Debian system; the above code is something I had on a laptop where I
worked on getting combining marks working.)
So because Debian GNU/Linux properly renders uncompressed BDF fonts if
they are placed in the font directory, I thought I'd ask if it could
make sense to support .bdf.gz font files -- both technically and as
Debian Policy. I thought that this could simplify installing a BDF
font (by avoiding conversion to PCF) as well as guaranteeing that all
information the font designer included was preserved in the installed