New web font subsets - Basic Latin only subset + "everything else" subset

[chrissimpkins]

Rationale:

1. the vast majority of glyphs displayed in source code fall within the Basic Latin set
2. there are exceptions that include string literals and comments, so an increased breadth of glyph coverage is necessary in some circumstances
3. size matters for initial page loads with web fonts
4. file sizes in this project are relevant with respect to point 3 above
5. There may be creative ways to display source code semantics that involve a mixture of different fonts for the Basic Latin elements and portions of source text that include glyphs outside of this Unicode range (e.g. use of proportional width fonts for comment blocks)

We are going to produce additional web font subsets with a new set of CSS files to support serving a very slim Basic Latin only set as default with "everything else" set loaded only in cases when Hack is being used to style glyphs outside of the Basic Latin set. After discussion with @chriscoyier and review of the way that web fonts are served in the Google Fonts project, this approach appears to be feasible using a combination of CSS definitions and these defined subsets of the full font set.

Initial testing shows these Basic Latin only sets to be ~ 50% size of current subset web fonts and ~10-15% size of the full character set web fonts.

We will not eliminate any existing web font subsets. These will be produced in addition to the current subsets and full sets that we offer.

[chrissimpkins]

Must keep name.ID records 3,4,6 with the pyftsubset tool for valid subset builds

fonttools/fonttools#1170 (comment)

[anthrotype]

they are not "invalid", they simply aren't installable on a local OS. In web fonts, the name table is completely ignored by the browsers.

[chrissimpkins]

Ah, I misunderstood the conversation. I thought this was platform specific browser rendering. Who is trying to install web fonts on the desktop... Thanks Cosimo.

[anthrotype]

that a "web" font cannot be installed on a desktop OS is actually a feature ;)

[chrissimpkins]

Definitely for commercial typefaces...

[chrissimpkins]

As we make a move to pyftsubset as our web font subsetting tool (and away from fontmake as the subsetter) and possibly to pyftsubset for all web font builds, we will be introducing two new dependencies to our build tooling.

pyftsubset is released through the fontTools project as a default executable. fontTools is currently a build dependency for Hack. This does not represent a new build dependency for this project. Builds of zopfli compressed woff files with pyftsubset requires the optional Python bindings for zopfli. Zopfli compression is optional but yields smaller files which are beneficial to viewers of web fonts (decreases page load times) and desired by those who use web fonts in their HTML. Builds of woff2 files (by definition brotli compressed) with pyftsubset requires the optional Python bindings for brotli. Both are optional in the sense that they are not part of the default dependencies of the fontTools library when installing with pip.

This is a move that we intend to make in the next few months and is currently slated for our v3.004 release so that we can support multiple web font subsets as described in the OP in this thread. We can define new make targets that build with current tooling and without the new types of web font subsets if this is helpful to any downstream projects. I need your feedback if this is the case.

For those with interest in the subset files, this change will not eliminate the current subset or full set that we release. These will still be part of our web font releases. We will be adding new subset types to these builds to increase options for web font users.

cc package maintainers who build from source : @paride @spstarr

@anthrotype is the maintainer of both the brotli and zopfli Python bindings projects and the appropriate contact if you have questions about these projects. See #400 (comment) for details about/links to the projects.

[paride]

@chrissimpkins python3-brotli is already Debian packaged, while zopfli is not. I don't think packaging it will be a problem.

[chrissimpkins]

@paride thanks Paride!