UFOs, and TTFs, and hints, oh my!

[Rob McKaughan]

After Tal’s presentation at Robothon last week, I spoke with Tal, John, Adam, and a few others about storing TT hints in UFOs. Here are a couple of my thoughts on it. I’d be interested in your feedback.

 

 

1. High- or low-level hints?

=================================

From a software architecture perspective, I highly recommend storing only high-level TT hints. One of the virtues of UFO is that it provides a single, authoritative source for the data required to build a font. This principle decouples ordering dependencies, enabling apps to add, remove, or transform font data, in any order in the workflow, and have one place from which the final binary can be built.

 

Low-level hint code is output data, not source. Embedding output data in a source file introduces an internal ordering dependency – low level code must stay in synch with the rest of the font data, and if that other data gets touched, the low-level code is invalid. A lot of the fragility, rigidity, and workflow linearity of the old tools (e.g. VTT, VOLT) is a result of mixing source data (e.g. VTT TSI tables) and final output data (the rest of the TTF that housed the TSI tables), thus creating an order dependency.

 

Determining if the low-level code is out of synch with the glyph data is a really hard problem – one that every application will need to get right. Even apps that don’t generate hints need to participate in detecting problems (even if only by setting a dirty cash flag). In my software career, I’ve seen too many similar strategies fail because not everyone will get things right in the same way.

 

Even if all apps got it right, embedding low-level code creates ambiguity: If an app detects a mismatch, what action should the designer take? Is the problem in the hints? The glyph data? We’ve all worked hard & late on an impending deadline and had something go wrong with our files. In that situation, we want clarity and an obvious next step. If we instead preserve the principle of a single authoritative source, then when you have a problem, you always know where the source of your problem lies (literally).

 

So: I really, really recommend storing high-level language, because that’s the source code for hints. Also, such a high-level language can be somewhat abstract so that it doesn’t have point number or glyph number dependencies, thus fits in nicely to a flexible workflow that UFO has enabled.

 

 

2) Towards a high-level TT language

=================================

 

Given the above, we need a standard language for describing high-level TT hints, just like Tal had hoped for in his presentation. To that end, I am floating a proposal here at Microsoft for releasing the specification of VTTalk as that high-level language specification. VTTalk has been refined over many years and is well tested. It is also a superset of the hinting functionality offered by all the TT hinting apps I’ve seen (FontLab, Glyphs, TTH), thus one can easily map the paradigms in those apps to VTTalk commands. (e.g. YAnchor(), YLink(), YInterpolate(), etc). Obviously we’d have to extend VTTalk to support point names as well as numbers.

 

I’m also floating a proposal of breaking out the VTTalk compiler from VTT and releasing it as a cross-platform, open-source project. It would act as a reference implementation of VTTalk, as well as a library for applications to call. Ideally, it would just be an object you could import, so applications can just drop the compiler in their final build process. This would make it easy for applications to adopt the new language. Ideally, too, there’d be a command-line wrapper for build scripts.

 

Also, using VTT’s compiler means that any apps that use it will take advantage of the two decades of R&D that we’ve put into it. For example, the VTT compiler has a code optimizer in it which produces very small, tight low-level code, which is handy for keeping webfont file-size down. Also, there are some other enhancements that we’ve recently made (first used in hinting Microsoft Sitka), that applications could potentially take advantage of without extra work.

 

To be clear: I’m making no promises at this point that we’ll do any of this. I’m just floating a proposal. I have not scoped out the work in detail (looks like a lot), nor checked against other priorities, vice-presidents, etc.

 

Since it’s just a proposal, I’ve a couple questions for you:

 

1) would it be valuable to release VTTalk as the high-level language?

 

2) is releasing the compiler useful (more specifically: who is interested in using it, and how would you use it)?

 

 

Looking forward to getting your input on these ideas.

 

// Rob

 

[Adam Twardoch (List)]

A few comments on my side:

> Low-level hint code is output data, not source. Embedding output data in a source file introduces an internal ordering dependency – low level code must stay in synch with the rest of the font data, and if that other data gets touched, the low-level code is invalid. A lot of the fragility, rigidity, and workflow linearity of the old tools (e.g. VTT, VOLT) is a result of mixing source data (e.g. VTT TSI tables) and final output data (the rest of the TTF that housed the TSI tables), thus creating an order dependency.

I agree. There are use cases when one wants to keep the binary hints, but that's typically the same use cases where one wants to keep the TrueType outlines exactly as they are. For that usage scenario, a format such as TTX is much better (or just the binary font itself). Sooner or later, we'll have a fontTools-based tool that will "update a new font from an existing TTX file/set of files". That would be most likely the best way to go.

