Live data from Hacker News

Browser Font Rendering Inconsistencies

blog.stephaniestimac.com

31–40 of 52 posts

Re: Browser Font Rendering Inconsistencies

#31

It's a webkit thing. Try -webkit-font-smoothing: antialiased and you'll get the version with less weight, while 'subpixel-antialiased' is the heavier one. This weight difference is more noticeable in white text against dark backgrounds. Photoshop offers several options on how to render text that show different "weight" in a similar way... they're called "Crisp", "Strong", "Smooth", etc. In particular there's a "Mac L…

It's not, actually.

In other cases, this might be that. But in this particular case, it's not. If you look closely, it's not about the heaviness at the edges -- they're literally different outlines. Safari in this case is actually creating a "faux bold". It has nothing to do with the heaviness of antialiasing, like Photoshop's options.

Re: Browser Font Rendering Inconsistencies

#32
post #9

This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users. Safari enforces the OSX "thick antialiasing", causing really thick fonts. This also causes really thick fonts, unreasonably so, in normal non-web apps. The reverse, unfortunately, is true: a lot of web developers worship at the altar of Apple, and have screwed up perfectly good websites by mak…

It's true that Mac has different font rendering, but this is not that.

This article is about "faux bold", which is intentionally faking a bolder text. This goes way beyond any antialiasing preferences.

You're describing Mac-style antialiasing, which has nothing to do with this article.

(Also your description of thin fonts isn't even correct. Thin fonts, if rendered mathematically correctly e.g. converted to curves in Photoshop, are too thin to be legibile at small sizes period. Mac compensates by giving heaviler antialiasing, while Windows compensates with hinting that forces strokes to be a full pixel wide. They look different, but there's no widespread problem of fonts being too thin on Windows.)

Re: Browser Font Rendering Inconsistencies

#33
Summary: if you're specifying a bold font style (700) but not supplying a bold version of the font (only 400 and 600), Safari creates a "faux bold" on its own, while other browsers fall back to the next-closest weight (600).

Neither behavior seems more obviously correct, since you're asking for something that doesn't exist.

Moral of the story: whenever you're using webfonts that come in a variety of weights, make sure you're loading font files in the weights you're intending to use! Otherwise behavior may vary.

(And in contrast to multiple comments here, this has nothing to do with macOS using different/darker types of antialiasing than other operating systems. That is not what this article is about.)

Re: Browser Font Rendering Inconsistencies

#34
Is there something happening in the font world I don't know about? I just spent the past day struggling with fixing my fonts on Arch Linux. I finally just deleted all xorg packages that give bitmap fonts becuase I couldn't get any of them to load right in Firefox. This was after a font package totally broke my installation a week ago.

Re: Browser Font Rendering Inconsistencies

#36
post #9

This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users. Safari enforces the OSX "thick antialiasing", causing really thick fonts. This also causes really thick fonts, unreasonably so, in normal non-web apps. The reverse, unfortunately, is true: a lot of web developers worship at the altar of Apple, and have screwed up perfectly good websites by mak…

This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users

Seriously? You changed operating environments because of font weights? That seems a little over-the-top.

Re: Browser Font Rendering Inconsistencies

#37
post #6

The problem arises when you're invoking a style (like `h1` or `h2`) that by default requests a bold weight, but the `font-face` declaration only supplies a WOFF declared "font-weight: regular". In that case, the browser will try to synthesize a bold style by "smearing" the regular. One fix for this is to set heading tags to "font-weight: normal". Another fix is to supply two `font-face` declarations for the same WOFF…

Thanks for sharing this explanation! This may fix a frustrating font problem we're encountering with mobile Safari. We're also running into other font issues, such as serving Chinese fonts. Are you open to consulting? Your profile doesn't list contact information. Is it okay to send an email with more details?

Re: Browser Font Rendering Inconsistencies

#38
post #9

This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users. Safari enforces the OSX "thick antialiasing", causing really thick fonts. This also causes really thick fonts, unreasonably so, in normal non-web apps. The reverse, unfortunately, is true: a lot of web developers worship at the altar of Apple, and have screwed up perfectly good websites by mak…

This is a well known Mac thing, and its one of the top 5 reasons why I moved away from OSX and refuse to support Apple users Seriously? You changed operating environments because of font weights? That seems a little over-the-top.

Only on Safari, even.

Yet this comment over all brings up a good point (re: downvotes).

Re: Browser Font Rendering Inconsistencies

#40

Summary: if you're specifying a bold font style (700) but not supplying a bold version of the font (only 400 and 600), Safari creates a "faux bold" on its own, while other browsers fall back to the next-closest weight (600). Neither behavior seems more obviously correct, since you're asking for something that doesn't exist. Moral of the story: whenever you're using webfonts that come in a variety of weights, make sur…

[deleted]
Post reply on HN