• Safari, Chrome and Opera will render the font normally without italicizing it.
• Internet Explorer and Firefox will attempt to italicize the font, but Internet Explorer will slant the font at a 20° angle while Firefox implements a 10° slant.

Internet Explorer 6.0	Firefox 3.6	Safari 4/Chrome 5/Opera 10

This inconsistency is quite annoying from a user-experience point of view. However, there is a way of leveling the playing field by using the CSS3 transform property. And even though Internet Explorer doesn’t recognize transform, there is a workaround without using JavaScript using the Matrix Visual Filter.

The CSS

When I was a calligraphy student, I learned that the Italics script was to be written on a 10° angle. Using the CSS3 transform property, this can be achieved by using the skewX() function:

#content h1 em {
    font-family: "Graublau Web Bold", Arial, sans-serif;
    font-style: normal;

    -moz-transform:    skewX(-10deg);
    -o-transform:      skewX(-10deg);
    -webkit-transform: skewX(-10deg);
    transform:         skewX(-10deg);

    display: inline-block;

}
	

The display: inline-block is there since Safari, Chrome and Opera will not allow transformations on an inline element.

But what about Internet Explorer? I could use my cssSandpaper script, but it is really simple to do without it:

#content h1 em {
    font-family: "Graublau Web Bold", Arial, sans-serif;
    font-style: normal;

    -moz-transform:    skewX(-10deg);
    -o-transform:      skewX(-10deg);
    -webkit-transform: skewX(-10deg);
    transform:         skewX(-10deg);

    display: inline-block;

    /* IE8+: must be on one line. */
    -ms-filter: "progid:DXImageTransform.Microsoft.Matrix(M11=1, M12=-0.1763269807084645, M21=0, M22=1, SizingMethod='auto expand')";

    /* IE6 and 7 */
    filter: progid:DXImageTransform.Microsoft.Matrix(
             M11=1,
             M12=-0.1763269807084645,
             M21=0,
             M22=1,
             SizingMethod='auto expand');
}
	

This is the Microsoft Matrix Filter equivalent of skewX(10deg). Let’s take a look at how this works in all the major browsers:

Internet Explorer 6.0+	Firefox 3.5+	Safari 4+	Chrome 5+	Opera 10.5+

Isn’t that nice and consistent? The screenshots are from the Windows versions of the browsers, but you can expect the same results for Mac and Linux versions as well.

Is This Really Italics?

Not really. Technically, we are creating an oblique variant of this font. The Wikipedia entry for Oblique fonts states that many sans-serif fonts do not have italic variants, so this technique will be a useful one in a web developers toolkit.

Caveats

• If you are going to make a few words in a row oblique, make sure you wrap the <i> and <em> tags around each word. This is because the display: inline-block rule treats multiple words wrapped in one set of these tags as one word, which will cause problems when you want the words to wrap to the next line.
  

  Wrapping multiple words with one <em> tag

  Wrapping multiple words with separate <em> tags

• If the oblique text does not have a solid background color, it will appear “blocky” or “pixely” in IE. To fix this, you must use IE’s Chroma Visual Filter, as described in my last blog post, How to Make ClearType, @font-face Fonts and CSS Visual Filters Play Nicely Together.
• In IE, multiple oblique words may appear to have more white space than the other browsers. In this case you may need to create IE-only CSS rules that implement negative left margin on each word, using a solution like Paul Irish’s Conditional CSS Pattern.

Update (Sept. 3, 2010)

• This article originally has the filter and -ms-filter rules reversed, which is against Microsoft’s best practices for IE8. This error has been corrected.
• Thanks to Zoe Mickley Gillenwater for pointing out that IE8 needs to have all the filter functions (i.e. all the stuff in the double quotes) on one line.

The modern web developer wants to be able to use a variety of CSS3 effects together, but sometimes doing this in IE can be challenging, especially if you don’t want to use JavaScript. Let’s take a look a common problem with IE: blocky text in IE when using IE Visual filters on a block of text. For example, if you’ve ever tried to do the cross-browser CSS opacity trick to implement opacity in IE6, this problem manifests itself when the text is styled with no background color. A developer uses this well-known cross browser CSS-foo to make this work:

#badAntiAliasing {
	opacity: 0.5;

        /* IE 8 */
        -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=50)";

        /* IE 6,7 */
	filter: progid:DXImageTransform.Microsoft.Alpha(opacity=50);

}

And it looks great in every browser, but it looks like crap in Internet Explorer 6 with ClearType turned on. It is especially pronounced when using @font-face embedding with fonts that assume that some sort of anti-aliasing technology is being used. The example below uses Graublau Sans Web with the Alpha filter to illustrate the issue:

Opacity Solution in IE	Opacity Solution in every other browser

This has been a known problem with IE ever since 2006 when ClearType’s product manager, Peter Gurevich, announced on the IEBlog their decision to disable ClearType on elements that use any Visual Filter. If you read the comments on this blog article, you will see many upset developers. I was one of them, since this not only affects the Alpha Filter, but all of IE’s Visual Filters, some of which I use in cssSandpaper to get IE to support CSS3 properties like transform.

Today, however, we can rejoice. There is a usable workaround that will make ClearType rendered fonts look nice when using Visual Filters. In our example above, here is what needs to be done:

body.ie6 #goodAntiAliasing,
body.ie7 #goodAntiAliasing,
body.ie8 #goodAntiAliasing {
	background-color: white;
}

#goodAntiAliasing {
	opacity: 0.5;

        /* IE 8: yes, it is ugly but it has to be on one line. :-( */
        -ms-filter: "progid:DXImageTransform.Microsoft.Chroma(color='white') progid:DXImageTransform.Microsoft.Alpha(opacity=50)";

        /* IE 6,7 is more flexible: it can be on multiple lines. */
	filter: progid:DXImageTransform.Microsoft.Chroma(color='white')
                progid:DXImageTransform.Microsoft.Alpha(opacity=50);

}

What is going on here?

1. The first rule sets the background color of the container to a color that is represents the color of the majority of the background image on the page. Note that this rule uses Paul Irish’s Conditional CSS Pattern to serve it only to IE.
2. The second rule executes two of IE’s Visual Filters:
   • the Chroma Visual Filter, which tells IE “Please make this color transparent”. The color we choose to make transparent is the one we selected in the first rule.
   • the Alpha Visual Filter, which does the opacity trick

New Opacity Solution in IE	New Opacity Solution in every other browser

These filters must be in the order given, and not the other way around. Note also that care must be given that the color chosen to be transparent should be the average color of what is behind the text being styled, otherwise you will get less than optimal results. If this background is a complex image, just use the colour that’s used most often.

This fixes not only the IE opacity problem, but also issues with other Visual Filters, such as Matrix. I will be updating cssSandpaper to use this trick so that transformed objects in IE won’t look so blocky.

Take a look at the solution in action (make sure you look at it in IE in order to get the full effect)

Although this blog wasn’t meant to be a forum on just CSS font-embedding, it is a topic of great interest to me and has been the inspiration of a few articles here (my article on JavaScript font-smoothing detection being the latest). As a result, I have been very fortunate in meeting a lot of interesting and like-minded individuals who want to make the web a better place for typography.

One of the more vocal ones, Paul Irish, asked me to join a project that will allow developers to find ways to make web type look better right now. Other members include web font blogger Tim Brown of Nice Web Type and Ethan Dunham of the excellent font resource Font Squirrel. The result is The Type Rendering Project – we’ve set some goals and would like to open up dialogue with you to fulfill them. We’re asking for your participation, and lots of expert advice, to fulfill these intentions. If you are interested and are a Twitter user, follow us – and more importantly, tell folks you care about how type looks on websites.

Interested in making web typography look better?

Read about The Type Rendering Project!

Examples of font-smoothing and subpixel-rendering as performed by technologies like ClearType. Image Credit: Wikimedia Commons users Pandries and Kalan