In FontLab VI, as a rule, we keep several levels of font data: cached binary tables, the "flat" PostScript and/or TrueType outlines, and the high-level data which includes all the geometry that does beyond flat fonts (smart corners, glued shapes for serifs etc., cloned shapes, paths with overlaps etc.). Whenever a high-level data structure is modified, the lower-level cached data is destroyed and rebuilt, but as long as you don't touch a high-level structure, the cached low-level data is kept. Ultimately, I think this is the best solution.

> Given the above, we need a standard language for describing high-level TT hints, just like Tal had hoped for in his presentation. To that end, I am floating a proposal here at Microsoft for releasing the specification of VTTalk as that high-level language specification. VTTalk has been refined over many years and is well tested. It is also a superset of the hinting functionality offered by all the TT hinting apps I’ve seen (FontLab, Glyphs, TTH), thus one can easily map the paradigms in those apps to VTTalk commands. (e.g. YAnchor(), YLink(), YInterpolate(), etc). Obviously we’d have to extend VTTalk to support point names as well as numbers.

Excellent.

> I’m also floating a proposal of breaking out the VTTalk compiler from VTT and releasing it as a cross-platform, open-source project.

Excellent.

> 1) would it be valuable to release VTTalk as the high-level language?

Would work for me. My general view on such things is: if I have a choice to start something completely new (including a new conceptual paradigm) or take an existing solution that has been proven to work (even if I may consider it "imperfect"), I will always think really hard before going for the first option, i.e. there must be really convincing arguments. I have publicly spoken for re-using the deprecated MM-in-OTF and GX variations formats for "responsive fonts", because support for these already exists, albeit imperfect, they have a strong conceptual background (albeit outdated), so both specs and code exists. They should be upgraded, but that's a comparably easy task. Starting discussions on something completely new will open up Pandora's box and it will take years to reach a consensus. So for a "Fonts 3.0" type of thing, I recommend skipping SFNT altogether and going for a "fonts as programs" approach. But that's a long-term goal, and before we'll get there, we should look at MM/GX.

With FontLab VI, we have, after all, taken on option #1 — a full conceptual reworking of the paradigm. You all know how long it's been taking us :) The release is coming near, but I wouldn't recommend going for a full reworking for evey aspect.

Same goes for hinting. By Yuri's own account, his FontLab TTH implementation of high-level hinting that he created in 1998, and that has been reimplemented in the TTH RoboFont plugin 17 years later, was strongly inspired by VTT, Beat Stamm's work, and VTTalk. In effect, The FontLab TTH paradigm has always been a conceptual subset of VTT anyway. I know people have written TTH-to-VTT conversion scripts.

So a comparatively easy task would be to map out the subset of VTTalk that can be expressed in FontLab TTH, and "strengthen" (define more strictly) its behavior, and then just define a simple protocol that says "what to do" when "full VTTalk" is used. For example, the "common subset" of VTTalk that can be easily understood by many existing implementations could be defined as "VTTH Tiny", and "full VTTalk" could be "VTTH Full" (akin to SVG Tiny and SVG).

App makers would be encouraged to use the more lightweight, portable VTTH Tiny as much as possible, and only "upgrade" to VTTH Full if really needed (risking that some apps may offer GUI support for VTTH Tiny but not for VTTH Full).

> 2) is releasing the compiler useful (more specifically: who is interested in using it, and how would you use it)?

FontLab would be interested in using it. We could offer GUI for VTTH Tiny (and possibly some GUI for VTTH Full), we could let users compile VTTH Tiny using both the VTT code and our own code (to maintain compatibility for fonts which had been hand-hinted using FontLab TTH), we could offer a possibly lossless conversion path from FontLab TTH to VTTH Tiny, and of course to VTTH Full as well. We might also offer the possibility to do a lossy downgrade from VTTH Full to VTTH Tiny. The approach could be mixed on a per-glyph level perhaps: you could have a UFO with VTTH Full talk, but that would not be readable by GUI, yet you could "downgrade" a glyph to VTTH Tiny. You'd then get GUI and could change things. You might lose some things but you'd gain some things. Of course, with Microsoft VTT, you'd still be able to edit VTTH Full, but in apps such as FontLab VI+ or RoboFont+TTH, you'd be able to GUI-edit just VTTH Tiny, but you'd be able to keep VTTH Full.

Best,
Adam

[Tal Leming]

On Mar 12, 2015, at 1:10 PM, Rob McKaughan <rob...@microsoft.com> wrote:

1. High- or low-level hints?

=================================

