TR Forums

http://techreport.com/news/27017/friday ... is-upon-us

TR rolled out a new site typeface: Source Sans Pro

I'm not a big web guy. If I remember correctly once upon a time ago the typefaces a site desired had to be available on the local machine of the browsing user. Today there are standards that allow the server to provide the fonts to the endpoint instead.

So this new Source Sans Pro should work perfectly even without out of the box support from Windows. While that might all be well and true, turns out that if you do have the fonts installed locally it is presented in a slightly different way.

Let me provide some picture examples with IE11 EPM 64bit and Chrome 64bit.

These two pictures are before the fonts were installed locally. Source Sans Pro is being rendered here.

Before:
http://unspacy.com/ryu/tr/gcbefore.png
http://unspacy.com/ryu/tr/iebefore.png

These two pictures are after the fonts were installed locally. Source Sans Pro is being rendered here.

After:
http://unspacy.com/ryu/tr/gcafter.png
http://unspacy.com/ryu/tr/ieafter.png

You can see that when the endpoint has Source Sans Pro fonts available it renders the typeface with a much thicker and fuller presentation.

I personally prefer this (I acknowledge it is an aesthetic choice), but I find it strange the behavior happens at all. I've managed to duplicate it across three different systems. You can test it out on your own systems by following these directions.

For those who want to install the Source Sans Pro fonts locally.

Go here: http://sourceforge.net/projects/sourcesans.adobe/files/

Download: SourceSansPro_FontsOnly-2.010roman-1.065-italic.zip

Extract: SourceSansPro_FontsOnly-2.010roman-1.065-italic.zip

Double click: source-sans-pro-2.010R-ro-1.065R-it
Double click: OTF
ctrl+a
right click one of the highlighted files
Click Install and agree to UAC prompt

Close browser, open browser, and reload TR.

Yeah, I have bad news for you.

It would appear that DirectWrite, for some reason or another, doesn't do subpixel rendering for you and the browser instead falls back on grayscale antialiasing. Very strange. It's actually an error, but if it pleases you, then go for it.

Wow, this is weird.
I've found the culprit. Cyril's questionable use of "62.5%" for the body font size is breaking local font rendering in every browser I've tried. (Firefox, Opera, Chrome.)

Overriding the CSS to use a round 60% or 0.6em both seemed to solve the issue: local fonts no longer appeared 1 pixel taller or have errors in them.

Oh, Cyril.

Even accounting for the size thing, subpixel rendering appears absent for the local font but not the online font. Grr. I'm going to have to uninstall the font now, because you made TR ugly for me.

Edit: It's only ugly in Opera 12, which does not feature DirectWrite support and is absolutely ugly using regular rendering on that particular local font.
My other, newer browsers seem to work right after I manually edit the CSS.

Edit 2: I've narrowed down the font face issue to the most ridiculous peculiarity I've ever seen: when using 62.5% as the font size, the local font will literally appear taller than the online fetched version. Use anything else (even other fractions) and the local font will have the proper height again. Bizarre.
Still no explanation for why it's thicker though. (It almost has as much apparent weight as the 600-bold version.)

Meadows wrote:

Wow, this is weird.
I've found the culprit. Cyril's questionable use of "62.5%" for the body font size is breaking local font rendering in every browser I've tried. (Firefox, Opera, Chrome.)

Overriding the CSS to use a round 60% or 0.6em both seemed to solve the issue: local fonts no longer appeared 1 pixel taller or have errors in them.

Oh, Cyril.

Dude, setting the body font to 62.5% is a common technique to get a default body font size of 10px (down from the standard 16px), which then lets you set relative font sizes in em without having to do too much math (e.g. 1.3em = 13px).

Changing the body font to 60% will just make all text slightly smaller. So text that should be 13px will become 12.48px. It might look better to you, but it doesn't really fix anything.

Cyril wrote:

Changing the body font to 60% will just make all text slightly smaller. So text that should be 13px will become 12.48px. It might look better to you, but it doesn't really fix anything.

That's what you think. I can make screenshots to prove that the local font renders slightly taller around 62-63%, but never at any other size.

The way I checked was quickly alternating back and forth between 400-weight and 600-weight, because only 400 is the local one, 600 is still fetched from Google fonts.

Maybe the local font itself has a "bug"? Is that even possible?

