The `pcfWriteFont` routine has two special 'features' that I classify as bugs. 1. It always assigns the accelerator table a size of 100 bytes in the TOC, regardless of its real size, which can vary between 34 and 72 bytes. Obviously, the programmer was too lazy to write code for computing the exact value. http://sourcecodebrowser.com/libxfont/1.4.2/pcfwrite_8c_source.html#l00276 2. Due to the way the routine is designed, it ships out the last font table with its real size, ignoring the TOC's size value. Since the TOC size values are always rounded up to a multiple of 4, the difference can be up to three bytes for all tables except the accelerator table, for which the difference can be as large as 66 bytes. http://sourcecodebrowser.com/libxfont/1.4.2/pcfwrite_8c_source.html#l00364 The first issue causes bdftopcf to make *all* PCF fonts unneccesarily larger (which is admittedly no longer an issue today given that they are almost always compressed), because this program always ships the accelerator table last, AFAIK. The second issue is more serious IMHO. I know that there is no formal specification of the PCF format and that `pcfWriteFont` is the canonical source, but I don't see a reason why parsing PCFs is more difficult than necessary by not obeying the TOC data even for the last element...
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/util/bdftopcf/issues/1.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.