From a software architecture perspective, I highly recommend storing only high-level TT hints. One of the virtues of UFO is that it provides a single, authoritative source for the data required to build a font. This principle decouples ordering dependencies, enabling apps to add, remove, or transform font data, in any order in the workflow, and have one place from which the final binary can be built.

 

Low-level hint code is output data, not source. Embedding output data in a source file introduces an internal ordering dependency – low level code must stay in synch with the rest of the font data, and if that other data gets touched, the low-level code is invalid. A lot of the fragility, rigidity, and workflow linearity of the old tools (e.g. VTT, VOLT) is a result of mixing source data (e.g. VTT TSI tables) and final output data (the rest of the TTF that housed the TSI tables), thus creating an order dependency.

 

Determining if the low-level code is out of synch with the glyph data is a really hard problem – one that every application will need to get right. Even apps that don’t generate hints need to participate in detecting problems (even if only by setting a dirty cash flag). In my software career, I’ve seen too many similar strategies fail because not everyone will get things right in the same way.

 

Even if all apps got it right, embedding low-level code creates ambiguity: If an app detects a mismatch, what action should the designer take? Is the problem in the hints? The glyph data? We’ve all worked hard & late on an impending deadline and had something go wrong with our files. In that situation, we want clarity and an obvious next step. If we instead preserve the principle of a single authoritative source, then when you have a problem, you always know where the source of your problem lies (literally). 

 

So: I really, really recommend storing high-level language, because that’s the source code for hints. Also, such a high-level language can be somewhat abstract so that it doesn’t have point number or glyph number dependencies, thus fits in nicely to a flexible workflow that UFO has enabled.

I agree with all of this. The problem that I'm facing from the perspective of the spec editor is that lots of people are putting hints in their fonts. It's a huge amount of time and money to produce these things. The UFO is meant to be a place where we can keep all of our important data, but some of our most important data is not being stored. It's probably the #1 requested thing in the UFO. The only commonality that I see between the hint editors is that low-level code. So, that's why I threw up my hands and said, "Ok, fine, let's hold our noses and store that so that we have *something*." The ordering dependency that you mentioned is a non-trivial problem to solve. We could address it in the spec by prescribing a fingerprinting procedure and stating what should take precedence if the outline data is out of sync with the fingerprint. In theory that would address the problems if we think about it long enough and find all of the edges. In practice, well, we would have to cross our fingers. As I mentioned in my presentation, this low-level data is very fragile and errors in it can cause some substantial problems out in the wild. From my perspective as the spec editor, none of this (the fact that we aren't storing anything along with the potential problems of storing low-level code) makes me feel very comfortable. We're stuck with a bad situation either way.

2) Towards a high-level TT language

=================================

 

Given the above, we need a standard language for describing high-level TT hints, just like Tal had hoped for in his presentation. To that end, I am floating a proposal here at Microsoft for releasing the specification of VTTalk as that high-level language specification. VTTalk has been refined over many years and is well tested. It is also a superset of the hinting functionality offered by all the TT hinting apps I’ve seen (FontLab, Glyphs, TTH), thus one can easily map the paradigms in those apps to VTTalk commands. (e.g. YAnchor(), YLink(), YInterpolate(), etc). Obviously we’d have to extend VTTalk to support point names as well as numbers.

 

I’m also floating a proposal of breaking out the VTTalk compiler from VTT and releasing it as a cross-platform, open-source project. It would act as a reference implementation of VTTalk, as well as a library for applications to call. Ideally, it would just be an object you could import, so applications can just drop the compiler in their final build process. This would make it easy for applications to adopt the new language. Ideally, too, there’d be a command-line wrapper for build scripts.

 

Also, using VTT’s compiler means that any apps that use it will take advantage of the two decades of R&D that we’ve put into it. For example, the VTT compiler has a code optimizer in it which produces very small, tight low-level code, which is handy for keeping webfont file-size down. Also, there are some other enhancements that we’ve recently made (first used in hinting Microsoft Sitka), that applications could potentially take advantage of without extra work.

This would be absolutely fantastic.

1) would it be valuable to release VTTalk as the high-level language?

Yes. I can't say officially until I've done more research and heard more opinions, but I think it would have a very, very good chance of being the way that hints are stored in UFO. There might be some data compatibility problems that we'd have to resolve, but, yeah, this would be incredibly valuable for the entire industry.

2) is releasing the compiler useful (more specifically: who is interested in using it, and how would you use it)?

I'd be interested in it as a part of the UFO spec. The UFO spec could say, "here is the storage format <link to MS documentation>" and "here is how that must be interpreted <link to other MS documentation>." That would solve so may problems with just a couple of links.

