Thanks for the reply!.. > I'm not familiar with the FreeType Type 1 code, but Adobe has a combined > CFF+Type 1 interpreter where the "PostScript stack" is implemented by a > simple array of 3 Fixed elements. I see a comment about a change to "skip > the unique id check", if that helps.
..However, I am unable to locate this. A simple array makes sense, but how was the limit of three decided? I don't have data for any fonts that might call an unhandled othersubr, but it seems they might pass in more arguments than that. > The large number operator (255) expects small Type 1 values to be integers, > converted to Fixed by << 16 (thus zero fraction). Large values are converted > to Fixed by a subsequent div operator, and there is no shift when the > numerator is pushed on the stack. CFF values are expected to already be > Fixed, so there is no shift. For CFF, small values (not 255 op) are stored in the stack as integers and large ones interpreted as Fixed. Now for the old Type 1 interpreter, small values are stored as Fixed and large values are stored as integers but are immediately converted to Fixed by the subsequent `div'. However, `div' expects two Fixed arguments. This means in handling Type 1, large values have a possible limit issue when converted to Fixed by << 16. I'll need to extend `div' to accept unscaled integers if `large_int' is set. My concern is that `div' might be abused in Type 1 fonts, expecting an integer result for use in indexing later. This would pass in the old interpreter but is not allowed in the new one. Again, I have no reference to actual fonts, so I don't know if this is a real problem. On the other hand, this means there should be no other issues with number format between Type 1 or CFF ops, as long as the operands are pushed correctly as above. Do correct me if I'm wrong. Ewald. _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
