UFO Roadmap Updates

[Tal Leming]

Hi Everyone,

We have updated the roadmap on the UFO site:

http://unifiedfontobject.org/roadmap/

This covers three things:

1. A decision on the "Single File UFO". We're going with ZIP. An example implementation is in code review: https://github.com/unified-font-object/ufoLib/pull/26
2. Define a new multi-font format. This is currently called "Unified Font Set" (UFS). This is a very early draft of the idea.
3. Add some things to the list of UFO 4 ideas.

Please let us know if you have any thoughts.

Thanks,
Tal

[Miguel Sousa]

Tal,

What about hinting? Has that been pushed to post-UFO 4?

M.

[Tal Leming]

A couple of folks said that they would look into storing hinting data and we're waiting for feedback on that. I'll update the list.

> --
> 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.

[Jack Jennings]

Sorry if this was covered elsewhere, but why not mandate a "root folder" name? For instance, "foobar.ufoz" must have a root folder "foobar.ufo"?

Jack

[Tal Leming]

This isn't explained in the draft, but it probably should be. It came down to a few of factors:

1. We discussed having a defined root name (or no root at all, which was my preference), but when you make a ZIP in the Finder, the UFO's base file name is used as the root. There isn't a way to specify what the root should be called. The main reason that we chose ZIP was that it will be very easy for designers to convert between the formats using off the shelf tools. So to stick to the goal of making things easy, after much sighing, we vague'd up the spec.

2. If we have the root name reflect the ZIP name, if the designer changes the name of the ZIP, the internal root is now incorrect.

3. vfb2ufo when creating a .ufoz gives the root the original UFO name, plus some random characters. (Someone from FontLab may be able to shed some light on this. I didn't spend a ton of time trying to figure out exactly what it does.)

Thanks,
Tal

> On May 25, 2016, at 2:04 PM, Jack Jennings <j...@ckjennin.gs> wrote:
>
> Sorry if this was covered elsewhere, but why not mandate a "root folder" name? For instance, "foobar.ufoz" must have a root folder "foobar.ufo"?
>
> Jack
>

[Dave Crossland]

Thank you Tal! :) Great to see progress on this front

[Adrien Tétar]

How about SVG-in-OpenType? Will SVG support be added in UFO?

Adrien

[Tal Leming]

I don't think we can change GLIF in a way that both supports everything that SVG does *and* does not require massive reworking of existing tools. SVG is deeply complex and requires an Illustrator like editor that is very different from the black/white drawing model used for the vast majority of type design. We always try to stay environment neutral in UFO so this presents quite a conundrum. That doesn't mean that I don't think UFO can't or shouldn't support this. It's more of a matter of figuring out how to do it without breaking tons of stuff.

We've been wrestling with this at more of an abstract level in UFS (see the notes about "documents.plist"). The same abstractions apply to UFO. When we started UFO, font format specifications were moribund. UFO could go three years between spec revisions and still need only a handful of changes to support new parts of OpenType. That's obviously not the case now so I've been thinking about ways to make it easier to deploy new UFO versions. To date, there have been two places where the changes have needed to happen quickly and it hasn't been possible: GLIF and fontinfo.plist. The problem isn't in updating the spec. The problem is that if we add something to the spec, existing tools need to become aware of these changes before they can support them at all. For example, if we add a <foo> element to GLIF, all existing GLIF parsers/interpreters will not know what that <foo> element is. They'll either raise an error saying that an unknown element has been found or they will simply ignore it and the data inside of the element will be lost. Neither of those is good for users.

In the case of GLIF, I don't think we can solve this since the format consists of custom defined XML elements. Any changes to GLIF are going to be major events. In the case of fontinfo.plist, I think the use of Property Lists is going to be extremely helpful[1]. We can tweak the fontinfo.plist spec to say that if an unknown key/value pair is found, the pair should be retained and rewritten into the UFO without modification. This will allow us to quickly update the UFO spec to handle new details without encountering massive data loss. These will be minor updates between major updates that support big new things. Yay!

The other things that I think will help will be the various lib locations and the data directory. The libs have been around since RoboFog and they are real world tested and work amazingly well. The data directory hasn't seen much use yet, but Adobe's use of it has shown that it is going to be useful. Between major updates, the spec can define public.* locations and formats for big new things in the libs and data directory. Those are already designed to be lossless, so it should just work.