As a type developer, I'd be extremely happy if the compiler and all of it's decades of experience could more easily be a part of my workflow.

Thanks,

Tal

[Frank Trampe]

Would makeotf would [ideally] call the VTT compiler when compiling a typeface from U. F. O.?

--
You received this message because you are subscribed to the Google Groups "Unified Font Object Specification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ufo-spec+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Frank Trampe]

Oops. I put in an extra would!

Would makeotf [ideally] call the VTT compiler when compiling a typeface from U. F. O.?

[Adam Twardoch (List)]

I imagine that the potentially opensourced VTT code could be integrated with the already-opensourced AFDKO code in several kinds of ways. AFDKO has the makeOTF app, but also a separate autohint app for CFF outlines, and there could be a separate vttcomp app for TT outlines, with glue code added to makeOTF.

GUI app developers such as FontLab or FontForge could easily integrate these libraries on a higher, more user-transparent level.

A.

[Dave Crossland]

On 13 March 2015 at 11:25, Adam Twardoch (List) <list...@twardoch.com> wrote:

I imagine that the potentially opensourced VTT code could be integrated with the already-opensourced AFDKO code in several kinds of ways

I wonder if Adobe legal would accept a multiple-copyright-holder situation on the FDK codebase.

[Adam Twardoch (List)]

I think this would not be much different from AFDKO relying on, extensively using, and (in case of the "binary" AFDKO distro) bundling non-Adobe-copyrighted software such as fontTools, which is copyrighted by Just van Rossum and others, or MutatorMath, which is copyrighted by Erik van Blokland.

The "vttcomp" tool/library could be sourced from a separate repo and then bundled, just like is the case with fontTools, MutatorMath and probably other components of the AFDKO package.

A.

[Rob McKaughan]

See below:

 

From: ufo-...@googlegroups.com [mailto:ufo-...@googlegroups.com] On Behalf Of Tal Leming

On Mar 12, 2015, at 1:10 PM, Rob McKaughan <rob...@microsoft.com> wrote:

 

1. High- or low-level hints?

=================================

…

 

So: I really, really recommend storing high-level language, because that’s the source code for hints. Also, such a high-level language can be somewhat abstract so that it doesn’t have point number or glyph number dependencies, thus fits in nicely to a flexible workflow that UFO has enabled.

 

I agree with all of this. The problem that I'm facing from the perspective of the spec editor is that lots of people are putting hints in their fonts. It's a huge amount of time and money to produce these things. The UFO is meant to be a place where we can keep all of our important data, but some of our most important data is not being stored.

 

----------

Yes, the investment people have in existing hinted fonts is an important practical issue. I’d guess that a lot of folks also want to convert every typeface project they’ve ever done to UFO for archival purposes.

 

I’m assuming that when people get their fonts hinted, they’re not just getting the final hinted TTF back, but also the hint source (VTT TSI tables, VFB, etc). Is this a valid assumption? (I’ve little idea: I only know what we do at MS, and indirectly from talking to other companies). If so, one could write a tool that pulled the source from these file formats and stored it as high-level language in the UFO.

 

If there are foundries with only the final TTFs and no source, how common is this? If it’s a small number, then is it worth the pain to find a solution?

 

Interestingly, Microsoft has a case somewhat like this: Times New Roman is filled with lots of hand-tuned low-level hinting code. Even if we moved to an entirely UFO-based workflow, I suspect we’d leave TNR as-is for fear of breaking the world’s most commonly used font. We’d likely leave it in its current source file and deal with it.

 

The other case is ttfautohint, as that never generates a high-level language. For this case, though, I don’t imagine people edit the hints after ttfautohint, so you could just run it again in the build process rather than caching its output.

 

I guess my short response is: can we find ways of helping people migrate their existing hint source to UFO with high-level hints, without having to add all the extra complexity of dealing with low-level hints? I’d be fantastic if we could, but being new to this conversation, I’m still optimistic.

 

Another approach: do it in a phased way: support a common high-level hinting source so that people can start using that. Then, in a later rev of the spec, add low-level support if people still feel the need. I think we agree that having high-level hints would be useful, but low-level hint support would be Hard. I’d hate a solution for high-level hints to be stalled waiting for a solution to low-level hints.

[Adam Twardoch (List)]

> On 14 Mar 2015, at 04:27, Rob McKaughan <rob...@microsoft.com> wrote:
> I’m assuming that when people get their fonts hinted, they’re not just getting the final hinted TTF back, but also the hint source (VTT TSI tables, VFB, etc). Is this a valid assumption?

