public-sans
public-sans copied to clipboard
uswds
Keep the repository strictly for source files
I would personally structure the repository to keep binary, exported font files, strictly separate from the source. If you update the release with each commit, you get a much cleaner workflow. I very rarely see it done the way I am suggesting though, so hopefully someone can educate me if I’m missing some essential information.
I'd been thinking about doing just that — the catch is (I think) that I'd need to to develop a script that compiles the exported files on my preview server so I can check to make sure everything is working properly. I don't wish to keep a git history of every exported binary, but I haven't been able to work a way around it yet.
I'm positive someone knows knows how to do that — and maybe it's you.
I don't wish to keep a git history of every exported binary, but I haven't been able to work a way around it yet.
Absolutely agree with this. I think the cleanest way of doing this would be to kick the exported binaries over to the releases section and to keep the release version number in sync with the version counter in the .glyphs source files. For every commit, you increment the version number in both places which would at the same time take care of issue #38.
As for the script you’re requesting, I am unfortunately not competent enough with scripting to make it happen, but perhaps @mbutterick has some experience with this?
You can use a continuous integration (CI) service like Travis CI, Appveyor, etc. to compile the fonts with fontmake and upload binaries to GitHub's release page in this project.
For example, fontTools does this: https://github.com/fonttools/fonttools/blob/master/.travis.yml#L87-L99. The resulting .whl files are attached to (tagged) releases here: https://github.com/fonttools/fonttools/releases.
Addendum: fontmake will not give you bit-identical binaries to what Glyphs.app produces; fontmake uses ufo2ft plus fontTools and some other things, Glyphs.app uses Adobe's AFDKO. If you don't have the time to do deep OpenType engineering, you may get away with using a Mac-CI service and running Glyphs from there. Or, you keep it simple and simply attach the finished binaries to a release: https://help.github.com/en/articles/creating-releases
Excellent — thanks @madig. I'm going to check out what you recommend and go from there. I do agree that this is the proper way forward. That said, I think I do want to maintain the UFO files in the repo as they potentially allow some cross compatibility. Does that make sense?
That said, I think I do want to maintain the UFO files in the repo as they potentially allow some cross compatibility. Does that make sense?
You can; it does definitely make more sense than the inclusion of binary files, although I would probably keep them in releases, myself as they are, as the binaries, derivatives of the source.
By the way, I think you might want to remove the _archive folders from the repository. Not only do they make the repo take up a great deal of storage, but their function is, as far as I can tell, already covered with the commit history.
@thisisdano yes, makes sense. It's what I'm doing for my Cantarell project: https://gitlab.gnome.org/GNOME/cantarell-fonts.
The problem with keeping the binaries out of the repo is that users expect to find them there. Typically font binaries are small, the number of commits is in the low thousands, max, and it just doesn't add value to users to overcomplicate the repo organization.
But it's impure ;)
The problem with keeping the binaries out of the repo is that users expect to find them there.
The user shouldn’t. The user doesn’t expect to find the binaries for any software in the source repository. No one would want all the binaries ever built of Mozilla Firefox or Chromium to be in their source repositories’ history. In any case, if they are in the repository for use in documentation, examples or as you say because the user expects them there, then at least make sure to use GIT LFS.
I think users can be expected to look into the "Releases" section, the readme can also point them there.
I think it's important to keep in mind that 'users' in this case are people who want font files, not necessarily people who are used to the structure of open source software repositories. To be honest I think @davelab6 is right based on my own experience that in many cases, the people coming to the repository are just looking for font files, not the source at all.
So I suppose it might follow that putting them wherever makes the most sense could be fine, as long as it's made very clear how to just get the fonts themselves. So maybe what @madig suggests isn't a bad idea, so long as the readme is very explicit right up top with links to the latest fonts themselves.
The user shouldn’t.
The user shouldn't, no, but they do anyway. 🤣
The user doesn’t expect to find the binaries for any software in the source repository. No one would want all the binaries ever built of Mozilla Firefox or Chromium to be in their source repositories’ history
But fonts aren't "software," they are "just files"
I think it's important to keep in mind that 'users' in this case are people who want font files, not necessarily people who are used to the structure of open source software repositories. To be honest I think @davelab6 is right based on my own experience that in many cases, the people coming to the repository are just looking for font files, not the source at all.
This is why you set up a mini-site (public-sans.digital.gov in this case) with a downloads section linking to the latest GitHub release. Keeping binaries in the repository is just bad practice.
That's the way to go I think, but I don't see a download button on that site :O
Thank you, @thisisdano for removing the archive folder and for adding a big, blue, download button on the mini site. Nice work.
@madig I think now Github also supports CI/CD pipelines, under the feature "Github Actions" natively instead of using Travis. https://github.com/features/actions
I think it's important to keep in mind that 'users' in this case are people who want font files, not necessarily people who are used to the structure of open source software repositories. To be honest I think @davelab6 is right based on my own experience that in many cases, the people coming to the repository are just looking for font files, not the source at all.
Till the font production automation gets a lot better and easier to set up, please keep pre-generated canonical otf/ttf files in the repository. That may change in the future but right now that’s what users (and downstreams) expect.
