ir notes #37
ir notes #37
Conversation
|
|
||
| - Designspace file maps UFO(s) into design space | ||
| - UFO font has layers | ||
| - Layers have glyphs |
There was a problem hiding this comment.
(FWIW. UFO can be mapped to "Font has glyphs, glyphs have layers", which is what Fontra is doing.)
There was a problem hiding this comment.
interesting, how does that work concretely? Does the UFO default layer's contents.plist file define the font's glyphs set and then the presence of given named glyph in the other non-default layers count as 'that glyph having that layer' (rather than the other way around)?
And how does this way of thinking of UFOs interact with designspace? I suppose you rely on mutliple DS source elements all pointing to the same UFO filename and having a layer attribute set to select where to source glyph definitions.
There was a problem hiding this comment.
the presence of given named glyph in the other non-default layers count as 'that glyph having that layer'
Yes, that is the easy bit.
I'm not claiming it is trivial to do perfect round-tripping, and my implementation isn't even complete. It can still deal with multiple UFOs and multiple layers per UFO, and I maintain a mapping between "glyph layer identity" and "ufo source + layerName". It will become somewhat more complex once Fontra is able to create new glyph layers and sources that don't already exist in the DS system as it is.
There was a problem hiding this comment.
I'm realizing that I don't really understand what "layer" means in this context or what it maps to in the final binary?
There was a problem hiding this comment.
Both in .glyphs and UFO/designspace, a glyph layer contains the master shape for a specific designspace location. Additionnally, such layers are used by designers as a scratch layer or a background layer, which will be ignored for the final binary.
There was a problem hiding this comment.
For a bare UFO, only the default layer matters to a compiler. For a Designspace, every default layer of every referenced UFO matters, plus the DS sources that reference a specific layer inside a UFO. All other layers have no meaning to the compiler.
There was a problem hiding this comment.
Do you happen to have an example of a font using a DS source that references a specific layer lying around?
There was a problem hiding this comment.
|
|
||
| enum Shape | ||
| Contour(Contour) | ||
| Component(Component) |
There was a problem hiding this comment.
In UFO you can indeed mix outlines with components. In retrospect I've found this needlessly complex. A model where you have a hard distinction between outlines and components as attributes of the glyph instance is much easier to work with. Something like:
struct GlyphInstance
advance
contours: Vec<Contour>
components: Vec<Component>
There was a problem hiding this comment.
i agree it's better/easier to work with to have two separate lists of contours and components instead of a single vector of either contour or components.
The respective ordering of contours/components shouldn't matter in the end because in the output binary format mixed glyphs are going to be decomposed and the order of contours does not change the rendering (winding direction does).
Having said that, there's one thing that may care about the ordering of contours/components, and that's truetype instructions that refer to glyph point indices, see unified-font-object/ufo-spec#169
Not sure if we care about representing those in the IR.
There was a problem hiding this comment.
TT can't mix outlines and components, so I think that's a non-issue.
There was a problem hiding this comment.
sure, in the binary TT file you can't mix, but in the source one may want to mix and at the same time also have truetype instructions that refer to point indices. Even so, a compiler's composite glyph decomposition procedure could take care of remapping those indices accordingly. Anyway, this was all just hypothetical, am not suggesting we should use that as an argument for a mixed Vector[Union[Contour,Component]]
There was a problem hiding this comment.
Forgive my density but I'm not quite grasping why it is better to have separate lists, particularly in Rust where the enum for this is very natural?
There was a problem hiding this comment.
Observation 2: both defcon and ufoLib2 separate contours from components. These are the two most used libraries in Python-land to write UFO, and both can't round-trip arbitrarily mixed contours/component sequences.
There was a problem hiding this comment.
important when interpolating
Apparently I momentarily forgot variations. Some say they are important.
both can't round-trip arbitrarily mixed contours/component sequences
This does feel like it's adding up to no significant benefit to mixing them together. I wonder why https://unifiedfontobject.org/versions/ufo3/glyphs/glif/#outline is the way it is then.
There was a problem hiding this comment.
I wonder why https://unifiedfontobject.org/versions/ufo3/glyphs/glif/#outline is the way it is then
Legacy. Insights progressed since. UFO is from 2001, 2? Fontographer did it that way. There's probably more to be found along those lines...
(The .glyphs format also seems to be able to arbitrarily mix contours and component references, FWIW.)
There was a problem hiding this comment.
.glyphs format also seems to be able to arbitrarily mix contours and component references
If Glyphs gains COLRv1 support and leverages the order of mixed contours and components we might find ourselves merging them back together. However, that's speculative so I think it's OK if we don't worry about it for now.
|
Bonus points if the IR could be reused by https://github.com/daltonmaag/Fontgardener, making fontgardens a serialization format. |
|
Merging because I think we have enough to be useful, will continue to update if additional comments, issues, or PRs flow in. |
Rendered