That is very different. This gets especially tricky when dealing with things like linguistic or script extensions. Some foundries have a font where the Latin has been hinted rather well, and they wish to extend the glyph set. They may be willing to compromise on the quality of hinting for the new glyphs, but would wish to retain the old hinting for the existing glyphs. That's a relatively common-use scenario for FontLab Studio 5: quite a few customers had specific questions about FLS5's ability to keep native bytecode hinting for "untouched glyphs". But this was far more common before ClearType and the popularization of FontLab and VTT. That is, that was most common in situations where the hinting had been added using some completely custom tools (not FL, not VTT), so no really portable sources for that hinting exists.

> If there are foundries with only the final TTFs and no source, how common is this? If it’s a small number, then is it worth the pain to find a solution?

I can't really tell how common this is. Of course there's always this possibility to store both the "native" glyphs and the native hinting in a closer-to-binary format and have a tool to pull them in when needed. In other words, you have your higher-level glyph sources in UFO, but for the glyphs you know you haven't modified and you want to keep the binary hinting, you pull in from a TTX source.

> The other case is ttfautohint, as that never generates a high-level language. For this case, though, I don’t imagine people edit the hints after ttfautohint, so you could just run it again in the build process rather than caching its output.

Indeed, currently it does not generate a high-level language. But in fact, last year Werner Lemberg told me that his tool would be able to emit some high-level hinting if a common language/syntax were decided upon. So -- especially if portions of VTT were opensourced -- there might be good chances that Werner could add a VTT autohinter.

> I guess my short response is: can we find ways of helping people migrate their existing hint source to UFO with high-level hints, without having to add all the extra complexity of dealing with low-level hints? I’d be fantastic if we could, but being new to this conversation, I’m still optimistic.

I think the extra complexity of low-level hints may indeed not really belong to UFO. After all, UFO does not have a low-level storage format for OpenType Layout features, just the relatively high-level FEA language. If you need to support your OTL at a lower level, you need to use a different format, such as TTX. Same would be the case for all the functionalities for which UFO has no storage, e.g. the MATH table or the CPAL color palettes.

> Another approach: do it in a phased way: support a common high-level hinting source so that people can start using that. Then, in a later rev of the spec, add low-level support if people still feel the need. I think we agree that having high-level hints would be useful, but low-level hint support would be Hard. I’d hate a solution for high-level hints to be stalled waiting for a solution to low-level hints.

I completely agree.

Regards,
Adam

[Tal Leming]

On Mar 13, 2015, at 6:57 PM, Rob McKaughan <rob...@microsoft.com> wrote:

Yes, the investment people have in existing hinted fonts is an important practical issue. I’d guess that a lot of folks also want to convert every typeface project they’ve ever done to UFO for archival purposes.

 

I’m assuming that when people get their fonts hinted, they’re not just getting the final hinted TTF back, but also the hint source (VTT TSI tables, VFB, etc). Is this a valid assumption? (I’ve little idea: I only know what we do at MS, and indirectly from talking to other companies). If so, one could write a tool that pulled the source from these file formats and stored it as high-level language in the UFO.

Yes. I don't know about anyone else, but my main hinting is initially done with VFBs. I wrote a little conversion tool that stored the data in the lib portions of the UFO. I could get the data out of FontLab and back into FontLab. Similarly, FontLab's vfb2ufo tool will convert their data structures into a private area of the UFO. This works fine for short term storage and current workflows. It's not future proof against the tools that know how to translate that into TTF going away.

I guess my short response is: can we find ways of helping people migrate their existing hint source to UFO with high-level hints, without having to add all the extra complexity of dealing with low-level hints? I’d be fantastic if we could, but being new to this conversation, I’m still optimistic.

I'd love to have a high-level implementation. The reason that I had for going with the low-level code was simple practicality. I often edit hints in FontLab, but I always generate final fonts in RoboFont. The only way that I can do that is if the high-level FontLab data is translated to low-level code. Luckily, the TTH extension does this. But, it only does it when it is running, so if I modify outlines outside of that tool and then try to generate a TTF something bad could happen (in theory). The process works, but only in RoboFont. It would be nice if that application dependency could be broken. If we had a high-level representation, the need for the low-level code would be greatly reduced.

Another approach: do it in a phased way: support a common high-level hinting source so that people can start using that. Then, in a later rev of the spec, add low-level support if people still feel the need. I think we agree that having high-level hints would be useful, but low-level hint support would be Hard. I’d hate a solution for high-level hints to be stalled waiting for a solution to low-level hints.

I'll put my "Standardize The Low-Level Nasty Stuff" process on hold until we know if a high-level representation could be possible.

Thanks,

Tal