AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Transtype 4 interpolation7/30/2023 ![]() ![]() The path from most general to most specific (or the other way around) is a common case in pretty much all in life. I wouldn't necessarily agree that this is always the case.Īlso, I don't think it's really data duplication we're talking about. Almost all of this can be summarized as "data duplication is a nightmare." What do you think about that? Of course tools would need to me made aware of that. If the build process is so that at some point the font is output as a set of TTX tables, and there is an older version of the tables already present, and the user has declared that the "name" table TTX file is "locked", then the outputting tool would honor that and produce newer versions of all the other table files, but keep "name" as it was before. could be "locked" by the user, and then if the user runs an autokerning/autospacing algorithm, that algorithm will do its thing only on the unlocked pairs or sidebearings, but it will not touch the locked entries. For example, certain kerning pairs or sidebearings etc. The same applies really to every aspect of the font production chain. But if it is unlocked and I change the UFO kerning, then the "kern" feature gets regenerated. For example, I could declare that my "kern" feature definition in ist is "locked" and then it would not be overwritten if I change the UFO kerning. Is this type of marking certain data as "locked" part of UFO? What I'm talking about is mostly when a more complex process has to transform one type of data into another. Certain version control systems also have this functionality, but that usually applies to older and newer versions of the same data. Very basic conflict resolution can be done using timestamps. The user should be able to set the preference whether to: present this question every time, overwrite every time or skip every time, and whether to log the overwrites and skips.Īll that should happen on font-wide, glyph group, glyph and, where applicable, sub-glyph scope. For certain types of data, "Keep both" could also be an option.ĥ. Whenever a tool deems it recommended that lower-level data is overwritten, but that lower-level data is locked, it should ask the user: "Unlock NNN and overwrite?" (Yes, Yes for All, No, No for All). ![]() Allow the user to overwrite the unlocked portions of lower-level code with code generated from updated higher-level code.Ĥ. Allow the user to lock portions of lower-level code i.e. Detect when a lower-level code becomes out-of-sync ("outdated") due to changes in higher-level code.Ģ. Generally speaking, I think a good tool and format should have the ability to:ġ. with hinting info added), and then there could be the Superpolator masters in Level 4. In case of Superpolator, there could be instances on levels 2 and 3 (e.g. Kalliculator's own "glyph generation" data, the shape of the skeleton and some pen definitions UFO code in GLIF format, potentially with Adobe-compatible PS hinting and FontLab-compatible TT visual hinting TTX code for "glyf" or "CFF " representation in case of "glyf", potentially with bytecode hinting. Taking Kalliculator as an example, a glyph would typically have three levels (let's forget about the 1.x levels now): Victoria dynamic group definitions or formula-based kerning values "code generator code": High-level information, e.g. "source code": Native UFO information about kerning groups and kerning values, and potentially some information as to which pairs should also go into the "kern" table "intermediate code": FEA syntax information for GPOS "kern" feature and, potentially, separate contents of the "kern" table, or VOLT syntax for GPOS "kern" feature "assembly code": Lowest level: XML representation of the "GPOS" table and the "kern" table Kerning is a good example where there are even more levels: Superpolator masters with interpolation info, Kalliculator skeletons and pen strokes, Victoria parametric info etc. "code generator code": "above UFO" information, e.g. "source code" Middle level: native UFO XML information "assembly code": source representation of SFNT data (let's assume for simplicity that it's TTX XML). "machine code": "master" binary SFNT data "deliverable code": binary SFNT data in the final container (TTF/OTF, WOFF, TTC etc.), signed, customized etc. There are largely several levels of any information about some font data: This is something I asked about back in April on the RoboFab list: what happens when for example kerning is being added by MetricsMachine and the data is not compatible anymore with the "private" data folder? ![]()
0 Comments
Read More
Leave a Reply. |