Technical issues in using decimal coordinates in PostScript fonts.
rrob...@adobe.com
The latest version of the FDK supports decimal coordinates in Type1/CFF fonts.
We did run into one issue which is a problem with the font format, that would benefit from some discussion among the font tool developers. Type 2 fonts (OpenType/CFF) store decimal coordinate values as a Fixed 16.16 number. This means that it is stored as two parts: an integer number which represents the integer part of the decimal value, with a range of −32K to +32K. The second part is the decimal fraction, and this is stored as an integer number which is a multiple of 1/64K. The fractional values that can be represented are thus a multiple of 1/64K, aka a multiple of 0.0000152879. This means that many decimal values cannot be exactly represented in the Fixed 16.16 value. For example, if you convert the coordinate value 41.37 into a Fixed value, and then convert this back into a decimal value, you get 41.3699951. This has never been a problem before, as the decimal values used in hints have typically been 0.5 or 0.25, and and all fractions that are 1/(2n) can be exactly represented in both Fixed and decimal values. Now that we are beginning to explore arbitrary decimal values, it is a problem. If you round-trip between a CFF font and a UFO font, and truncate rather than round, the fractional errors for the relative coordinates can add up to several design units over a long path with hundreds of points. Also, closed paths can become an almost closed path, adding an extra on-curve point, and you get an implied line-to at the end of the path that is a small decimal fraction in length.
What I did in the AFDKO tools was to round coordinate values (away from zero) to 4 significant places when converting from decimal values in a UFO font, and to round (away from zero) to the nearest Fixed 16.16 when converting to Fixed 16.16. With this in place, there can still be cumulative errors from the truncation of sequential relative coordinate values, but it would take a lot of coordinate values to add up to one design unit. I would like to see this approach adopted by other developers as well. The degree of rounding precision is arguable. I chose four decimal places, since this is the most than can be supported when converting between Fixed 16.16 and decimal values, but I think it would make sense to have fewer. I also think that it would be useful to have font tool developers agree on a convention for rounding decimal values.
An oddity which is specific to the AFDKO tools is that that the font development workflow will support only 2 decimal places. This is because of the autohint tool, which originally supported only a Fixed 25.7 format for coordinate values (in other words, the fractional part is a multiple of 1/128). I changed this to Fixed 24.8, which will support two decimal places, but not more. I would obviously have liked to support a larger fractional part, or switch to using real decimal values, but we needed to be able to produce the same output before and after with the same original input. If I had disturbed the code with a larger change, the output but would not be exactly comparable, and we did not have time to do a large QA effort (as in man-months) to evaluate new autohint output.
