Comments (19)
I think users can be expected to look into the "Releases" section, the readme can also point them there.
from public-sans.
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.
from public-sans.
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.
from public-sans.
could you publish it on npm?
from public-sans.
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.
from public-sans.
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?
from public-sans.
Seems the answer came right through the open door!
from public-sans.
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
from public-sans.
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?
from public-sans.
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.
from public-sans.
@thisisdano yes, makes sense. It's what I'm doing for my Cantarell project: https://gitlab.gnome.org/GNOME/cantarell-fonts.
from public-sans.
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 ;)
from public-sans.
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.
from public-sans.
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.
from public-sans.
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"
from public-sans.
That's the way to go I think, but I don't see a download button on that site :O
from public-sans.
Thank you, @thisisdano for removing the archive folder and for adding a big, blue, download button on the mini site. Nice work.
from public-sans.
@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
from public-sans.
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.
from public-sans.
Related Issues (20)
- Wrong weight on alternative `g` glyph HOT 3
- font-feature-settings, stylesets HOT 4
- Release is missiong the OFL.txt HOT 1
- "i" becomes "I" at start of every word HOT 4
- Public Sans - Bug: Update uswds compile to ^1.0.0-beta.3
- Public Sans - Feature: [add support for pinyin with tones]
- Awkward gap between capital A and lowercase m
- Remove Piece from Italic Character Latin Small Letter a with Ring Above: U+00E5 aring (å) HOT 1
- Feature request for a nerd font version HOT 2
- Subscript unicode values not set HOT 1
- Public-Sans: Create workflow to add triage label to all issues
- Public Sans - Bug: Some letters and sequences of DIN 91379 are rendered incorrectly.
- Public sans - Dependencies: Use node LTS 18
- Public-sans - Dependencies: Update python HOT 1
- Public Sans - Feature: single story lowercase "g" as an alternate glyph
- Public Sans - Feature: Consider making d, b, q, p distinct under reflection
- Public Sans - Feature: Additional stylistic sets for uppercase G
- The letter å becomes ǻ in italic
- Public Sans - Feature: Include variable woff2 files
- Public Sans - Feature: Update ruby & node version
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from public-sans.