BDFCTOOL(1) BSD Reference Manual BDFCTOOL(1)
bdfctool - convert BDF and bdfc font files
bdfctool -c bdfctool -d [-F] bdfctool -e [-a]
The bdfctool utility converts (mostly) fixed-width bitmap fonts between the BDF file format as used by XFree86(R) and the bdfc format as speci- fied below. It operates as a filter, i.e. takes its input from the stan- dard input stream and writes data to standard output. The options are as follows: -a In edit mode, emit ASCII (1:2) encoding for an unset bit ('.'), a set bit ('#') and the line end separator ('|'). +a In edit mode, emit Unicode (1:1) encoding (default). -d Decompress the font from bdfc into BDF. -c Compress the font from BDF or the bdfc edit form to bdfc, also sort- ing and weeding out any duplicates (later occurrence wins). -e Expand selected glyphs inside the bdfc file into the edit form, which uses U+3000 and U+4DC0 to represent unset and set bits, respectively, so they can be visually edited. This mode operates on glyphs and does not need to be passed the whole file, e.g. using ^K/ in the jupp text editor. -F Do a fast decompression with no error checking. Run this on files passed through bdfctool -c only. Used by the MirOS XFree86(R) build process.
A .bdfc file is a compressed, editable representation of a subset of the Bitmap Distribution Format (BDF) as used for fixed-width fonts in the XFree86(R) windowing system. Every file starts with a line consisting of "=bdfc 1", where '1' is the version number. The format is line-oriented and only somewhat stateful. It is optimised for being operated on using the jupp text editor and mksh shell scripts. Lines starting with an apostrophe U+0027 and a space U+0020, or consisting of only an apostrophe before the newline, can be used anywhere inside the file, except within the trailing-data lines of an edit block (see below), to denote a comment, which is retained (tacked on to the following character). Next comes a block of font header information that are just passed through, prefixed with a "h". After that, list the font properties, pre- fixed with a "p" each, and followed by a "C" on a line by itself, which will deal with emitting the STARTPROPERTIES number, the properties and ENDPROPERTIES and marks the place where CHARS is put in BDF. Finally, there is the character block, which is somewhat stateless. There are two types of entries for that block, glyph defaults and glyph data. The block is ended with a period (".") on a line by itself. Glyphs are sorted by their font encoding / Unicode code point, and each glyph occurs only once, although the bdfctool tool in the -c operation mode is able to take glyphs in any order and weed out duplicates. The character name can be omitted if it matches the form "uni20AC" where "20AC" is the four-nibble uppercase Unicode codepoint of the glyph, in this example the Euro sign. Glyph defaults are lines in the format d 540 0 9 0 0 -4 where the first "d" is the line type, and the next values are, in order, the arguments to the SWIDTH and DWIDTH and the third and fourth argument to the BBX BDF commands. (The first and second arguments of BBX are derived from the glyph data line instead.) The glyph defaults are used in encoding every subsequent glyph for BDF and are valid until the next glyph default line, which means that a char- acter block must start with one, and that sorting may need to duplicate or move such lines, as handled by bdfctool -c. Finally, let's talk about the glyph data lines. The standard (condensed) form looks like c 0020 6 00:00:00:00:00:00:00:00 space which are, in this order, the type of the line, the encoding of the glyph, the width (in bit) of the glyph (first argument of BBX), the glyph data (in whole bytes, uppercase nibbles, as in BDF, but colon-separated; the number of which yields the second argument to BBX) and the glyph name (which, as explained above, is optional) consisting of up to 14 al- phanumeric characters. The editing form is a multi-line form and must not be used in persistent storage, revision control or transmission. Its first line looks like e 0020 6 8 space which is basically the same as the standard form, except that the number of lines replaces the bitmap data. This is followed by (in this case eight) lines that comprise of (in this case six) occurrences of either U+3000 (to denote an unset pixel) or U+4DC0 (to denote a set pixel), fol- lowed by U+258C (to denote, as a visual help, the next character). The compression script also accepts a dot U+002E or a space U+0020 as null- bit, a hash U+0023 or an asterisk U+002A as set bit, and a pipe sign / bar U+007C as line end marker. You should use the regular form if your display font has an 1:2 ratio (e.g. 8x16, 9x18) and the alternative form if it has an 1:1 ratio (e.g. 8x8 pixels), and switch fonts if it has a different ratio altogether. The trailing dot does not denote the end of file for the -c operation, as it can handle concatenated files, but is used to have an easy way to switch between the file and glyph sections, since the former does not use a structured line format.
The bdfctool utility exits with one of the following values: 0 No error occurred. 1 Wrong usage. 2 An error during processing occurred, e.g. invalid input. 3 A strict mode (-d) error occurred, e.g. invalid input. 4 An error in an external program, such as mktemp(1), occurred.
The following example should be a minimal valid font demonstrating all features of the bdfc format: =bdfc 1 ' $ucs-fonts: 4x6.bdf,v 1.5 2002-08-26 18:05:49+01 mgk25 Rel $ hFONT -Misc-Fixed-Medium-R-Normal--6-60-75-75-C-40-ISO10646-1 hSIZE 6 75 75 hFONTBOUNDINGBOX 4 6 0 -1 pFONT_ASCENT 5 pFONT_DESCENT 1 pDEFAULT_CHAR 0 C d 640 0 4 0 0 -1 e 0000 4 6 char0 #.#.| ....| #.#.| ....| #.#.| ....| c 0020 4 00:00:00:00:00:00 space c 018F 4 00:C0:60:A0:40:00 .
bdftopcf(1), fstobdf(1) The XFree86(R) Bitmap Distribution Format, version 2.1, specification
Thorsten Glaser <email@example.com> wrote this tool because cvs(1) does not scale for multi-thousand-line files, to have a one-line-per-glyph format that matches BDF.
bdfctool has its own ideas of how a BDF font file should look like, and if you deviate from that, you might get an error; although, support for more features can surely be added. "ENCODING -1" support is missing. The glyph encoding is currently treated as the primary key; values from 0000 to FFFF inclusive are valid, the zero-padding is mandatory. The current practical limit on glyph width is 32. 0-bit wide glyphs cause an error; those with height 0 are silently converted to an unset 1x1 bit- map. MirOS September 1, 2012 2
Generated on 2013-04-27 00:20:00 by $MirOS: src/scripts/roff2htm,v 1.77 2013/01/01 20:49:09 tg Exp $
These manual pages and other documentation are copyrighted by their respective writers;
their source is available at our CVSweb,
AnonCVS, and other mirrors. The rest is Copyright © 2002‒2013 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.
This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.