Re: BDF Considered Harmful?
On Fri, Mar 13, 2009 at 05:36:27PM -0700, Paul Hardy wrote:
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:
It looks like my point didn't pass through. I don't care how much
information is lost in the translation _as long as_ the information is
useless for the final user. So it is pointless that you mention all
the info which is lost, *unless* you also explain what are the
practical effects of loosing that info.
Until you do so, the Maybe will still need to be clarified.
As long as we have the original BDF versions of fonts in source
packages though, at least we're not discarding any information.
Ditto. So, according to this, not having BDF files into binary
packages does no harm.
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
... but is bloated, so we will not have it in binary packages, so it
is not an option. Agreed?
but a gzipped .bdf.gz version doesn't work.
Wonderful. So, until this is fixed, we are discussing a non viable
solution. Agreed?
It seems to me that the only remaining option for having .bdf.gz fonts
accepted in binary packages would be to implement the needed changes
to make them work. Also, you will need to address the issues raised by
Steve, either by providing a random access mechanism to individual
glyphs, or by showing that the performance loss is negligible.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: BDF Considered Harmful?
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.
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?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: BDF Considered Harmful?
On Fri, Mar 13, 2009 at 12:45 AM, Stefano Zacchiroli z...@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
Re: BDF Considered Harmful?
On Wed, Mar 11, 2009 at 3:21 PM, Stefano Zacchiroli z...@debian.org 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 characters. 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 confidence-inspiring comment: /* 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 font. Paul Hardy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
BDF Considered Harmful?
BDF font files have not been allowed in Debian packages for a while, as per Debian policy. I emailed Russ Allbery last year about the possibility of allowing BDF fonts back into Debian for reasons that follow. He was willing to entertain the idea. I waited for the lenny release before bringing up this possible change in policy. Currently BDF fonts are supposed to be converted to PCF. BDF is a plain ASCII format, and PCF is binary. Thus a PCF font file will be more compact than its BDF source. However, the original BDF version can contain ASCII comments that are not preserved in the PCF version. These comments often contain information such as author, copyright, and licensing information. With the BDF versions discarded, that information is lost -- there is no round-trip conversion from BDF to PCF to BDF. Thus a blind BDF-to-PCF conversion can discard valuable information the author intended to remain with the font. This can be significant given the abundance of BDF fonts in the early history of X11. In addition, PCF format fonts are gzipped on Debian systems as per Debian Policy. If BDF fonts are also gzipped, there is little difference in size between the two formats so the advantage of the binary PCF format over the ASCII BDF format disappears. In fact I created a unifont.bdf.gz file for testing and it was a little smaller than the derivative unifont.pcf.gz file. A unifont.bdf file worked fine on Debian, and so did the derived unifont.pcf.gz file, but unfortunately a unifont.bdf.gz file did not. Is there a possibility of getting .bdf.gz font files to work in Debian, then allowing .bdf.gz files in Debian font packages, and updating Debian Policy to allow installation of BDF fonts compressed with 'gzip -9'? Paul Hardy GPG Key ID: E6E6E390 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
On Wed, Mar 11, 2009 at 01:07:56AM -0700, Paul Hardy wrote: However, the original BDF version can contain ASCII comments that are not preserved in the PCF version. These comments often contain information such as author, copyright, and licensing information. With the BDF versions discarded, that information is lost -- there is no round-trip conversion from BDF to PCF to BDF. My first thought: Could BDF be considered a source format for PCF? The logical consequence would be to ship BDF in the source package, and to convert it to PCF when the font package is built. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
On Wed, 2009-03-11 at 12:15 +0100, Richard Atterer wrote: On Wed, Mar 11, 2009 at 01:07:56AM -0700, Paul Hardy wrote: However, the original BDF version can contain ASCII comments that are not preserved in the PCF version. These comments often contain information such as author, copyright, and licensing information. With the BDF versions discarded, that information is lost -- there is no round-trip conversion from BDF to PCF to BDF. My first thought: Could BDF be considered a source format for PCF? The logical consequence would be to ship BDF in the source package, and to convert it to PCF when the font package is built. That's pretty much what happens today, afaik. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
On Wed, Mar 11, 2009 at 01:07:56AM -0700, Paul Hardy wrote: BDF font files have not been allowed in Debian packages for a while, as per Debian policy. I emailed Russ Allbery last year about the possibility of allowing BDF fonts back into Debian for reasons that follow. He was willing to entertain the idea. I waited for the lenny release before bringing up this possible change in policy. Hello Paul, I would like to clarify that BDF are not allowed in *binary* package, but are allowed in *source* package. Currently BDF fonts are supposed to be converted to PCF. BDF is a plain ASCII format, and PCF is binary. Thus a PCF font file will be more compact than its BDF source. However, the original BDF version can contain ASCII comments that are not preserved in the PCF version. These comments often contain information such as author, copyright, and licensing information. With the BDF versions discarded, that information is lost -- there is no round-trip conversion from BDF to PCF to BDF. Thus a blind BDF-to-PCF conversion can discard valuable information the author intended to remain with the font. This can be significant given the abundance of BDF fonts in the early history of X11. 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. Users that need the BDF files can get it from the source package, so its is not lost to the user. Furthermore a cursory use of zless on some pcf.gz in debian seems to show that copyright information *are* preserved. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
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. Make an analogy with Perl source file, it
will work better: they do have copyright notices and comments, yet we
ship them in binary packages.
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.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: BDF Considered Harmful?
Stefano Zacchiroli wrote: 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. Make an analogy with Perl source file, it will work better: they do have copyright notices and comments, yet we ship them in binary packages. With Perl you have no choice. AFAIK there is no binary Perl format. 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. Copyright notices belong in /usr/share/doc/package/copyright. -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
On Thu, Mar 12, 2009 at 09:26:07AM +1100, Brian May wrote:
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.
Copyright notices belong in /usr/share/doc/package/copyright.
Does that answer my question?
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: BDF Considered Harmful?
Brian May br...@microcomaustralia.com.au writes: Stefano Zacchiroli wrote: 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. Make an analogy with Perl source file, it will work better: they do have copyright notices and comments, yet we ship them in binary packages. With Perl you have no choice. AFAIK there is no binary Perl format. Try the analogy with Python, then. One can ship either the source file ‘foo.py’, or the compiled bytecode ‘foo.pyc’, and the recipient can use either one as a Python module. -- \ “You know what would make a good story? Something about a clown | `\who makes people happy, but inside he's real sad. Also, he has | _o__) severe diarrhea.” —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
On Thu, Mar 12, 2009 at 11:31:48AM +1100, Ben Finney wrote: Brian May br...@microcomaustralia.com.au writes: Stefano Zacchiroli wrote: 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. Make an analogy with Perl source file, it will work better: they do have copyright notices and comments, yet we ship them in binary packages. With Perl you have no choice. AFAIK there is no binary Perl format. Try the analogy with Python, then. One can ship either the source file ‘foo.py’, or the compiled bytecode ‘foo.pyc’, and the recipient can use either one as a Python module. We ship .py files in the source because the .pyc as generated on the build host is not guaranteed to be compatible with the python on the target host. That argument also does not apply to BDF. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: BDF Considered Harmful?
On Wed, Mar 11, 2009 at 01:07:56AM -0700, Paul Hardy wrote: In addition, PCF format fonts are gzipped on Debian systems as per Debian Policy. If BDF fonts are also gzipped, there is little difference in size between the two formats so the advantage of the binary PCF format over the ASCII BDF format disappears. In fact I created a unifont.bdf.gz file for testing and it was a little smaller than the derivative unifont.pcf.gz file. 'Size' is not the only advantage of using compiled formats over ASCII formats. They normally are also much more efficient to parse; e.g., an ASCII file format that supports comments isn't going to have any sort of index, so using any part of the file will require loading the whole file and parsing it linearly until you find what you're looking for. I'm not familiar with the PCF and BDF font formats, but I suspect this is the real reason for historically preferring PCF (though the practice of subsequently gzipping the PCF files eliminates some of the potential performance benefits). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
