Consider proving full-featured fonts as alternatives to their trimmed counterparts

[blueset]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Google Fonts strip off a lot of useful OpenType features when offering fonts on their servers. Their configuration is currently only whitelisting a few features that only meets the bare minimum standard for a decent typesetting. Many commonly used features for finer typesetting occasions – like old-style/lining figures, small capitals, etc – are all missing from their trimmed version. This is also one of the reasons I am inclining to other alternative services or self hosting over Google Fonts for projects demand better quality typography.

References

Whitelisted features [ref]:

    _layout_features_groups = {
        # Default shaper
        'common': ['rvrn', 'ccmp', 'liga', 'locl', 'mark', 'mkmk', 'rlig'],
        'fractions': ['frac', 'numr', 'dnom'],
        'horizontal': ['calt', 'clig', 'curs', 'kern', 'rclt'],
        'vertical': ['valt', 'vert', 'vkrn', 'vpal', 'vrt2'],
        'ltr': ['ltra', 'ltrm'],
        'rtl': ['rtla', 'rtlm'],
        # Complex shapers
        'arabic': ['init', 'medi', 'fina', 'isol', 'med2', 'fin2', 'fin3',
                   'cswh', 'mset', 'stch'],
        'hangul': ['ljmo', 'vjmo', 'tjmo'],
        'tibetan': ['abvs', 'blws', 'abvm', 'blwm'],
        'indic': ['nukt', 'akhn', 'rphf', 'rkrf', 'pref', 'blwf', 'half',
                  'abvf', 'pstf', 'cfar', 'vatu', 'cjct', 'init', 'pres',
                  'abvs', 'blws', 'psts', 'haln', 'dist', 'abvm', 'blwm'],
    }

• Why don't all OpenType features work in fonts served via the API? google/fonts#1335
• Andrew Brampton struggling with old-style figures with Google Font

Describe the solution you'd like
A clear and concise description of what you want to happen.

Include an alternative option to import the full-featured (i.e. original) font instead of their trimmed counterparts. The original fonts are available at https://github.com/google/fonts in the directory format of license/font/files. If font size / package size is a concern, these original fonts can also be packed into a different package separate from the trimmed ones.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Those original fonts can also be collected manually from their respective foundries, although a huge amount of manpower might be needed.

Additional context
Add any other context or screenshots about the feature request here.

Some type foundries and cloud hosting services (Adobe Fonts) etc also offer a wider range of OpenType features to choose from (or sometimes even the original files) than Google Fonts.

[blueset]

Further on the data source, all font families in the repo mentioned above are accompanied with a METADATA.pb file, which contains a comprehensive information about the typeface, including filenames, family names, weights, styles, etc.

Specification of the syntax of METADATA.pb is available here: https://github.com/googlefonts/gf-docs/tree/master/METADATA

[ayuhito]

@blueset, I love where the idea is coming from, however, I'm somewhat unsure whether the relative demand is worth the drawbacks of such a thing.

I understand Google's stance on this considering the vast majority of users don't need such niche features and thus file sizes can be cut down for the benefit of everyone.

