Font Smoothing Techniques? Text-Shadow Rendering Differently in Chrome 14.0.833.0 or Higher

Font Smoothing Techniques? text-shadow rendering differently in Chrome 14.0.833.0 or higher

Well, I've figured it out, sorta. Annoying since I set a bounty, but whatever.
I'm fairly certain this is not a bug and it is expected behavior - especially since we've seen a few more iterations of Chrome and it's stayed the same.
A few different methods work. I wrote up a bit for my blog, you can see the full article here, but here's the bulk of it:

First, I tried the -webkit-text-stroke:1px #000 where #000 is the
color of the text. But this style is meant for use where the color of
the text is different from the stroke, for a nice text-outline. When
both are the same color, it looks...odd. I'm not sure why; I'm no
font-rendering expert. You can see the behavior in the picture after
the article.

Next I tried a simple text-shadow:#000 0 0 1px where #000 is the same
color as the text. Due to the same Chrome 14.0.833+ problem, this
still leaves the font looking somewhat jagged. It's better than just
plain text, however.

Next I tried a combined the two attempts above. This looks a little
bit better, but it bulks up the text as it essentially adds 2 pixels
to the thinkness of the text.

Lastly, I tried applying two text-shadows: text-shadow:#000 0 1px 1px,#000 0 -1px 1px > > where #000 is the color of the text. What this does is
apply two text shadows, one of which is pushed down a little and the
other pushed up. This way, the text shadow covers the jagged edges. It
bulks up the text a little but definitely smooths it out.

Depending on the size of your text, different methods work. Smaller
(but still jagged) text could use the text-shadow, larger text could
use the shadow/stroke method, and very large text could use the
dual-shadow method. Of course the larger the text the less noticeable
the extra few pixels become. You can see all the different methods
here

Ragged website font on Windows

The font I use for headers looks ragged on Windows using Chrome

1. Your webkit-font-smoothing rule is missing a - prefix, it should be -webkit-font-smoothing

2. To solve the issue of Chrome font-rendering, add -webkit-text-stroke: 0.3px;

Difference:

Final code:

h1, h2 {
    -webkit-font-smoothing: subpixel-antialiased;
    -webkit-text-stroke: 0.3px;
}

* You may need to apply the above CSS to all selectors that use the custom font.

---

Preview

Original answer: https://stackoverflow.com/a/11493510/877671
voting to close as duplicate.

Font with strange shadow (blur) when Opacity is below 1 (Chrome Only)

First of all, I want to Thank the @Tschitsch. He's comment was a light in the darkness. So, thank you!

In the end, I still don't know if the other users don't witness or just don't notice the issue. Anyway, I wanna thank everybody that tried to help in anyway.

Now, to the Answer:

Making a little of observation, I noticed that it only happens when the text was inside a DIV that its opacity set to below 1 (100%). When the opacity is 1, the text is rendered perfectly clear (So, I assume it's not a normal thing. It's not like... This font is rendered this way in Chrome, there is nothing you can do).
I also noticed that there was none problem in the text to be semi-transparent it self.

So, in conclusion, the problem was only the inheritance of the opacity property by the text from the div.

My solution was simply use the opacity directly in the colors of the elements, witch allow me to make the DIV semi-transparent, without set a opacity to the text (but You can use the rgba in the text too, without any issue).

