what is the purpose of the derivedchars file?

[mbutterick]

Source Serif’s master styles each have a derivedchars file (for instance).

I have found no explanation of these files other than @frankrolf’s mysterious comment that “it is just the way we’ve been creating our accents (and other components) all along.”

It seems to be a DSL for specifying and building component glyphs. I can see how it works, roughly. But I also see that the Source Serif UFOs contain all their component characters. In what way does the derivedchars file “create” the accents?

[frankrolf]

The derivedchars file is a means for storing accent positions in relationship to a base glyph. In addition to that, a derivedchars file can also store recipes for composite glyphs, such as IJ

The derivedchars language looks like this:

# simple derived glyph
/En DerivedName
(H) Base
EndDerived

# simple derived glyph with width adjustment
/eight.tosf DerivedName
(eight.osf) 12 0 Base
558 Width
EndDerived

# accented glyph
/ocircumflex DerivedName
(o) Base
(circumflexcmb) AddCentered
EndDerived

# accented glyph with offset
/egrave DerivedName
(e) Base
(gravecmb) 21 0 AddCentered
EndDerived

# adjacent accent
/dcaron DerivedName
(d) Base
(caron.alt) -51 0 AddAdjacent
EndDerived

# flush left accent
/Alphatonos DerivedName
(Alpha) Base
(tonos.cap) 76 0 AddFlushLeft
EndDerived

For creating/reading derivedchars files, dvInput/dvOutput scripts exist. Those scripts are not public, but perhaps they should be.
As far as I can tell, the derivedchars workflow has been around for a while – I remember using it in FontLab days. Perhaps it comes from a time when not many accented glyphs could be stored in font files?

Why does the derivedchars workflow still exist?

The derivedchars workflow is based on the desire to adjust accent positions for every glyph, independent from any anchors (the average position of which can be a little limiting for the variety of accent shapes – circumflex for example might be lower on an A than on E). Some famous designers on our team like to work on accented glyphs as a separate step – “reset” all accents to the horizontal center of the glyph, and then adjust them one-by-one.

Since I have been working on fonts that need to support combining marks, I usually build all accented glyphs using anchors, and just create the derivedchars files as a means to double-check composite glyphs.
This entry would be a red flag, for instance:

/Aacute DerivedName
(A) Base
666 Width
(acutecmb.cap) -5 0 AddCentered
EndDerived

I hope this answers your question.
Please indicate if there’s any interest in publicizing the dv scripts – I’d bring it up with my colleagues then.

[mbutterick]

• Which tool consumes the derivedchars file? The makeotfexe compiler? (Edit: you mentioned dvInput and dvOutput but I mean more broadly, where does derivedchars fit into the workflow)

• You say that you use derivedchars to “double-check composite glyphs”. But can the composite glyphs be omitted from the source file entirely, and instead created by derivedchars?

• If so, are there other [dis]advantages to using derivedchars? Do you consider it archaic / obsolete / deprecated?

• As for opening dvInput and dvOutput — arguably, since most of the AFDKO toolchain is now open-source, and Source Serif is too, and derivedchars is not deprecated within Adobe, perhaps that would make sense. So you have my vote, though I recognize it would require more.

[frankrolf]

Which tool consumes the derivedchars file?

Only the dvInput/dvOutput scripts

Can the composite glyphs be omitted from the source file entirely, and instead created by derivedchars?

They could, but that gets hairy with kerning, group assignment, etc.

If so, are there other [dis]advantages to using derivedchars? Do you consider it archaic / obsolete / deprecated?

There are many different ways to achieve the same result, and while handling derivedchars files might be a bit cumbersome, they still are a valid way of building accented glyphs consistently.

As for opening dvInput and dvOutput — arguably, since most of the AFDKO toolchain is now open-source, and Source Serif is too, and derivedchars is not deprecated within Adobe, perhaps that would make sense. So you have my vote, though I recognize it would require more.

Noted.