Integrate with Fontship

[alerque]

I am the primary developer of Fontship, a font building package that aims to simplify the build and release process for font projects and enable more collaborative workflows specifically benefiting open source font projects. I've been developing it under the auspices of The League of Moveable Type because that was their font collection was the initial impetus for the work. I was trying to package their fonts into distro packages and frustrated at how different the build and release systems for each font were.

I've since joined up with The League in the capacity of cleaning up their repositories and developing Fontship. So far I've helped update and release new packaging for Raleway and League Spartan. Very shortly now League Mono will join that list, with the rest of the foundry's library to follow. Another open source font I've been publishing through Fontship is Libertinus.

I think we should probably have a talk about how to integrate Fontship with Fontsource. Clearly this is of mutial interest. First I see that The League on your list of open source foundries that you support even outside of being available on Google Fonts (some are, some are not). That's great! A few of them are out of date, but I'm glad to see packages anyway. Of course updating them would be in order, but I'd also like to see closer integration.

A couple of issues I see need airing out:

• At first glance at least Fontsource appears to rely on upstream font projects committing font build artifacts to their Git repositories. This is a serious anti-pattern that I consider anathema, is finally starting to be discouraged by Google Fonts (one of the primary early drivers of this terrible workflow), and isn't even too kosher by GitHub TOS.

• Second I would like to specifically enable font project owners to publish their own NPM packages. I don't have an issue with a third party publishing them under an obvious namespace such as fontsource is doing, so that isn't a criticism of the project, just stating my goal that font projects themselves would be able to publish "theirfont-webfont" or similar packages in addition to you also maybe publishing "fontsource-theirfont" packages.

• Versioning is an issue. I'm not too keen on the NPM packages being a miss-match for the actual font versions. I'm a firm SemVer supporter, but the font ecosystem is kind of limited by the OFF/M$OT specs that specify a two segment version string. For Fontship I am mandating the use of OpenFV compatible versioning. This is a lot better than many current font projects do, but still doesn't make to SemVer very consistently.

There are two open issues on Fontship relevant to this, theleagueof/fontship#88 and theleagueof/fontship#77. Fontship already generates various formats including webfont (WOFF & WOFF2) builds by default. What we don't do yet is generate any CSS templates to ease use as a webfont. I would be interested in hearing your suggestions on how that should be done, and also on generating NPM packaging.

In my head at least an ideal solution would be a fontship make npm or similar target that would generate a package ready to publish to NPM. This target could be run from CI jobs (as currently can be done for other distribution packaging) and automatically published to NPM for tagged releases. I would expect that any repository that was laid out to be Fontship ready would also be very easy to generate Fontsource packages from because they will be so normalized, but you will need to use releases not repository tracked binary files.

[ayuhito]

The idea to integrate Fontship with Fontsource is an interesting concept but I'm not wholly sure how that will pan out practically.
Exactly what would we be directly integrating?

Workflow

At first glance at least Fontsource appears to rely on upstream font projects committing font build artifacts to their Git repositories. This is a serious anti-pattern that I consider anathema, is finally starting to be discouraged by Google Fonts (one of the primary early drivers of this terrible workflow), and isn't even too kosher by GitHub TOS.

For Google Fonts, we rely on Google Font Metadata that automatically parses the Google Fonts Developer API and generates even more necessary datapoints by fetching their CSS API as well before aggregating it all into one file. This is automatically updated and checked on a weekly basis.

For all other fonts, it is manual implementation. I grab the latest release on their repository and after chucking their files through Fontsource's packagers to standardise it with the rest of our fonts, it is then published. Updating the fonts is also a manual process. You may consider that an anathema, but what do you suggest to change in our workflow that resolves that?

In the long term, I do want to look into automating as much of this process as I can - but every repository seems to do things a little differently, needing a manual touch. Fontship running on all League fonts may prove to be beneficial as it would standardise how those fonts are published, although of course, I'd want to see a bit more widespread use of that before building automated scripts dedicated to that process.

Versioning

Versioning is an issue. I'm not too keen on the NPM packages being a miss-match for the actual font versions. I'm a firm SemVer supporter, but the font ecosystem is kind of limited by the OFF/M$OT specs that specify a two segment version string. For Fontship I am mandating the use of OpenFV compatible versioning. This is a lot better than many current font projects do, but still doesn't make to SemVer very consistently.

Versioning is an interesting topic with Fontsource. We follow a semblance of Semver but not a perfect rendition of it. A quick look at our changelog shows that major and minor updates are dependent on whether Fontsource updates its packaging methods. Patch updates, on the other hand, might be a mix of either Fontsource or an update from the source itself, which may potentially be a big change that we have no notice or control over.

However, we always also link the source version at the bottom of each package README as well, as seen here. I think that is the best compromise between managing Fontsource's and each individual source's versioning.

Packaging

What we don't do yet is generate any CSS templates to ease use as a webfont. I would be interested in hearing your suggestions on how that should be done, and also on generating NPM packaging.

Arguably... that is the whole purpose of Fontsource. We use lodash's template function to build the CSS whilst stuff like package.json is simply just exporting and writing an object. I do want to research that a little and see if there are better solutions for the sake of reliability and future maintenance, but it isn't a too high priority task currently.

[alerque]

Thanks for the detailed response @DecliningLotus. I see I was under some misunderstanding about how fontsource works under the hood. I'll be getting back to this eventually with a more detailed proposal of how I envision closer integration could work.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
Use the 'not stale' label to prevent the issue from automatically closing.

[alerque]

Nope not stale, still working on this.

[ayuhito]

Hiya @alerque, are you still interested in pursuing this? Just checking in as it's been around 6 months since the last discussion.

[alerque]

Yes. Personal and local concerns have demanded that I clear out some FOSS time and I've been dodging all font related stuff for a while now. I'll jump back in as soon as I have the bandwidth and this is definitely still on my radar.

[ayuhito]

No worries then! Just a checkup while doing some repo cleanup. Thanks!

[ayuhito]

Appreciate the original issue, but I think I'll close this issue to clean up some of the stale issues in this repository. If this ever comes to fruition, feel free to reopen or create a new issue!