Either way, I deleted the local font and will default to your CSS, because tinkering just made everything ugly. I didn't mean this all to become so long-winded, but sometimes when I see something peculiar I attempt to investigate.

Ah, found the answer. The cause is the use of OTF.

http://www.smashingmagazine.com/2012/04 ... rendering/

Looks like OTF are Postscript based fonts and DirectWrite addresses them in the following way.

DirectWrite not only gives smoother outlines, it also applies subpixel rendering to PostScript fonts. Unlike TrueType rendering, however, it allows for more gray pixels in order to reflect stroke weights more realistically. That makes it well-balanced, and similar to Mac OS rendering.

Meanwhile TTF based fonts are addressed by DirectWrite in the following way.

In DirectWrite (the successor of GDI), Microsoft added vertical smoothing to ClearType. This new rendering mode (so far used by Internet Explorer 9), gives us smooth and precise rendering in all sizes. The main difference to Mac OS that remains is that it still tries to align contours to full pixel heights, which leads to even better rendering given that the font is well-hinted. What’s more, DirectWrite allows for subpixel positioning, which gives the characters exactly the spacing that they have been designed with, improving the overall rhythm and evenness of the texture.

I've tested and confirmed. Deleting the local OTF and installing the local TTF results in a presentation identical to having the server provide the font. Installing the local OTF will override the server delivered TTF font (presumed) and DirectWrite the OTF a larger weight.

I'm just going to use my browser to override all text to be Comic Sans. This way it always looks like poop and I can't blame any text format or DirectWrite. Though doing this may make me want to kill myself.

Ohh, that sounds like fun. I for one think Comic Sans is glorious and should be used everywhere, especially on the internet. Also the new font seem to be just a little bit blurry on my display for some reason.

Is this the reason the site looks poor in IE11, seems ok in Firefox for me though?

captaintrav wrote:

Is this the reason the site looks poor in IE11, seems ok in Firefox for me though?

Not sure what you're talking about?

(Waterfox 32, IE 11, Chrome 37something; the weights are a little different but I wouldn't say any of them are "poor")

Silver theme heretic!

It must be something with DirectWrite and/or ClearType on my work machine, it does look terrible in IE11, but we only recently updated from IE8. The fonts look really nice on high dpi displays like on my 2013 Nexus 7. In UberGerbil's picture Chrome looks abysmal, which is weird since it can't be a cleartype problem when it's an image of the display. It almost looks to me like a poorly adjusted VGA-connected LCD, but I have two DVI displays connected to a Quattro card, so that's not it. Uber's screenshots look fine on my tablet. I'll blame NVidia's drivers, since everything else on this machine looks like you'd expect. Also have noticed some other bizarre display issues since installing IE11. Using other browsers is against corporate policy.

Yeah, Chrome in Ubergerbil's post looks kind of rough. The top of the lower-case "e" for example. Very thin, too light of a weight for the DPI settings on his display. I don't use Chrome day-to-day, but I just fired it up in a Win7 VM and it has the same extra-light weight making certain letters look weird.

I, for one, welcome our new font overlords! (Though not perfect, IMO the new fonts look better in Chrome/Chromium on Linux than whatever was being used before.)

Hmmm, my work machine doesn't have this font installed. I'm not sure how exactly font rendering works when the desired one isn't available, but whatever shows up now seems to have a blurry, glossy sheen to it. Basically, it makes reading on the site very uncomfortable. I'll have to see what it looks like at home, but I extremely dislike whatever font is rendering now.

dashbarron wrote:

Hmmm, my work machine doesn't have this font installed. I'm not sure how exactly font rendering works when the desired one isn't available, but whatever shows up now seems to have a blurry, glossy sheen to it. Basically, it makes reading on the site very uncomfortable. I'll have to see what it looks like at home, but I extremely dislike whatever font is rendering now.

The whole point of "The Fontening" is that you don't need to have the font installed any more; the site downloads the fonts it needs into your web browser on the fly. This does require that the browser support downloadable fonts, though. What browser does your work machine run? If you're running IE pre-9.0 that could be the issue. (This page lists what version of each of the popular browsers added downloadable font support.)

Or maybe you just don't like the new font...

After looking at this, I think it's just I don't like the font.

Maybe I need some of your special brew.

Sorry for the necro, but I've been noticing some font size/spacing irregularities on the front page with Firefox 39. They're not necessarily bad, I just keep thinking I've accidentally increased the zoom level. I'll see how it looks with Chrome when I get home.