improve the font loading CSS

[Pomax]

The font loading CSS on src/styles/brackets_fonts.less currently outright loads a set of .ttf fonts, rather than first checking whether the fonts are available on the local system, and if not, trying to load the WOFF versions, with otf fallback (and an eot shortcut in case IE is involved, so it doesn't download everything even after finding something it supports). Loading the ttf versions for fonts that are inherently CFF/OpenType is kind of weird, especially since this is an Adobe project =)

Have a look at the fontsquirrel/bulletproof CSS (https://www.fontspring.com/blog/the-new-bulletproof-font-face-syntax etc.) for a sensible load ordering, and make sure to also add in a local url as first check in case people actually already have Source Pro locally installed?

[humphd]

This would be good to fix for the in-browser case, as a large portion of the overall download size ends up being these .ttf files.

[redmunds]

This sounds like the right way to go. Pull requests are gladly accepted. :)

[peterflynn]

How would we check whether or not a font is available locally? That might be more trouble than it's worth, especially since these particular fonts seem unlikely to be installed locally.

I know we had some rendering fidelity issues with non-TTF webfonts in the past. A lot has changed since then, but we should still be cautious -- perhaps someone could post PNGs for comparison, from both Mac & Win running on the current brackets-shell?

[peterflynn]

Also, we may want to tackle this in combination with PR #8985 so we don't incur the cost of scrubbing the UI for font problems twice.

[Pomax]

you don't explicitly "check" so much as simply request the font based on its OpenType name, and if that fails the next source gets evaluated. For Source Sans Pro Regular, for instance:

@font-face {
  font-family: SourceSansPro;
  src: local('Source Sans Pro Regular'),
       url('fonts/SourceSansPro/SourceSansPro-Regular.eot?iefix') format('embedded-opentype'),
       url('fonts/SourceSansPro/SourceSansPro-Regular.woff') format('woff'),
       url('fonts/SourceSansPro/SourceSansPro-Regular.otf') format('opentype'),
       url('fonts/SourceSansPro/SourceSansPro-Regular.ttf') format('truetype');
  font-weight: normal;
  font-style: normal;
}

Whether it's unlikely or not that people have Source Sans installed themselves (it's freely available, so they might), the check effectively costs nothing if the font is not locally installed, but shortcuts a significant over-the-wire load if it happens to be available.

There's also probably no point in loading all three of woff, otf, and ttf, given the near universal support for woff (http://caniuse.com/#feat=woff), and the fact that the only browsers that don't support .woff don't support .ttf either (http://caniuse.com/#feat=ttf). The exception here is Android <4.4, but that happens to be also the versions of Android with extremely buggy webfont code, so that even .ttf files that do load end up not being reliably applied.

[le717]

I would go for making the font loading more conditional. Brackets does feel slow loading at times, and if this will help development of the in-browser version and help speed up loading (although since it's loading it over file:/// already, this probably won't change anything), I'm all for it, and will gladly update #8985 with these changes.

For the record, I have Source Sans Pro and Code installed on my computer, so people do install the font on their computer, but not all that often. ;)

[Pomax]

we're using brackets in the browser atm (as a codemirror replacement - it is fantastic O_O), and you really feel the hit on http:// rather than file:///

[petetnt]

Nothing that significant but Source Sans Pro is (I think at least) bundled with Adobe Creative Cloud software so there's some millions (not sure what the current amount of subscriptions is, in the 2014 it was "over 1M") of people with the font installed.

[peterflynn]

@petetnt It's not -- you'd have to manually browse to the font on TypeKit and choose to install it. So I think the percent of Brackets users with locally-installed copies is probably extremely low. Seems like it wouldn't hurt to add the local() bit into the CSS, but I wouldn't expect any real performance improvement.

@Pomax For that reason, for in-browser forks I'd suggest changing the default font to something that's not a webfont. E.g. "Menlo Regular", Consolas, Inconsolata, "Vera Sans", "Lucida Console", Courier, fixed.

[petetnt]

@peterflynn I agree that all of your points, but some Adobe program installs Source Sans for sure. I only have anecdotal evidence but

• I am CC subscription: My PC has Source Code Pro / Source Sans Pro installed locally and I haven't installed any fonts from TypeKit ever
• My colleague is has only CS5.5 installed and he doesn't have those fonts installed
• My another colleague has CC programs installed, but certainly hasn't used TypeKit (or most likely any other CC program anyway) at any point

But yeah, like I said it's insignificant it's a moot point anyway 🎱 Just something that came into my mind when I checked if I had the font installed locally and I was surprised it was!

[peterflynn]

Odd -- I have CC installed on 3 computers; only one of them has Source Sans Pro (because I installed it manually), and none have Source Code Pro. Maybe there's one specific app (e.g. Edge Reflow?) that installs it even though the overall CC package doesn't?

[petetnt]

Actually you are correct, culprit is one of the Edge apps!

[Pomax]

I can confirm that while I never intentionally installed Source Sans Pro myself, as an Adobe product user, it turns out to already be installed on my system (Not a CC user though, I use Photoshop CS6 and Lightroom 5... although for PS I certainly picked the "install all the fonts that you have" option).

[le717]

@Pomax @humphd Pull the changes at #8985 at see if the additional font-face rules help any.

[humphd]

@le717 Interestingly that patch makes things worse, in terms of pure download size (though I think what you've done looks right in general). Before I was seeing 5 .ttf font files totaling 311K in size (gzipped); after I see 4 .woff and 1 .ttf font files totaling 478K (gzipped). However, I was able to confirm that once I installed the fonts to my system, the local(..) bit meant that no fonts were downloaded at all, which is great; so overall, a win.

I think the path forward for me, in terms of the browser use case, is to fix https://github.com/humphd/brackets/issues/78.

[peterflynn]

@humphd If you're comparing master to that PR, the size will definitely go up since it's upgrading to newer versions of the fonts that include more glyphs.

I would hope though that comparing the old TTF-only version of that PR to the new version of the same PR doesn't show much of a size difference...

[marcelgerber]

Yeah, I just confirmed that the updated fonts are the reason for the increased size, not the format change.
Actually, a gzipped (gzip -9) .ttf has roughly the same size a .woff has.

[Pomax]

That would make sense, a WOFF is literally "the original font, with each table gzipped" with iirc a 32 byte rather than 16 byte per-table-record for noting original vs. compresses sizes, and the corrective offets.

[miguelsousa]

I'll mention that by using src: local(...) you'll start running into problems related to not having all users using the same version of the fonts. In the long run I think these problems will outweigh the benefit of not fetching the fonts over the wire (which is something I believe is not going to happen every time because the browser is supposed to cache the fonts).