In an earlier article, I mentioned that Boing-Boing had a few issues when they wanted to use @font-face embedding inside their website. In short, the problem was that some fonts look bad on computer monitors without font-smoothing enabled in the operating system. This brought on a lot of discussion as to whether there was a way to detect whether or not font-smoothing was being used using JavaScript. I initially thought there wasn’t a way, but after seeing a promising but incomplete method of detecting font-smoothing, I spent a few days devising a way to do it.

Internet Explorer Does Something Easily (For a Change)

Paul Irish mentioned to me and a few other colleagues that he came across a page using an Active X control that detects font-smoothing in IE. I was so hopeful … until I realized that this only works on browsers that have come into contact with Microsoft’s online Cleartype Tuner, which I visited with my copy of IE months before. If a users had never visited this page, the script would fail.

I was more disappointed because Googling “javascript cleartype” did not point to anything useful. However, searching for “javascript font-smoothing” pointed me to an article that told me about Internet Explorer’s screen.fontSmoothingEnabled property. This gives us what we need … but only in Internet Explorer. How on Earth can we detect font-smoothing in other browsers, and in non-Windows operating systems?

Canvas to the Rescue

Letter 'O' , Arial font, 32 px, rendered both without (left) and with (right) font-smoothing

I then thought about about the screenshots I made for the @font-face in Depth article. Can a browser render a black glyph and detect if there is some sort of non-black pixel colouring around the its edges of the glyphs? A human can tell the difference: if there are some non-black pixels around the edge of the glyph, it must be using font-smoothing.

But web browsers can do this too! Just have the browser draw a letter in black inside a canvas tag, and then have it sift through the canvas’ pixels to see if there are any that are not pure black or pure white (more accurately, have the browser check the alpha channel to see if there are any semi-transparent pixels, which have a value that is not 0 or 255). If there are no semi-transparent pixels, then the algorithm assumes that no font-smoothing is being used. I wrote an JavaScript routine that does this – it starts from co-ordinate (8,1) and scans left to right, to the bottom of the canvas (any point on near the top on the left-hand side of the canvas would have done as well).

The result is a JavaScript object, TypeHelpers, which implements this routine in one method, hasSmoothing():

var TypeHelpers = new function(){

   // I use me instead of this.  For reasons why, please read:
   // http://w3future.com/html/stories/callbacks.xml
   var me = this;

   me.hasSmoothing = function(){

      // IE has screen.fontSmoothingEnabled - sweet!
      if (typeof(screen.fontSmoothingEnabled) != "undefined") {
         return screen.fontSmoothingEnabled;
      } else {

         try {

            // Create a 35x35 Canvas block.
            var canvasNode = document.createElement('canvas');
            canvasNode.width = "35";
            canvasNode.height = "35"

            // We must put this node into the body, otherwise
            // Safari Windows does not report correctly.
            canvasNode.style.display = 'none';
            document.body.appendChild(canvasNode);
            var ctx = canvasNode.getContext('2d');

            // draw a black letter 'O', 32px Arial.
            ctx.textBaseline = "top";
            ctx.font = "32px Arial";
            ctx.fillStyle = "black";
            ctx.strokeStyle = "black";

            ctx.fillText("O", 0, 0);

            // start at (8,1) and search the canvas from left to right,
            // top to bottom to see if we can find a non-black pixel.  If
            // so we return true.
            for (var j = 8; j <= 32; j++) {
               for (var i = 1; i <= 32; i++) {

                  var imageData = ctx.getImageData(i, j, 1, 1).data;
                  var alpha = imageData[3];

                  if (alpha != 255 && alpha != 0) {
                     return true; // font-smoothing must be on.
                  }
               }

            }

            // didn't find any non-black pixels - return false.
            return false;
         }
         catch (ex) {
            // Something went wrong (for example, Opera cannot use the
            // canvas fillText() method.  Return null (unknown).
            return null;
         }
      }
   }

   me.insertClasses = function(){
      var result = me.hasSmoothing();
      var htmlNode = document.getElementsByTagName('html')[0];
      if (result == true) {
         htmlNode.className += " hasFontSmoothing-true";
      } else if (result == false) {
            htmlNode.className += " hasFontSmoothing-false";
      } else { // result == null
            htmlNode.className += " hasFontSmoothing-unknown";
      }
   }

}

