Workflow: alternate version based on main version [solved]

I have one quite large family in one Glyphs file (Inter, 10 masters 2500 glyphs). A commercial client has asked to have a customized version of Inter made for them, so it would not be open source and can thus not be part of the main Inter.glyphs file. The changes/customizations the client wants are relatively small, affecting only 20% of the glyphs.

As I see it, there are two ways to solve this, two options:

  1. Fork (copy Inter.glyphs → ClientInter.glyphs)
  2. Some form of extension that contains only the changes, “layered on” or “inheriting from” the main Inter.glyphs

Now I’m wondering if there’s a way to do option 2?

(Option 1 has the big downside of being a fork; not receiving fixes and improvements to the main Inter version in the future. One could manually keep the ClientInter.glyphs in sync, but that’s a cost I don’t think the client wants to take on.)

Here’s an illustration of the “option 2” idea. An example where the “Client” version of Inter has a different /s but is otherwise identical to the main version:

1 Like

What kind of customization are you planning? Changing glyphs, changing instances, masters, custom parameters, features, …? The task becomes more difficult depending on the degree of inheritance that is required for the final, merged font file.

The changes will most likely be only to glyph design (shapes, sidebearings, kerning.) Features are maintained outside of Glyphs so I can use git to diff & merge those if needed. Codepoint mapping remains identical, glyphorder identical, etc. Only changes to glyph design and spacing. (Thank you for a good question!)

I would maintain a second Glyphs file that contains only the divergent glyphs and then have some script (Python script in Glyphs or external script) that copies the source Inter.glyphs file and overwrites the glyphs with those of the client file, resulting in a merged Glyphs file. You can either store the merged file somewhere and regenerate it as needed or export it directly as part of the script.

For Glyphs scripts, see https://docu.glyphsapp.com/

For an external built process, try the plutil program included with macOS (.glyphs files are property list files).

Sidenote: Consider using the .glyphspackage source format. It stores each glyph in a separate file which is generally better for version control systems and makes replacing glyphs from one font source with those of another font source trivial with shell scripting or even visually in the Finder.

That sounds like a decent option. I’ve written a lot of Glyphs scripts so shouldn’t be too much work. It will be slow though.

Re glyphspackage, fontmake—which I use in my build toolchain—doesn’t handle it:

$ fontmake -o ufo -g src/Inter.glyphspackage
fontmake: Error: In 'src/Inter.glyphspackage': Loading Glyphs file failed: ('Please supply a file path to a .glyphs file',)

Wrap your code in

font.disableUpdateInterface()
# ...
font.enableUpdateInterface()

and large changes to the font should be much quicker.


For fontmake and other external built processes that cannot handle .glyphspackage files, you can use my glyphspack to convert between the .glyphspackage and .glyphs file flavors:

For example, read a .glyphspackage and write the contents of the equivalent .glyphs file:

$ glyphspack SomeFont.glyphspackage

It’s a standalone binary, but there is only a pre-made binary for macOS in the Releases list. For other systems, you need to built the tool from source with cargo.

Otherwise, there is also a Python based tool that does .glyphspackage to .glyphs from @jkutilek:

1 Like

Re glyphspack/glyphspkg: Oh, that’s interesting. Would be easy to add as an intermediate step to my Makefile. Thanks Florian! (I’ll try glyphspkg for now; if you could include Linux x86_64 and optionally mac arm64 builds in your releases of glyphspack I could use that instead as I can’t possibly ask contributors to install rustc.)

The pre-made binary for macOS is universal, it runs on Intel and M1. I will have a look at offering more pre-made binaries, including the various Linux distributions on various architectures.

1 Like

I ended up with a git submodule setup and writing a simple patch script. I’ve created an example project here GitHub - rsms/inter-derivative-example: Example of a font based on Inter which showcases the workflow.

Thank you @FlorianPircher for all your help!

And I added pre-built binaries for x86-64 Linux and Windows to glyphspack :​)

[Bonus side note: The UIState.plist file is specifically designed to be ignored by Git, so that you don’t need to deal with display strings in Git anymore: Move `DisplayStrings` into separate file for .glyphspackage - #3 by FlorianPircher]

1 Like

There is another possible solution.
Make a copy of the .glyphs file. Remove all glyphs that should stay the same. Then add a “Import Font” custom parameter to the Font settings and choose the original .glyphs file. All glyphs, that are not in the opened file any more are now showing up in Font View with a lock.

5 Likes

Thank you for the tips.
Import Master can be useful too.

‘add a “Import Font” custom parameter’

Woah, that’s cool. I’ll have to try that setup out. Thanks Georg

1 Like

“I added pre-built binaries for x86-64 Linux and Windows to glyphspack”

Thank you for doing that

“The UIState.plist file is specifically designed to be ignored by Git”

I noticed. That’s so nice!

What happens with kerning?

Tried it today. This is a really powerful feature! However for my use case I don’t think it’s a good fit since I use fontmake to build font files (and from testing by just building, it does not appear to work with linked fonts.) But I guess someone could contribute that functionality to glyphsLib and/or fontmake :–)

Another “feature request” for linked fonts is some way to make components “cross over.” For example, if I wanted to customize just /A in a font, it would be neat if I could have all componentized derivative glyphs remain part of the original font (and source diacritics from it) but reference the customized /A component when being “manifested” in the customized font.

Edit: I was just thinking how similar this is to overlayfs in Linux. I bet you could do something similar using an overlayfs mount of two or more .glyphpackage directories.

Better to have both A and A.ss01 in your font, and all its composites:

  • duplicate (Cmd-D) all A diacritics
  • replace (Cmd-Shift-F) .001 with .ss01
  • recompose them on all masters (Ctrl-Opt-Cmd-C)

The advantage is that all linked data (especially kerning) can be taken care of as well. You can then disable their export and swap them with a Rename Glyphs parameter in the respective instances or variable font settings in Font Info > Exports.

2 Likes