Skip to content
This repository has been archived by the owner on Nov 14, 2018. It is now read-only.

Picking the font #14

Closed
espadrine opened this issue Jan 4, 2014 · 10 comments
Closed

Picking the font #14

espadrine opened this issue Jan 4, 2014 · 10 comments

Comments

@espadrine
Copy link
Member

This issue is heavily related to bug #12.

For licensing reasons, servers are usually not bundled with Verdana, the font we currently use. However, the license also forbids that we include Verdana in this project for use by the width computation system: http://www.microsoft.com/typography/fontpack/eula.htm.

That made me look at using an open font. A font that we could bundle in this project. Since such a font wouldn't be web-safe, the SVG file would have to link to it or bundle it.

As it turns out, while Blink allows SVG images to link to external fonts, Firefox does not. On the other hand, they both support fonts bundled in the SVG through data:font/ttf;base64,…, but either way, the result is a pretty big download.

Say, if we wanted to use Open Sans (the font currently used in all major badges), we'd have to include at least 284K of base64 data, which causes a download roughly 132x the size of the equivalent PNG.

Maybe there is a way to only include the font information for the characters actually used, but I haven't found it.

@espadrine
Copy link
Member Author

The approach taken right now is to require users to either have Verdana installed or to download it to the repo's root. I also use a fake commit to push a Verdana version to Heroku.

However, that does lock us in with a non-open font.

@mathiasbynens
Copy link
Contributor

ttfsubset can be used to programmatically do TTF font subsetting. I am not sure how viable this is.

However, TrueType and OpenType were superseded by WOFF, so we’d probably want to use a WOFF version if possible.

Either way it seems like a bad idea to bloat the SVG size :(

Licenses… ಠ_ಠ

@stucox
Copy link

stucox commented Jan 8, 2014

Non-designer’s answer to this issue: What does it matter, it’s only a font, just specify a few and hope it looks ok :trollface:

A minor point, but why does template.svg use font-family="Verdana,serif"? Wouldn’t sans-serif make a more suitable fallback?

@nathany
Copy link

nathany commented Jan 8, 2014

Personally I like the idea of using a web safe font.

My main concern is how reasonable it is to switch all the existing OpenSans-using badges to Verdana so READMEs don't end up with a row of very obviously mismatched badges (@olivierlacan's initial reason for starting Shields).

@stucox Any fallback will probably run into issues with text extents (and therefore badge width) not matching expectations.

@espadrine
Copy link
Member Author

For the purpose of comparison, here is the template SVG file using a subset of OpenSans. Images, which were up to 0.8kB (compare with the corresponding PNG of 2.5kB), are bloated up to 12kB.

Yet the subset only contains lowercase letters from a to z and a space.

In other words, this doesn't get rid of fallback issues (esp. wrt. width measurement, I don't know of any web-safe font with the same width as OpenSans), and it makes the file download slower.

I'll stay focused on finding the best fallback strategy. The one currently implemented is described here. I should note that while DejaVu Sans doesn't quite have the same size as Verdana, it is never bigger, and therefore never overflows the badge.

@espadrine
Copy link
Member Author

It seems that across the board, using a font width of 11px gives more readable badges. Snapshots below.

Windows

  Firefox Chrome IE
Verdana verdana-firefox-win
DejaVu Sans
Geneva

Mac

  Firefox Chrome
Verdana
DejaVu Sans
Geneva

Note: the blue defects are not present, they are merely a testament to the quality of default Mac software.

Linux

  Firefox Chrome
Verdana
DejaVu Sans
Geneva

Overall, this font size change is mostly to combat the absurd font blur present on mac systems, which I believe is something that @olivierlacan will welcome.

Another issue is that of priority of fonts, which is the fallback of which. For that purpose, I will use my quantitative appreciation of the screenshots above, weighted by the proportion of users in that case. To compute the proportion of users, I will use GitHub stats.

Note that Geneva is not part of that competition. It doesn't look as good anywhere, the event that it is installed on a non-mac system is improbable, and it really only is there because 0.5% of mac users don't have Verdana according to some old stats that probably don't apply well to GitHub viewers.

So Verdana is -1, DejaVu is 1; we will get a result between -1 and 1; if the result is closer to a font, that font wins first place.

Probability of Windows: 0.39
Probability of Mac: 0.43
Probability of Linux: 0.17

Qualitative winners:

Windows: Verdana (see blur of the "i" in "failing" in DejaVu, see distance of the dot in "i")
Mac: DejaVu (see distance of the dot in "i"…)
Linux: DejaVu (better horizontal width of individual letters)

Result = -1 * 0.39 + 1 * 0.43 + 1 * 0.17
       = 0.21

Therefore DejaVu wins first place. The fallback sequence is therefore DejaVu Sans, Verdana, Geneva, sans-serif.

If you disagree with the qualitative winners, please detail why.

@mathiasbynens
Copy link
Contributor

Woah — Nice research, @espadrine! The science checks out. 👍

Are the pages you used to take the screenshots in #14 (comment) available online somewhere? Would be useful to verify the results (not that I don’t believe you!).

espadrine added a commit that referenced this issue Jan 14, 2014
Font order change.

Part of issue #14.
@espadrine
Copy link
Member Author

@mathiasbynens Sure! I'd welcome more screenshots.

(In fact, that'd be a startup idea: a jsperf for website screenshots!)

@mathiasbynens
Copy link
Contributor

OS X, retina display, Verdana (DejaVu Sans not installed)

os-x-retina-verdana

OS X, retina display, DejaVu Sans

os-x-retina-dejavu

@espadrine
Copy link
Member Author

@mathiasbynens thanks a lot! It looks exactly the same.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants