I may not be a big fan of it aesthetically, but that's not reason enough to hijack it. That's just how it is with UFO, and we should stick with it. I think what is BEYOND doubt is that both the Adobe PS representation and other representations such as the FontLab TTH representation should adhere to the plist form. PS hinting is, after all, a bit "low level", they are (and should be) on the same level of abstraction as TrueType bytecode. It may be problematic or lead to unexpected results, but I think for PS hints, we need a way to represent that kind of situations. I mean, it is their nature that they can exist in a glyph where no points are to be seen within their "reach". start positions and widths of the hints), and another which is a bit more related to points.īut I would say that anything that is related to point IDs would not really work for PS hinting. I think, generally speaking, we have two ways to express PS hints: one which is rather close to the native representation (i.e. info about linking points (that would ultimately use the UFO3 object IDs and be a bit more abstract).
you have hint positions and widths, while he'd somehow prefer FontLab "links", i.e. His concern is that the current representation is like FontLab "hints", i.e. He said he still intends to propose a better representation. At Robothon, I have talked to Tal briefly about the PS hint representation.
0 kommentar(er)