// if EventHelpers.js is included, insert the hasFontSmoothing CSS classes
if (window.EventHelpers) {
   EventHelpers.addPageLoadEvent('TypeHelpers.insertClasses')
}

Note the object also has an insertClasses() method. This method, when run, adds a class to the html tag:

• hasFontSmoothing-true if font-smoothing is being used
• hasFontSmoothing-false if it is not
• hasFontSmoothing-unknown if the user agent is unable to tell

This makes it easy for developers who don’t want to mess with JavaScript code and just want to use CSS.

Also note the EventHelpers.addPageLoadEvent() call at the end of the code. This method (which is part of EventHelpers.js, included with the archive below) implements Dean Edwards’ window.onload alternative which doesn’t wait for all the objects in the page to be loaded. I use this implementation to execute TypeHelpers.insertClasses() when the page loads so any font-detection CSS rules will work right away. Please feel free to change this code to use the equivalent function call in Dojo, Prototype, jQuery, or whatever JavaScript code framework you prefer.

Example #1: JavaScript Font Smoothing Detection

Enough of theory … let’s look at it in practice! To show how to detect font-smoothing with JavaScript, I created a page that, when the page is loaded, checks to see if it can tell if font-smoothing has been implemented and tells the user. Here is the code that does this check:

function displayInfo() {

   var message;
   var isFontSmoothingOn = TypeHelpers.hasSmoothing();
   if (isFontSmoothingOn == true) {
      message = "This browser is using a font-smoothing technology";
   } else if (isFontSmoothingOn == false) {
      message = "This browser isn't using a font-smoothing technology"
   } else {
      message = "We could not detect if font-smoothing is being used."
   }
   document.getElementById('detectInfo').innerHTML = message;

}

window.onload = displayInfo;

See the above code in action

Example #2: CSS Font Smoothing Detection

As implied earlier, this library can help CSS use different fonts if the browser is using a font-smoothing technology. For example, using the following CSS will allow a browser to use the Droid Sans embedded font only if it using font-smoothing — otherwise, it will use Arial:

@font-face {
	font-family: "Droid Sans";
	src: url("/shared/fonts/DroidSans/DroidSans.eot");
	src: local("Droid Sans"),
	     local("Droid Sans"),
	     url("/shared/fonts/DroidSans/DroidSans.ttf") format("truetype");
}

body {
	font-family: "Arial", "Helvetica", sans-serif;
}

html.hasFontSmoothing-true body {
	font-family: "Droid Sans", "Arial", "Helvetica", sans-serif;
}

We can also serve special content to users depending on the way fonts are rendered on their browser. We first create content for all three scenerios (browser uses font-smoothing, browser doesn’t use font-smoothing, and the “we cannot detect” case) and wrap the content inside <code>div</code> tags using appropriate CSS classes:

<div class="fontSmoothingMessage initiallyHidden">
    <p>You browser <strong>is</strong> rendering this page
    with font-smoothing. Because of that, we will attempt
    to serve up the Droid Sans font to render this page,
    because we think it looks cool. If you are using a
    browser (such as Google Chrome) that cannot render
    downloaded True Type fonts by default, then the page
    will be rendered using Arial instead.</p>
</div>

<div class="noFontSmoothingMessage initiallyHidden">
    Your browser <strong>is not</strong> rendering this
    page with font-smoothing. It is for that reason we have
    decided to use the plain old Arial font to render this
    page, because it is hinted for use for displays that
    don't employ a font-smoothing technology.
</div>

<div class="unknownFontSmoothingMessage initiallyHidden">
    <strong>We are not sure</strong> if your browser is
    rendering this page with a font-smoothing technology.
    It is for that reason we have decided to use the plain
    old Arial font to render this page, because it is
    hinted for use for displays that don't employ a
    font-smoothing technology.
</div>

Note all the div tags are members of the class initiallyHidden. This class will be used to hide all font-smoothing related content until the script kicks in.

However, all this will not work unless we use the following CSS code:

.initiallyHidden {
	display: none;
}

