UFO sources?

[ctrlcctrlv]

Cool project!

I wonder: thoughts on UFO sources, instead of only TTF?

[psb1558]

I do intend to read and write UFO sources--it shouldn't be difficult. I'm not sure of a timeline: at this relatively early stage of the project, my to-do list is pretty long.

[ctrlcctrlv]

That's understandable. When/if you finish it, it's no problem for me to include w/the MFEK distribution. I'd call it MFEKtruetype but of course prominently display the source, that's just for internal consistency with the other tools. My only real requirements are that it be ① really useful; ② not reliant on one specific font editor or another; ③ Apache-2.0 compatible; and ④ cool.

[ctrlcctrlv]

(And if you never get to it, I may end up doing it or hiring someone to do it. :-) )

[psb1558]

Oh, I'll get to it. It came up a while ago in the Typedrawers forum, and it's been on the to-do list for a while.

I wouldn't call it cool, though.

[ctrlcctrlv]

Really? Why not? It's really cool!

[psb1558]

Thinking aloud about a plan for this.

Looking over the UFO spec, I can see how to store ygt source (or, eventually, VTTTalk) in private dictionaries in the UFO. Storing in the UFO this way should be the default "save" behavior when either (1) user started the project by reading a UFO or (2) the current session began with ygt code read from a UFO. "Save as" will override the default behavior

"Export" should offer user a choice: export to .ttf font or export to UFO (either store TrueType "assembly" code in an existing UFO or write a new UFO if necessary).

Comment?

[ctrlcctrlv]

That makes total sense to me!

[psb1558]

A progress report. (I'm not putting this in the repository until it's complete.)

Just as you can begin a project by opening a .ttf font, so you can now begin one by opening a UFO. After that, ygt stores its source in the UFO data directory instead of in a separate .yaml file. (The data directory was new in UFO 3, so the UFO needs to be at least that version to work properly.)

There are two next steps. One (the easy one) is to export compiled TrueType instructions to the UFO (instead of generating a new TTF). I say it's easy because UFO 3 prescribes places to put all instruction-related data, and fontTools provides methods for storing it.

The second step is "save as," necessary for moving back and forth between free-standing ygt source and ygt source stashed inside the UFO. This is more complicated because, while reading a UFO and afterwards generating a .ttf is easy, I can't find a tool for going from .ttf to .ufo without calling an external program, which I don't particularly want to do.

So I am thinking of saying that I'm not in the business of generating UFOs. If you have a free-standing .yaml file and want to "save as" a UFO, you'll need to select an existing UFO (version 3 or higher) to save in.

I'm still hoping to find a suitable tool for saving a UFO, but this is the state of things right now.

[psb1558]

This feature is complete but subject to revision and debugging.

The behavior of ygt is determined by the extension of the source file.

If you begin a project by opening a .ttf file, the source is saved as a .yaml file and "Export" produces a hinted .ttf font.

if you begin a project by opening a .ufo, the source is saved in the data directory of the UFO and "Export" writes hints and associated data to the places in the UFO prescribed by the UFO3 spec.

"Save As" lets you move back and forth between these two modes. I'm not sure I'm completely satisfied with the behavior of "Save As" yet: I might have to add a separate menu item File-->Save to UFO, since the behavior of "Save As" is different depending on whether you're writing a new .yaml file or updating an existing UFO.

An important point:

Ygt is happy to hint a font with CFF outlines, even though CFF fonts can't be hinted with TrueType hints. If you do this, you should hide off-curve points display and record points as coordinates (View-->Point coordinates), since the point indices of the generated font will be different from those displayed by ygt, and the off-curve points will be different as well. Further, before you export TrueType hints to a UFO, you should make sure that it contains quadratic, not cubic outlines: otherwise the point indices will be catastrophically wrong.

You can change a UFO's cff to quadratic outlines by running cu2qu on the UFO.

Finally I should say that I have no idea whether any program can make use of hints embedded in a UFO3, though it would be easy to do so.

[psb1558]

The UFO-handling version of ygt is in the repository now.

[verbosus]

Hi Peter, when working with UFO 3 sources, I guess it’d be useful to somehow be able to specify which layer to take the outline data from. That way, one could store cubic outlines in the foreground layer, but have quadratic outlines elsewhere in a background layer, ready to be hinted.

[psb1558]

@verbosus: Good idea. I'll look into it.

[psb1558]

So far I'm not finding a lot of facilities in the standard UFO tools for dealing with layers: ufoLib2 knows about layers, but it seems there's not much in fontTools.ufoLib or ufo2ft (which converts a UFO to a fontTools TTFont.

What are you using to manage layers in your UFOs?

BTW, you can base your hints on the on-curve points in a CFF font. Just set up Ygt to use coordinates instead of indices as point identifiers and turn off display of off-curve points.

I haven't done a lot of experimenting with UFOs yet, and I've still got a good bit to learn.

[verbosus]

With fonttools.ufoLib you can get a list of all layer names and use that to get a GlyphSet with a specific layerName.

defcon is also aware of layers, as is ufoLib2 as you mentioned. The latter two are requirements of ufo2ft. While the layer support in ufo2ft is not entirely comprehensive, I’ve been landing a few patches that aim to improve that, which is then reflected in fontmake. For instance, it is now possible to build static instances from a UFO source specifying a custom layer—though I’m still working on a patch for the variable font path.