To especifically solve the issue in the Bootstrap Tooltip Component (v 2.3.2) in Chrome, below is my code. It makes the Text be clear in Firefox 27, Chrome 34, IE 8 (I still don't believe in this last one hahaaaha)

Css Code

.tooltip.in {
    opacity: 1;
}

.tooltip-inner {
    color: #FFFFFF;
    background-color: rgba(0,0,0,0.8);
}

.tooltip.top .tooltip-arrow {
    border-top-color: rgba(0,0,0,0.8);
}

I really hope I could help anybody that across this issue too.

(Still don't understand why was down-voted...)

Why does my font look much better in IE9?

Simply put: this is because IE9 introduces a new font rendering engine that is based largely on that seen in WPF's ClearType implementation. Its enhanced engine does a better job at reducing jagged edges, making fonts look smoother and better, especially at large sizes.

Getting into the details — and I mean to get really technical — this breed of ClearType is different from the one seen in the rest of Windows, also known as GDI ClearType (for Windows' GDI graphics library). The old GDI ClearType is the one that Windows versions of most other browsers base their font rendering engines off, which is also the one that makes fonts look really jaggy in large sizes.

The following paragraph from the second link summarizes most of the rest of its content, that explains quite nicely why fonts look smoother in IE9's new engine:

A significant improvement over the previous version of ClearType is the use of sub-pixel positioning. Unlike the ClearType implementation found in GDI, the ClearType found in Windows Presentation Foundation (WPF) allows glyphs to start within the pixel and not just the beginning boundary of the pixel. Because of this extra resolution in positioning glyphs, the spacing and proportions of the glyphs is more precise and consistent.

See, especially, the section on Y-direction anti-aliasing with screenshots for comparison. Another quote:

ClearType in Windows Presentation Foundation (WPF) provides antialiasing on the y-direction level to smooth out any jagged edges.

Chrome 37 DirectWrite fixed text rendering, but special characters still appear grainy

There are several ways to use DirectWrite. You can let it decide when to switch to hinted characters (which depends on what the font tells it) or you can force vectors all the way, but this requires a bit more implementation code, i.e. a custom renderer. So simply "using" DirectWrite is not the end of story.

I don't know how Chorme does it vs IE, but I suspect the stars and checkmark are being rendered in the "old school" way, being hinted, which is why you start to see them smooth after a sufficiently big size, when then hinting turns off.

Hinting is heavily dependent on the font. The newer Microsoft fonts are less heavily hinted than the old ones. The white star doesn't have widespread font support. Of the newer MS fonts, only Segoe UI Symbol supports it. From the older ones, only Arial Unicode seems to support it. The same font support observation applies to the checkmark glyph.

In your example, the two glyphs are probably coming from some crap/free font on your machine (possibly something that ships with Chrome as fallback font.) If I force the font to Segoe UI Symbol, the star looks pretty good to me, certainly not much worse than the text, when rendered with Chrome 37:

<p style="font-family:'Segoe UI Symbol'; font-size:12px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Segoe UI Symbol'; font-size:18px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Segoe UI Symbol'; font-size:24px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Segoe UI Symbol'; font-size:30px">✓ This is a ☆ paragraph.</p>

Actually the checkmark looks pretty good in Arial Unicode too. Only the star is a bit thin/wonky. But it's not the same as the one you've shown, so yours is not even coming from Arial Unicode.

<p style="font-family:'Arial Unicode MS'; font-size:12px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Arial Unicode MS'; font-size:18px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Arial Unicode MS'; font-size:24px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Arial Unicode MS'; font-size:30px">✓ This is a ☆ paragraph.</p>

On my box, if I pick a font that doesn't have the checkmark and white star glyphs, e.g.

<p style="font-family:'Gabriola'; font-size:30px">✓ This is a ☆ paragraph.</p>

then Chorme falls back to Arial Unicode for those two glyphs:

But I'm guessing you don't even have Arial Unicode installed. According to Wikipedia's page on that font, it only comes with MS Office, not with any base Windows operating system. Segoe UI Symbol should be available on base Windows 7 though. I'm guessing Chrome just picks the first font, in alphabetical order, that contains the glyph if it's missing from the font specifically requested. On my box, IE11 behaves differently on that last line; it serves the missing check-mark and white-star glyphs from the MS Mincho font, so the output looks like this:

Interestingly enough, even though MS Mincho seems to be widely available according to that MS page I linked previously, fileformat.info doesn't mention it. And if I force Google Chrome to use this MS Mincho font, I surely get the crappy output you get at smaller sizes:

<p style="font-family:'MS Mincho'; font-size:12px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'MS Mincho'; font-size:18px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'MS Mincho'; font-size:24px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'MS Mincho'; font-size:30px">✓ This is a ☆ paragraph.</p>

So this seems to be what Chrome defaults to on your box for those missing glyphs. At small sizes MS Mincho actually looks a little better, but not by much, in IE11:

On Firefox on the other hand, the missing glyphs (in Gabriola) get served from Segoe UI Symbol, which is why they look good:

If you actually force Firefox to use the crappy MS Mincho font, it looks just as bad as IE11:

Apparently the pixelated look at small sizes of MS Mincho (and its brother MS Gothic) is somehow by design. I don't know enough about CJK fonts to have any opinion on that myself... Suffice to say they are unfortunately installed by default on a wide variety of Windows(es).

Even more strange is that the much newer replacement that MS devised for MS Mincho and MS Gothic, which is called Meiryo, also has these two glyphs, but it's not selected in IE11, even though it is alphabetically before MS Mincho and MS Gothic ('MS' part of the name.) Here's what Meiryo looks like:

<p style="font-family:'Meiryo'; font-size:12px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Meiryo'; font-size:18px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Meiryo'; font-size:24px">✓ This is a ☆ paragraph.</p>
<p style="font-family:'Meiryo'; font-size:30px">✓ This is a ☆ paragraph.</p>

Firefox has a pretty complex font fallback algorithm, in which the fallback fonts lists depends on the range of the glyphs. It's given starting around line 700 in gfxWindowsPlatform.cpp. For the 2xxx glyph range, Firefox is coded to prefer Segoe UI Symbol over Arial Unicode. Chromium probably has something similar, although I suspect less elaborate.

What's also interesting (and strange at the same time) is that DirectWrite itself implements a font fallback at least for the simple DrawText case, but its fallback (at least for Gabriola) is also Segoe UI Symbol! So IE11 and Chrome must be doing something custom to get it worse looking than DirectWrite does it out of the box. Here's a screenshot of the DirectWrite SDK sample app modified by simply changing the test string:

If you want to serve your own fonts, which is really the only way to ensure consistent looks if you can't control what fonts are installed on the clients, then you should look at a tutorial like this one. For inconsistency reasons like the above, some experts like Lonely Planet's Ian Feather recommend switching to SVG for icons like those. YMMV as the saying goes...

---

Related Topics