Introducing Inter UI & Fira typefaces

[rusackas]

CATEGORY

Choose one

• Bug Fix
• Enhancement (new features, refinement)
• Refactor
• Add tests
• Build / Development Environment
• Documentation

SUMMARY

This PR updates the main UI typeface of Superset to Inter UI, and code fonts (e.g. SQL editor) to Fira Code. Both fonts are under the SIL Open Font License, and license information has been added to LICENSE.txt to reflect this, as per ASF guidelines.

This work is a small step toward SIP-34 (#8976).

Note that the Roboto font (not actually used visibly anywhere) was also removed, in both its binaries and LICENSE.txt references.

Also note that Fira Code is an extension of Fira Mono. I included that typeface temporarily for when ligatures are turned off, but decided it's better to just use OpenType features to just turn ligatures on/off, rather than loading a different font entirely.

Fira Code is a font that contains handy ligatures that many people love. However, not everyone might love them, so there's a LESS variable called @use-ligatures to turn them on or off (they're off by default). If/when we move to a CSS-in-JS approach (See SIP-37, issue #9123), we can make this selection more dynamic, switchable via user preference or deployment config.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

SQL Lab BEFORE (Helvetica + Menlo)

SQL Lab AFTER (Inter UI + Fira Code, ligatures OFF)

SQL Lab AFTER (Inter UI + Fira Code, ligatures ON)

Explore BEFORE (Helvetica)

Explore AFTER (Inter UI - note that viz components are still using other fonts - in this case, Arial)

I've clicked around to other areas, and things are looking OK. Holler if there are any concerns, and I can add additional screenshots.

TEST PLAN

ADDITIONAL INFORMATION

• Has associated issue:
• Changes UI
• Requires DB Migration.
• Confirm DB Migration upgrade and downgrade tested.
• Introduces new feature or API
• Removes existing feature or API

REVIEWERS

@etr2460 @mistercrunch

[willbarrett]

Yaaaaaayyyyy ligature support!

[etr2460]

This seems reasonable, but I am concerned about how much extra fonts we'll be sending down the wire on initial page load. Ideally these should be cached, but it's possible people haven't set up cache headers properly so they'd eat an extra megabyte or two on every page load.

I'd recommend a couple changes:

• Only include a 3 font weights for each font (thin, normal, bold)
• Update/improve documentation in the config file about how to properly configure static resource caching

[rusackas]

@etr2460 I shared this concern as I was implementing this... in fact I went down a rabbit hole of writing LESS conditional mixins to only load the @font-faces that were actually in use. In the end though, it turns out every browser since IE8 is smart enough to NOT load @font-face resources that aren't actually in use. So, I added all the font binaries to the repo in case they come in handy, but in actuality, only three of the weights, and one of the formats, might ever actually get loaded. Usually only a couple of those are actually in use by a given view, and they do appear to be cached from what I saw. So despite all the font binaries visible in this PR, the burden on load is actually pretty light.

[etr2460]

ooh, that's good to know. i think this looks fine from my perspective then. Let's make sure we have an action item going forward to standardize on font weights within our less variables file then so that we don't get a weird mix of different types of font stylings (i still think there might be value in limiting the files committed in the repo so no one accidentally uses uncommon font weights, but it's not too big of a deal)

[williaster]

Is there a plan for updating fonts on the charts? like mass migrating to set font: inherit or something?

[rusackas]

Is there a plan for updating fonts on the charts? like mass migrating to set font: inherit or something?

@williaster My initial thought, for the shorter term, is to just add the new fonts by name to the front of the font stack. Using "inherit" might also work, but could also have ramifications in other (embeded) use cases. By explicitly naming the font, the charts would fall back to their existing font stack when the new font is not available for whatever reason.

Longer term, I think the plugins should follow the CSS-in-JS patterns we use for the main repo, and ultimately pull from the same theme settings (presumably pulled in from Superset-UI). SIP-37 is in need of votes to make that a possibility.

[mistercrunch]

Are we sure SIL is apache-comptible? Listed here as "weak copyleft"
https://www.apache.org/legal/resolved.html#weak-copyleft-licenses