You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Git workflow for forking/customizing single glyphs #189
first, let me say: This is a great project, chapeau especially to @rsms Inter is already a very solid grotesk typeface and since being open source it could become a go-to tool for many projects and really become a sans-serif big player.
This is a question: I'd like to edit some glyphs to fit my personal preference better using GlyphsApp (talking about taste, not enhancement per se). How could a workflow possibly look like for src/Inter.glyphs to be able to merge changes/updates on the main project back while keeping my customizations. And at the same time keeping the possibility to participate.
Does someone have a workflow in place for such changes or suggestions on the smoothest possible way? I fear that it could be quite troublesome impossible to check for changes in the source file, since relatively small changes result in quite a lot of changed lines (timestamps and so on).
What I thought of so far: Splitting out the glyphs for editing or using stylistic sets/alternates? Stylistic sets being the easy way of course with the downside that some tools I use might have trouble with OpenType features. So being able to freely edit would be my preferred solution.
Create one commit for every logical change you make. For instance, if you want to make changes to two different glyphs, change one and commit the changes, then change the other and commit again.
Use the “export” function in Glyphs to generate font files. You can also use the Inter toolchain to build “production” font files, but that requires a bit of work in a terminal.
There are ways to convert the glyphs file to UFO for exporting to other font editor formats. For instance glyphsLib.
The .glyphs format has not been designed for version control workflows like other source code, you will most likely end up having a bad time there. Consider using glyphsLib to convert the .glyphs files into UFOs, where each glyph is put into a separate file. Sourcing upstream changes would then require you to fetch a fresh .glyphs file and glyphs2ufo-ing it onto your UFOs.
Activity
[-]Git workflow for forking inter[/-][+]Git workflow for forking/customizing single glphys[/+][-]Git workflow for forking/customizing single glphys[/-][+]Git workflow for forking/customizing single glyphs[/+]rsms commentedon Sep 4, 2019
I’ll make this a todo for adding documentation.
In the meantime, the cleanest way to contribute:
For contributions meant for upstream:
For forking: (no intention to get contribute back)
There are ways to convert the glyphs file to UFO for exporting to other font editor formats. For instance glyphsLib.
madig commentedon Sep 12, 2019
The .glyphs format has not been designed for version control workflows like other source code, you will most likely end up having a bad time there. Consider using glyphsLib to convert the .glyphs files into UFOs, where each glyph is put into a separate file. Sourcing upstream changes would then require you to fetch a fresh .glyphs file and glyphs2ufo-ing it onto your UFOs.
rsms commentedon Oct 23, 2019
A shortcut for generating UFOs:
This will generate all UFO files into
build/ufo/together with.designspacefiles.You can also manually generate master UFOs into any directory like this:
To manually generate instance UFOs, run
fontbuild instancegen <designspace> <style>. Example:(Note: Instance UFOs are always written to
build/ufo/)