Consistent, smooth font display

OK, as an offshoot to this discussion (which was interesting until it devolved into a rendering/validation/my site is better than your site shouting match), I ran into an issue which is sort of related to the discussions on accessability and font sizes that went on in there.

I found an issue lately which was related to font display. I had my base font (declared on body) as either 100% or 1em - I don’t remember which (either way it was to use the system baseline font size). I noticed on my machine, the site looked fine, but on our testers machine, the font display looked, well to be honest horrible. I was able to track it down to his machine base font being different than mine, which threw off the relative sizing calculations. I had always assumed the browsers were able to go to the closest font size, but that wasn’t happening here - and I’m not talking a webfont or anything like that, just a standard verdana or arial.

What I ended up doing (which I hated but was under a time crunch for delivery) was to set a px base size, then set the relative sizes so they resized properly (1.2em became 1.13xxxxxem).

So I guess my question is - how do you set a fluid (% or em based) font size which will allow for clean font rendering at the various sizes without the display going ugly?

guess I’ll call out those I’d like to hear from so I can be sure they at least see it…@Paul_O_B, @deathshadow60, @Stomme_poes

Do you mean that the layout screwed up or the actual text? Theoretically (as I’m sure you know), it shouldn’t have affected the text at all. If you were using an elastic layout, then I think you need to (if you didn’t) set a max-width and min-width.


You mean, the font stack had wildly-different x-heighted fonts all together, like verdana, arial, sans-serif;? and then the Windows machine showed Verdana while the Mac showed Arial and the Linux machine defaulted to probably Free Sans, all different sizes?

I use a web site to eyeball x-heights, unfortunately they did an update recently and now it’s much harder to see the fonts alongside themselves,

Don’t mix x-heights in your font stack. I keep big fonts with big fonts, small fonts with small fonts, and medium/defaults where font doesn’t matter.
This means “calibri, georgia, serif” is a no-no.

Beyond that, as TehYoyo said, if a machine uses a larger font, things should just scale up. I got problems when I first started using em’s and did the mistake of a “verdana, arial” font stack, but this was because the containers were still px-based while the fonts were em’s.

[FONT=Verdana]There are some fonts that look fine at some sizes but horrible at a lot of intermediate sizes, particularly if there is no font-smoothing turned on (do you have it active on your browser? If so, it can hide a multitude of sins) – Arial, Tahoma and Times New Roman are three that spring to mind, but generally I’m happy with Verdana, Georgia, Trebuchet and Calibri at any size – I don’t think I’ve yet seen a size on those that looks messy. The trick then is to choose fonts that scale well and eschew fonts that scale badly.

Zoom this page in and out and hopefully you’ll see some of those fonts go squiffy at certain sizes and others looking fine and funky at whatever size.[/FONT]

Hi Dave,

I guess we’d need to see a screenshot of the bad looking page in question to have a guess what might be wrong. How much difference was there? If its only the odd pixel then that’s about normal.

If you’ve set the font in ems/% (same thing) then no matter what size the user has their base size set at then the font size will maintain the relationship that you set (within the odd pixel due to rounding errors). 50% of 16px is 8px and 50% of 24px is 12px so the percentage difference is the same no matter what the base is. However some browsers do round up and down at different points so you may get a 1px difference and browsers like IE9 have some weird sub pixel algorithms going on also.

Of course the user can choose to ignore fonts and font-sizes and use their own if they want anyway so there never is a guarantee (as you know).


Are you sure? :rofl:[/ot]

I don’t know what you’re talking about … :shifty:


Ooh - you cheat. :eek2:[/ot]

One thing you shouldn’t forget:

The font stack will normally contain fonts for different platforms. Those different font faces will also have different ideas about your relative size, depending on the platform.

So it’s more than just about the fact that different fonts look good at certain sizes, and looking ugly for the rest, as I first stated in that “discussion” (which ended up well, once trolls gave up), it’s about which font looks good on what platform at what sizes. That’s typography.

Off Topic:

