Bit-mapped Japanese font parser 2.0 review
DownloadBit-mapped Japanese font parser is a font parser
|
|
Bit-mapped Japanese font parser is a font parser. Note, this package doesn't include the actual font data. To get the font data you need to download it from the download section in the left.
Then move *.jfr into the directory where you unpacked this parser, and follow with the quick instructions.
Quick instructions:
Complete parse requires about 4 megabytes of free disk space. This is a huge improvement over the original version which required almost 45 megabytes.
1. make
2. make parse
3. watch the progress indicator
4. mv *.pcf.gz /usr/X11R/lib/X11R6/fonts/misc
5. make clean
6. HUP your font server if you use one
7. xset fp rehash
8. xlsfonts | grep kanji
/usr/X11R/lib/X11R6/fonts/misc is the standard location for all sorts of random bit-mapped fonts, but you might have a special location. Substitute that in step 4.
About:
I came across a number of these "raster fonts" a while ago. Quick look inside the files proved that they are bit-mapped fonts, and the format looked pretty straight-forward. I wrote the original parser for these just guessing the values, basically by experimenting and playing around. Later on I came across some docs on the subject - looks like these fonts were used in Windows 3.1 Japanese edition to substitute back-then low quality Japanese TTF fonts at small point sizes. These were designed using full-scale 16 bit programming techniques.
Quick info about the font format, there are some headers, then follows a "segment table" which is basically a table with pointers inside the font file where to locate a particular chunk of data. Because the 16 bit way of accessing memory is by using 65k "segments", each file is virtually split into < 65k segments which get loaded into separate memory areas, and then there is a algorithm how to assemble whatever character by using the segment number and offset. Anyway, with 32 bit access all of that doesn't really matter. In my implementation I just mmap the whole file and read it all out of memory.
Generating table.h was a LOT of work! First, I took the codearea table out of one of the jfr files (this maps shift-jis code to the character number inside the font file), and extracted the number ranges. These were shift-jis, of course, and X uses jis0208. There is no converter from a shift
jis byte into jis0208. So I had to write one. Taking iconv, and some tables from glibc 2.1.93, I hacked together something which converted the shift-jis data into ucs4 (unicode, I guess) and then from that into jis0208. The code to the converter is about 500k thanks to the huge jis->unicode->jis conversion tables, and you won't need it unless you get a jfr font with a different encoding table (unlikely). Anyway. After I got the font format figured out and converted the character table, everything else was pretty easy. Note some bit hackery in the bitmapXX() functions which was necessary to present the font data in a usable format. Also notice cool use of function pointers to select a conversion function at runtime.
What's New in This Release:
This version uses correct JISX0208 tables, and is much faster.
Bit-mapped Japanese font parser 2.0 keywords