The package size is definitely a concern, considering the latest 3.0.0 release of Fontsource (#37 - publishing to NPM later today) has already made fonts such as Noto Sans JP as large as 100MB. On the other hand, I'm not too keen on publishing an additional 998 packages on NPM to support this.

Don't you think that maybe for the smaller group of creators who wish to utilise such niche features, it may just be best for them to directly download the full-featured fonts themselves from the source? In the end, Fontsource simply makes it more convenient to self-host fonts for your average developer and it is fairly simple to self-host manually if you chose to do so.

[blueset]

Thanks for the clarification.

As this request does not seem fit the objectives of fontsource, I would try some alternative solutions on this.

[BobPritchett]

Access to the full-featured fonts is one of the primary motivators for self-hosting. This would be really helpful.

[ayuhito]

Access to the full-featured fonts is one of the primary motivators for self-hosting. This would be really helpful.

To clarify, the biggest blocker for this is actually maintenance. There are 1500+ fonts that Google Fonts provides with the support of multiple full-time contributors. Fontsource can programmatically mirror Google, but manually taking on the burden of sourcing full-featured fonts would just be highly infeasible.

---

Despite that, I think this is doable to some degree programmatically. I've been working a lot on a new API to act as a CDN and handle all download logic and it's given me a lot more confidence to theoretically do this. We would at least have the infrastructure to support this.

• Full-featured TTFs can be automatically sourced from the Google Fonts repository.
• We'll need to first have the ability to analyse these fonts (which I do want to bring to the website like Wakamai Fondue) using lib-font so we can determine all the relevant features. We would have to work on a public API first with all this metadata before bringing it to the website.
• We'll need to be able to transform these fonts and have the functionality to strip individual features from fonts to help minimise bundle sizes.

I've been inspired a lot by Wakamai Fondue and want to bring many of its features to the Fontsource website, so I'm already onboard to getting the APIs done for the extra font metadata and it's been one of my long-term goals.

Font transformations on the other hand are a lot more tricky because it requires us to essentially implement the whole Google Fonts build pipeline so we can apply things like subsetting, compression and feature selection to our sourced TTFs. While we can rely on the open-sourced libraries from Google, cobbling them together is still a lot of work and would need a lot of time invested into this. Something I personally won't have the time to do, but would be open to any outside contributor to take on.

I'll reopen this issue since I think things are a lot more achievable now than when the original issue was posted.

[BobPritchett]

Thanks for re-opening this. I think just offering the full featured fonts would be useful; I don’t think there’s a need to strip specific feature and build custom versions of each font. Google already offers stripped down versions. If you care enough to want the missing features, you likely want them all. (If you care about old style numerals, you’ll like real small caps.) And many of these are small — 10 alternate digit glyphs, a few ligatures, alternate style characters, etc.

I think there’d be a lot of value just offering the full versions as an alternative to Google’s stripped down versions.

[ayuhito]

I think just offering the full featured fonts would be useful; I don’t think there’s a need to strip specific feature and build custom versions of each font. Google already offers stripped down versions. If you care enough to want the missing features, you likely want them all. (If you care about old style numerals, you’ll like real small caps.) And many of these are small — 10 alternate digit glyphs, a few ligatures, alternate style characters, etc.

That is reasonable. It should be a lot simpler to implement compression and subsetting alone which I think is minimally required for webfonts. Ideally, those implementations should be in WASM format to leverage our CF Workers API.

[ayuhito]

Notes for myself when I do end up taking this on:

• Analyse the tables using ttf-parser. We can then build on it to make something similar to Wakamai Fondue Engine.
• Create a subsetter that hooks into hb-subset (wasm build) for subsetting features and languages. This is essentially a simplified port of pyftsubset without any external dependencies.
• Create a compression library that supports TTF/OTF --> WOFF and WOFF2. There aren't many good WASM-friendly solutions at the moment, but it is relatively simple to implement.
• Rewrite CLI into Rust to hook into these new libraries.

Rust will likely be used as WASM compilation is a goal for all of the above. Ideally, I would like to run all of them on platforms like Cloudflare Workers for our API service.

---

Alternatives considered:

• allsorts - Does most of what we want to do already. Doesn't support variable fonts or the new COLR fonts.
• fonttools - Google uses this to currently build and subset their fonts. However, I want something much more simpler that can also be compiled into WASM. I don't want to have Python as a dependency, however, if the Rust-based subsetter proves to be too difficult to achieve, it may make sense to fallback to this.

[sandstrom]

Perhaps this is not considered related, if so feel free to disregard.

For some fonts, there is no 'whole font' file available, only the subset versions (latin-ext, cyrillic, etc). One example of such a font is "PT Sans".

For us, it would have been great if the "full font" was available under files/pt-sans-full-700-normal.woff2 or similar.

[jschroeter]

We also noticed this, e.g. the infinite symbol (∞) seems not to be part of the Roboto font files. E.g. paste the ∞ character here: https://fontsource.org/fonts/roboto

In @fontsource/roboto v4.5 there was a file @fontsource/roboto/files/roboto-all-300-normal.woff (unfortunately only woff, no woff2) which included it, but in v5 this file doesn't exist anymore. But not sure if it's worth the effort to do anything about it.