daltonmaag / file-format-discussion Goto Github PK

DaMa use-case that crops up on larger projects: A font family contains multiple scripts which develop at different speeds (from drawing outlines up to kerning and hinting) but may need e.g. Latin glyphs for reference (or use as components in different script, e.g. Cyrillic A). Currently, one has to insert the needed glyphs into other UFOs. Maybe add ability to reference external files?

Two things here: A Cyrillic/Greek font may reference glyphs as components (e.g. "A"), a Hebrew font might want to include Latin numbers in the final font. So a UFO may include external glyphs in the glyph set for compiling into a final font and may reference them as components.

I'm concerned that relying on location to distinguish discrete and continuous axes in the proposed designspace 5 is inadequate. For example, the italic axis as defined in the OTVar spec would seem to be identical to a discrete italic axis in a designspace file.

Variable fonts allow masters to act on regions, so each delta can have a min, peak and max location. But old DesignSpace only allows specifying peak.

This makes building fonts with locally-active masters impossible when one uses tools like fontmake.

Also, with the image below, if I add a master like shown in (2), then its deltas bleed across the varspace as shown in (2), effectively polluting the varspace. Currently, one has to create a fake counter-master as shown in (3) but it's tedious and inefficient. We’d like the interpolation to work as shown in (4), without the fake counter-master.

DS5 should allow defining min and max of the master's location, not just peak.

Corner components means that you take an outline and insert it into another outline at a specified point. I suppose you can already store the necessary metadata, but a compiler needs to know about it.

Smart components is, from what I understand, interpolation within the same font. Glyphs can have their own private axes and other glyphs can use these glyphs as instantiated components at arbitrary axis locations. This would be a pre-processor step for a compiler (fetch component and interpolate as specified in the glyph, place (decomposed?) result in glyph).

The metadata for both can be stored in UFOs already, but a design tool needs to know about them to understand what to do. Maybe a formalization helps.

@twardoch: what smarts would FL6 like to store?

Pick up this point from the UFO roadmap:

charactermapping.plist: A new file that defines character to glyph name mapping will be added. To prevent duplicate or conflicting data, the element will be removed from the GLIF specification.

The mapping should probably be global/the same for an entire project.

Instead of listing all instances serially, one could define a lot of instances as combinations. E.g. the following would generate 10 * 3 * 4 = 120 instances, by iterating through the combinations of values for each axis.

<instance-matrix>
  <axis name="Weight" values="100 200 300 400 500 600 700 800 900"/>
  <axis name="Slant" values="-20 -12 0"/>
  <axis name="Optical Size" values="9 16 24 72"/>
  <!-- maybe other things like naming scheme for filenames? -->
</instance-maxtrix>

The names of each instance would be inferred from STAT data.

Pros:

• Easy way to avoid very long list of instances for a complex designspace
• Relies on STAT data and automation = avoids user error in instance definitions

Cons:

• Not easy to override specific information about individual instances, without going back to listing them by hand?
• Could be achieved with Python code to generate the designspace file, or with a templating language (e.g. jinja2, erb...) on top of the XML, and would allow more flexibility than the above without burdening the designspace spec with more concepts and XML elements etc.

@chrissimpkins

I'm currently trying to write a script to infer Unicode values for glyphs that have none (think one and variants one.tnum and a localised one-hb). Inferring the value for one.tnum is usually easy, but what if one-hb is only accessible via a GSUB locl substitution? Currently, you have to compile a UFO with it's feature file and then go through the final GSUB table and map out the substitutions.

It would be nice if an ideal format would be able to store comprehensive layout data in a structured way so you don't have to compile code (features) to answer the question.

Possible inspirations: VOLT, FontForge?

The specification is largely unmaintained and unclear in some places. For example, the source name is required in the format description but optional in the SourceDescriptor API and only used for when a master is referenced by e.g. a glyph element.

Axis values changing semantics when a mapping is present also caught some people by surprise: fonttools/fonttools#1655.

Maybe it makes sense to get to a clean slate to work with and clean up the spec in a 4.1?

One can currently assign e.g. a UUID to a point and then reference it from the glyph lib element, but maybe it's nicer to attach e.g. hinting/smart component/anchor tpe information directly to where you want them.

Anchor discussion: unified-font-object/ufo-spec#32

Imagine you start with an existing family (Aktiv Grotesk, Segoe UI) that exists in various discreet instances already, and your job is to create a VF that can be used in a layout-preserving way. This means that both kerning and spacing have to match the static fonts at every pre-existing axis stop. This can be achieved by putting the glyph master at that position, which also increases the maintenance burden. Would it make sense to be able to put the advance width as separate master data at locations? The outline would then be interpolated as usual, independent of the advance width master. I know that outline and advance width are tied together, but at least for cases where the diff is a few font units, it may work well enough.

Often, I will a small number of sources to cover a wide range of style, e.g. weight. This works well for 95% of the glyphs in the designspace, but some need touch-ups somewhere in the middle of their interpolation. A good way to do this is via "sparse" sources which just contain a few glyphs, but not all glyphs, and (unless otherwise intended) no kerning or feature data. However, this process is a bit cumbersome and not very standardized, so it would be great to make more explicit in future versions of the DesignSpace spec.

I suggest adding an Apache license to this repo, so that any patent concerns are addressed.