Anyway, back to SVG-in-OpenType. Given the above tweak to fontinfo.plist, we could do something like the following (I haven't read the details of the SVG table spec in a while, so I may have some details wrong).

- add the necessary font-level data to fontinfo.plist
- store the SVG documents in data/public.openTypeSVGGlyphs/*.svg
- store the *.svg file name and any glyph-level data in representative GLIFs in a layer named glyphs.public.openTypeSVG.

Just a quick thought.

Thanks,
Tal


[1] HAHAHAHAHAHAHAHAHA[2]
[2] Please don't restart the Property List debate.[1]

[Denis Jacquerye]

Why not store SVG in the GLIF’s image like one can do for bitmaps?

There can then be info about which layer to use for the SVG-in-OpenType table.

[Denis Jacquerye]

I’m saying this because one may want to define anchors, guidelines, etc.

[Tal Leming]

> On May 26, 2016, at 10:54 AM, Denis Jacquerye <moy...@gmail.com> wrote:
>
>
> Why not store SVG in the GLIF’s image like one can do for bitmaps?
> There can then be info about which layer to use for the SVG-in-OpenType table.

Store the actual SVG in the image or a PNG representation of the SVG?

Tal

[Denis Jacquerye]

Store the path of the SVG in image.fileName.

[Tal Leming]

Hm. That would require anything that uses the displays the image element to be able to rasterize/display SVG. That may be non-trivial to implement.

I see your point about anchors and all of that. I was thinking that the GLIF could contain that kind of information and the SVG file located in the data directory would be be the outline data. The "glyph" would be a composite of the two. A tool that allows the editing of SVG glyphs could merge the two and present them seamlessly for the user*. A compiler could do the same to create an OTF.

*Hm. A rasterized PNG of the SVG in the image element could be really useful here. That would let a font editor allow a designer to do glyph things (anchors, metrics, etc.) without knowing anything about SVG. The individual SVG files could then be edited in Illustrator, Sketch or whatever and those tools wouldn't need to know anything about glyphs. The SVG -> PNG representation could be made with a commandline tool. Hmmmmm.

Thanks,
Tal

[Adrien Tétar]

I think what we would be looking at is primarily displaying the SVG, not editing it. Many toolkits have a way to display SVG since it's a fairly common format.

Anyway I think this should at least be given consideration in the roadmap file.

[Tal Leming]

Hi Everyone,

FYI, I pushed some changes to the roadmap addressing incremental updates and SVG-in-OpenType. Full version here:

http://unifiedfontobject.org/roadmap/

Diffs here:

https://github.com/unified-font-object/ufo-spec/commit/03cfac718c7d7a65ecd18189e1300762fff2dd99

Thanks for the feedback! It is all very helpful.

Thanks,
Tal

[Adrien Tétar]

Hey Tal,

Can anchor types be added into the roadmap?

https://github.com/unified-font-object/ufo-spec/issues/32

Thanks,

Adrien

[Tal Leming]

Yeah. I forgot about these.

Thanks,
Tal

[Adrien Tétar]

Hey Tal,

Have you thought of making kerning group membership a glyph attribute (as in glyphs app)?

Because right now one has to loop through all the groups twice, and that seems like an unnecessary extra step to just get a kerning value.

Adrien

[Frank Grießhammer]

Curious: How would that work with kerning exceptions?

from a two-dimensional keyboard

[Behdad Esfahbod]

The kern list doesn't change; just group membership.

behdad
http://behdad.org/

[Tal Leming]

> On Aug 3, 2016, at 1:29 AM, 'Adrien Tétar' via Unified Font Object Specification <ufo-...@googlegroups.com> wrote:
>
> Have you thought of making kerning group membership a glyph attribute (as in glyphs app)?

My own MetricsMachine does this. I maintain two mappings inside of the groups object in addition to the regular dict: glyphToSide1GroupName and glyphToSide2GroupName. These are updated as needed whenever the groups change by observing the group via notifications. The glyph objects have side1KerningGroup and side2KerningGroup attributes that are properties that do something like this:

def _get_side1KerningGroup(self):
font = self.font
if font is None:
return
groups = font.groups
return groups.getSide1GroupForGlyph(self.name)

Everything is always in sync this way. It works™.

Also, if you look at the lookupKerningValue function in ufoLib.kerning, there are two kwargs that can be used to send these cached mappings to the function. If those are given, there is no looping needed.

> Because right now one has to loop through all the groups twice, and that seems like an unnecessary extra step to just get a kerning value.

If the group membership are stored at the group level, anytime you want a group's contents you have to loop through all glyphs. It's a no-right-answer situation. In the UFO structure, this is what we went with. Apps can do whatever they want internally as long as they write the data back into the UFO in the correct format.

Tal