html.hasFontSmoothing-true .fontSmoothingMessage,
html.hasFontSmoothing-false .noFontSmoothingMessage,
html.hasFontSmoothing-unknown .unknownFontSmoothingMessage {
	display: block;
}

Of course, this whole soltution relies on whether JavaScript being turned on in the user’s browser. This should be kept in mind when implementing this solution.

See the above code in action

Download

All code used in this article can be downloaded below (Note: version 1.0 was missing the Droid Sans Fonts which have now been put into the archive. Thanks to John Faulds for pointing this out).

TypeHelpers.js v.1.0a and sample code.

With the help of Tim Brown, it was determined that the code detected font-smoothing correctly in the following browsers:

• Internet Explorer 6 and up on Windows XP and higher.
• Firefox 3.5 and higher on Windows XP and higher, Mac OS X 10.4 and higher, and Ubuntu Linux 9.10 (and probably lower)
• Chrome 3.0 on Windows XP and higher
• Safari 4.0.3 on Windows XP and higher and Mac OS X 10.4 and higher

This script cannot detect font-smoothing in any version of Opera (at the time of this writing, this includes all versions up to 10.10), since it cannot write text inside the canvas element in a way we can poll the pixels afterwards. If anyone can find a way of making it work with Opera, please write a comment below — I’d love to be able to support this browser.

Testing Caveats

Testing font-smoothing in most Windows web browsers is easy since it can be turned off inside the Display control panel. However, when using Safari for Windows, it is necessary to navigate inside Safari’s Appearance preferences and set the Font-smoothing option to Windows Standard. This is because by default, Safari uses it’s own built-in font-rendering engine which doesn’t seem to render aliased fonts. In Mac OS X, it seems anti-aliasing only works for fonts below a certain size, so aliased fonts don’t seem to be an issue with that operating system. In Ubuntu Linux I have yet to find a way of shutting of font-smoothing. If anyone knows a way, please let me know.

SVG fonts for Opera and Chrome

Jonathan Snook wrote a great article regarding Opera 10 and Google Chrome supporting SVG fonts (Chrome can load them without any pesky command line switch!).  He mentions how to convert TrueType fonts to this format using Batik, and that by removing all the <hkren> elements inside the file’s XML can make the font smaller than the original TrueType file.  Too bad the browsers don’t support this format.

Opera’s buggy implementation

I noticed after I launched my first @font-face article that Opera was not loading the fonts on my blog when users visited more than one page. It turns out that Opera 10′s implementation of @font-face is a little buggy. When you feed it a page with an embedded font, you may not see the embedded fonts properly, like in the screenshot below:

Opera sometimes doesn't load the font at all, and removes other styling (click to enlarge).

According to Opera, this happens when “specifying different weights and styles for a single font-family name”. Håkon Wium Lie, the company’s Chief Technology Officer , has described a work-around until the company can fix the problem properly.

I am debating whether to implement the work around on my site, or to wait for Opera to fix the problem and patch all Opera 10 installations via auto-update (I’m leaning towards the latter).

Performance Issues With Font Embedding

One of the comments on the last article came from Steve Souders who had performance concerns with font-embedding. Paul Irish came back with information showing the when browsers load the fonts, and what they do before the font is loaded.  He also shows how to use JavaScript to make the loading behaviour consistent between browsers.

The performance issues with font-embedding is something I am going to be keeping an eye on, especially when it comes to font-services, which the OpenType site believes will be the future of web font distribution for commercial fonts. Although it doesn’t seem like much of an issue currently (my blog seems to load quickly), I don’t want to do anything that would slow down my web applications – especially if I am using them just to make the text look a little prettier.

Windows XP Rendering Issues

Boing-Boing had a bad experience with font-embedding. Turns out they got a lot of complaints when they decided to incorporate it into their website. The reason: some users didn’t have ClearType turned on, and the font Boing-Boing chose looked “like ass” without ClearType.

Below are screenshots of this site without ClearType on:

Internet Explorer without ClearType

Firefox without ClearType

The article stated that there are quite a few XP computers which apparently don’t have ClearType on by default. I wonder if there are any stats to back that up. If so, then developers embed fonts into pages should test that scenario as well. It does look different.