Love the work! The typical file size for the Inter-UI (web) fonts are fairly large, around 100-170KB - Is that known/expected? I was hoping to confirm I'm using the right set given typical custom web fonts are around 20-40KB... thank you!
bhellman1
All 3 comments
I assume this is at least partly because the glyph set covers a lot of language characters that might be stripped away in more 'optimised' web fonts. If @rsms is interested I'd be happy to look at producing smaller subsets (either here or in the npm package) that reduce file size by offering narrower language support. I'm not super experienced with font editing but my first guess for how to do that would be a via a bash script that runs some font forge commands?
philipbelesky
on 3 Feb 2018
That would be greatly appreciated... @rsms ?
bhellman1
on 3 Feb 2018
Indeed the file size is simply larger than what you are used to because of the greater coverage of glyphs. Subsetting is a pretty easy process and whenever Inter UI gets onto Google Fonts, you may be able to grab subsets from them.
I propose you read the following article: https://www.bramstein.com/writing/web-font-anti-patterns-subsetting.html
In practice, the file size makes little difference in speed, especially on high-end mobile devices where the TCP/IP handshake and TLS negotiation of a new connection often takes several orders of magnitude longer than transfering packets for a file itself. (I worked on this kind of stuff at the Facebook mobile infrastructure team a few years ago.)
If you still insist in subsetting, you can use Google's sfntly (https://github.com/googlei18n/sfntly; macOS Homebrew repo here https://github.com/bramstein/homebrew-webfonttools)
@philipbelesky I'd stronly recommend _against_ including subsets in the NPM package. It's both easy to make a mistake (and not knowing it, like dropping a component used by a glyph left in, causing certain software to choke) and the world speaks many languages — e.g. providing a ASCII-only subset would not be usable for any display of user data (e.g. on a website) and in my experience most people using NPM never look at the details, so it's very possible that users of such subsets won't actually understand the compromises they are making.
rsms
on 18 Feb 2018
Related issues
y6nH
·
4Comments
dom1n1k
·
3Comments
reinhart1010
·
8Comments
cssobral2013
·
3Comments
sk1nzz
·
4Comments
Most helpful comment
Indeed the file size is simply larger than what you are used to because of the greater coverage of glyphs. Subsetting is a pretty easy process and whenever Inter UI gets onto Google Fonts, you may be able to grab subsets from them.
I propose you read the following article: https://www.bramstein.com/writing/web-font-anti-patterns-subsetting.html
In practice, the file size makes little difference in speed, especially on high-end mobile devices where the TCP/IP handshake and TLS negotiation of a new connection often takes several orders of magnitude longer than transfering packets for a file itself. (I worked on this kind of stuff at the Facebook mobile infrastructure team a few years ago.)
If you still insist in subsetting, you can use Google's
sfntly(https://github.com/googlei18n/sfntly; macOS Homebrew repo here https://github.com/bramstein/homebrew-webfonttools)@philipbelesky I'd stronly recommend _against_ including subsets in the NPM package. It's both easy to make a mistake (and not knowing it, like dropping a component used by a glyph left in, causing certain software to choke) and the world speaks many languages — e.g. providing a ASCII-only subset would not be usable for any display of user data (e.g. on a website) and in my experience most people using NPM never look at the details, so it's very possible that users of such subsets won't actually understand the compromises they are making.