I’ve also contemplated the problem of not being able to choose the font size based on the platform, at one point. Or based on the font face in the stack being currently in use.

To reiterate my opinion from that “discussion”:

You should be able to use fixed size for baseline, and relative also. You are able to change the font baseline, fixed or relative, in your media queries. It’s one thing most seem to overlook, media queries are not just for layout, they are for typography too.

No one will be able to give you a definitive answer, you just have to do extensive testings of your own, using different machines, different devices, different platforms, based on the font stack of your choosing.

The possibility of a bad render becomes smaller the more test you do. Media queries are better the more test you do.

At least, that’s what I did. I tested it on different machines with different flavors of Win, with different flavors of *nix (pretty easy to do that, with Live USB *nix OSs), and on different mobile devices: smartphones, tablets, Android or iOS.


[…]as I first stated in that “discussion” (which ended up well, once trolls gave up)

To me, at least one didn’t. (although not a troll in the truest sense of the word - but he’s not using it in that sense, anyway)[/ot]

Could it just be a freak mistake, Dave?


Unfortunately, I’d have to go back and recreate the page since I had to work around it at the time - if I have time over the weekend, I’ll see if I can create a generic version of the situation (it was for a client).

The best way I can explain the problem I had was they essentially wanted an odd 13px base font size, and a small relative change for their other sizes (12px, 14px, 16px). If I used a number that didn’t exactly render to an even pixel size, the fonts were not clean - very jagged and rough.

I ended up setting the base to 13px and using specific em sizes (0.923, 1.077, 1.231) instead of (0.9, 1.1, 1.2). I’m just wondering if there was a better approach I could have taken…


(Notice Chrome assumes Tahoma to be generic serif, while Firefox decides to ignore the font bbcode tag entirely… because I don’t have Tahoma. Which btw is a tiny-*ss sissy font and should be beaten with a stick.)

I have no idea if I have “font-smoothing”, it’s whatever Linux’ desktop environment sets I think. So this may be a Windows-specific issue? Macs have that goofy font-fattening thing going on… like feeding fonts a delicious diet of tasty, tasty chocolate.

I think that’s about the best you can do. No guarantees at all on off-brand fonts, including the spiffy new choices on Google Fonts and FontSquirrel.

Edit: Poes, regarding your last post, maybe it’s just me, but my biggest problem with Chrome is its font rendering. Blech.

AFAIK - font smoothing is done on the system level not the browser.

@Dave - what fonts did you choose? I think that is the key. Some fonts can be scalled to any size, and some just get pixely after getting too big/small. I used to be able talk a bit about this, but nothing came to me. However the following article may shed some light:

  1. The term is “dynamic” fonts – when you said fluid I thought you were talking layout, not font sizes.

  2. We’d have to see it to say what went wrong, though I have my suspicions.

  3. As a rule of thumb and as some have already mentioned, the problem was most likely from different default sizes in your font stack. Certain fonts start out rendering larger at the same font-size, so if you used Verdana – on anything that doesn’t have verdana available you can typically expect it to be

  4. If you used ‘web fonts’ – most of the time it’s a “Well there’s your problem”. The majority of fonts simply are not made for use on screen in the first place! Serif fonts in particular simply can’t handle smaller sizes because there aren’t enough pixels for their serifs to render. Script fonts are often worse… Serifs improved legibility when there’s enough dots to render them; they turn a page into useless crap when there aren’t.

On the whole it’s why I wouldn’t use web fonts on anything more than heading elements where you’re going to have them bigger in the first place… and even then I wouldn’t actually use them on my own sites. As a rule of thumb they are just as big an accessibility train wreck as flash navigation… I’m leery of the entire concept because so many fonts that are out there just flat out shouldn’t be used on any text you actually expect people to read.

As I’ve said several places, you could do far, far, FAR worse, than:

font:normal 85%/150% arial,helvetica,sans-serif;

The WORST you can complain about there is not being able to tell a lower case “l” from a upper case “I”. BIG HONKING DEAL! Effects one and a half columns in a 1600 page copy of Mirriam-Websters.

