Tuesday, July 7, 2009

Why Safari Ruins the Text in Some SVG

I recently had the opportunity to write a fun bit of software: an automatic organization chart generator that generates the chart using Scalable Vector Graphics (SVG).

Little did I know that, when I sent an example of the software's output to my boss, declaring it to be working, and rather nicely I thought, what he saw when he viewed it in Safari was a hideous mess – unrecognizably bad compared to how it looked in Safari on both of the Macs I use. For one thing, the text was incredibly ugly. Seemingly bit mapped. For another, the portions of the text that were supposed to be bold were rendered plain (and, again, incredibly ugly). To top it all off, the conformance of the text to the stated metrics was terrible. Had I known that my boss would see something so awful, I wouldn't have sent it.

It took some back and forth, but I finally figured out why the SVG looks so bad on most other people's Macs. It's a setting in the "Appearance" pane of "System Preferences"; the one at the bottom labelled "Turn off text smoothing for font sizes __ and smaller." I believe the default value is 12, though I changed the setting so long ago, I don't remember for sure. In any case, being a big believer in anti-aliased type, I always set that value to the smallest one possible, which is currently 4. In my org. charts, I was using a font size of 8 pixels. While I'm not sure how we're mapping pixels to points these days, the key was that the font size in the SVG fell beneath the system's "Turn off text smoothing" threshold. So, "unsmoothed" text was drawn, and, judging by how badly it scaled and how ghastly it looked, I think it actually reverted to a bit map.

Interestingly, Firefox ignores that setting and uses "smooth" fonts anyway. Also, Firefox, at least as of version 3.0.11 and Safari 4.0.1, draws the text much nicer (for lack of a more specific term) than Safari – even after you get Safari using "smooth" fonts. Usually I find that Safari's SVG support is better than Firefox's, but not in this case. Well done, Firefox developers.

An example organization chart is included below. It describes the structure of the U.T. Austin Computation Center in February, 1988.

A lot has changed since then. One change is that U.T. Austin no longer has a Computation Center, and is rapidly running out of people who remember when it did have one, which is a shame. Also, only a handful of the people in that chart still work for the University at all.


  1. Great find! I've seen this issue as well but hadn't realized what was causing it.

    BTW, are you using TEXT or TSPAN elements? You should plug this into the SVG Web toolkit and see if it renders correctly on IE (http://code.google.com/p/svgweb). We don't yet support TSPAN elements though which is why I was asking.

    Brad Neuberg

  2. Brad,

    I use tspan elements within text elements for most of the text. As far as I know, that's the appropriate way to do things like laying-out the multiple lines of a paragraph. Of course, my org. charts don't contain paragraphs of text, buy I viewed the problem of laying-out the multiple lines in each box as an analagous problem, and therefore used the same solution.

    If there's a good reason why that's a bad idea, please set me straight.


    P.S. The org. chart embedded in my posting is the same SVG produced by my program, so if you'd like to see exactly what markup I did, and didn't use, you can open that graphic in another frame
    or window and view its source.

  3. TSPAN is the correct element to use. I was just wondering to see if things would be compatible yet with the SVG Web JavaScript toolkit for IE. We're still working on TSPAN.