Use .glyphspackage format for default font sources?

[eliheuer]

This repo contains font sources that provide an example of how the Google Fonts system works.

Would it make sense to use the .glyphspackage format for the demo font sources in order to encourage contributors to use that format?

In my experience the Glyphs format makes open-source collaboration using Git difficult if the person making the PR isn't fully trusted by the person receiving the PR. Being on the receiving end of a .glyphs file PR can be difficult because it isn't always clear what was changed in the single .glyphs file. Many PRs are for just changing font info or just changing outline data, and the .glyphspackage format splits these concerns up into separate files.

This might lead to a better dynamic between Google Fonts onboarders and open-source font developers who don't fully trust the Google Font onboarders to make huge changes to their .glyphs files.

As an example, the Junicode project is using .glyphspackage: https://github.com/psb1558/Junicode-font/tree/master/source/Junicode-Italic.glyphspackage

[florianpircher]

The single-file .glyphs format allows the file to be easily send via email or uploaded to the Glyphs Forum for support, which are reasons why Glyphs uses it by default. For any kind of VCS workflow I would strongly recommend the .glyphspackage format. As @eliheuer wrote, PRs merge cleaner, but you also get a better overview of what changed when staging files for a commit and you can filter the Git history for just a single glyph or a set of glyphs by limiting the log to those files.

[simoncozens]

That's a good idea. It's also Glyphs3 specific.

[eliheuer]

Sending via email or uploading to the Glyphs Forum for support shouldn't be an issue for most Google Fonts projects because they are open source. It's probably easier to just link the GitHub repo anyway. The only downside I see is it might confuse some people due to not being the default format in Glyphs.

[florianpircher]

I wrote a small cli tool to convert between .glyphs and .glyphspackage files: https://github.com/florianpircher/glyphspack. This should help integrate Glyphs packages into existing workflows that do not yet expect folder-based Glyphs files.

[eliheuer]

Thanks @florianpircher! I think the next step is trying to onboard a project with .glyphspackage sources to Google Fonts. I'm going to try using your CLI tool to convert Mekorot this week.

Making .glyphspackage the default might be something to look into in 2022, but for 2021 just getting some .glyphspackage projects through the system seems like a good first step.

[eliheuer]

Sadly, I just don't think there are good incentives for large-scale collaboration on Google Fonts projects right now.

I'm trying to change that with font NFTs that create better incentives for large-scale collaboration: https://www.nan.xyz/txt/libre-type-as-a-veblen-good/

But for now, this issue can be closed or ignored.

[simoncozens]

I just merged a PR to support glyphspackage in glyphsLib. Next step is to call it in fontmake.

[davelab6]

This is the right way. We should do this. Is anyone using g2 still? I think it's okay to forget g2 unless we have important users

[simoncozens]

googlefonts/glyphsLib#803 is merged, waiting on googlefonts/fontmake#931. I think @BornaIz still uses G2.

[florianpircher]

googlefonts/fontmake#931 is also closed now, thanks to everyone involved!

[simoncozens]

One more reason to wait for this a little bit longer is that the glyphspackage format changed slightly recently. Obviously only in very specific cases, but I'd quite like the majority of glyphspackage files we deal with to be the newer format.