Also why it helps to be aware of why you should be using %/em in the first place, so that it DOES automatically enlarge and contract:

… and to realize just how randomly different fonts can be at the same alleged “font-size”

You go and choose some goofy non-standard font, you need to compare it at the same size to your fallbacks and the master fallback of whatever serif / sans-serif ends up on various platforms so you at least have some clue – this is why I do NOT consider Verdana (for example) to be viable for web deployment – it is simply way too much larger than arial,helvetica,deja-vu sans, etc, etc… on the serif side, Georgia is way too big compared to times, franklin gothic, etc, so it too is not ‘viable’ should the end user not have that font available.

Of course SOMEONE is going to chime in “what about branding” – you brand with logos, colors, MAYBE headings… you start trying to use branding on flow text just for a certain font, you’re a {expletive omitted} moron who fails to grasp the point of the Internet or the limitations of the medium!

The WORST you can complain about there is not being able to tell a lower case “l” from a upper case “I”.

This is in fact why people use the incorrect name for the famous “Leek spin” song.

Sorry, there’s no excuse for two completely different letters to look the same here. They should always be obviously different.

Similar, I was reading Wikipedia pages about Romanian leaders. So many I thought their names had L’s but it was I’s.

Sorry, but if the second word is uppercase and it’s a title of a song, they should BOTH be upper case… Or is that another of those language differences? In fact, isn’t Ievan the proper name “Eva”? Proper names are supposed to start with a cap too Mallory… or does Dutch not do that? It’s a song title, it starts with a proper name, why isn’t that upper case?!?

So… it’s an issue because people are stupid? They don’t realize it’s upper case since it’s a title and a name?!?

Sorry, as problems with a font goes, that’s a REALLY lame one.

Dave, if you could provide some more specific information about which system, which browser, which font and which sizes, people could (possibly) say some more about it. Or provide some screenshots. But in general it’s difficult with font rendering. There are so many variables. So as mentioned before it’s mostly a matter of testing. In general, almost anything on (older versions of) Windows looks very bad (compared to mac), but it also depends a lot on what fonts and what sizes. Even which color, etc.

I wouldn’t fall back to using px just because in one specific situation it looks bad.

I disagree. Sure it’s easy to figure out when you’re trying to, but it’s still a readability issue. Especially when you’re reading a paragraph you could either scroll across a word with same characters for different letters without noticing, possibly picking up the wrong word, or worse it could force you to stop reading, wasting your time questioning what the word says. A font should deliver its contents clearly, without hassle.

This is the age old issue of thinking ‘oh people can’t use it they must be stupid’. When the reality is if people can’t use it than it is poorly designed. After all what are we designing things for if not people? And if people cant use it than surely it is not properly designed for them.

Is it possible to feed windows fonts this tasty tasty chocolate? I’m not sure if this is similar to Dave’s problem but I’ve been testing my fonts on different platforms and the fonts are perfect on mac and windows seems to have an awful and crippling case of aliasing.

To go into more detail it appears that the latest versions of IE and FF have some pretty good anti-aliasing going on. Chrome and Opera don’t. Well actually Chrome seems to apply anti-aliasing once you zoom far enough and in all circumstances Opera seems to be having some sort of jaggy bonanza.

I disagree. The two don’t mutually exclude. Why? A simple fact of font stacks. Somebody failing to grasp their mechanism, maybe, will argue just for the sake of arguing.

Sites using fonts for branding all over the site will display with a certain appeal (brand) for users having the fonts at the top of the font stack.

For the rest, it’ll nicely fall back to fonts lower down the font stack, as far down as one of the two generic font families.



Take Microsoft.

body, select {
    font-family: Segoe UI,Tahoma,Arial,Verdana,sans-serif;

Take Apple:

body {
    font: 12px/18px "Lucida Grande","Lucida Sans Unicode",Helvetica,Arial,Verdana,sans-serif;


Of course, one doesn’t have to absolutely care for that, branding by fonts also. But arguing against this type of branding while implicitly dismissing font stacks is just not good enough. It’s pure amateur overlook.