Live data from Hacker News

Browser Font Rendering Inconsistencies

blog.stephaniestimac.com

41–50 of 52 posts

Re: Browser Font Rendering Inconsistencies

#41
Damn it folks, stop trying to make your designs pixel perfect!

There will always be font rendering inconsistencies. It's how the web works.

> The cross-platform problem is a harder one to solve as you can't control how the operating system handles font rendering.

Bingo.

So stop trying! Embrace flexible designs and differences in rendering

Re: Browser Font Rendering Inconsistencies

#42

Damn it folks, stop trying to make your designs pixel perfect! There will always be font rendering inconsistencies. It's how the web works. > The cross-platform problem is a harder one to solve as you can't control how the operating system handles font rendering. Bingo. So stop trying! Embrace flexible designs and differences in rendering

I think the problem described in the article is a bit beyond 'pixel perfect', though. the font weight is DRAMATICALLY different. Text being way too thin or too thick can have an impact on readability.

Re: Browser Font Rendering Inconsistencies

#43
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…

> "Strictly speaking, I would classify this as user error, not a browser flaw, though it's an easy mistake to make"

I agree, but browsers should use console warnings to report when they resort to font synthesis or weight substitution. That would go a long way to help web developers understand this problem.

Similarly, console warnings to report character substitution when a needed character is not present in the font-family list would be useful.

In general, I want more transparency from text rendering engines when they encounter something that may not be what a professional designer or typesetter would want. The opacity of today's engines breeds ignorance among their users (web developers).

Re: Browser Font Rendering Inconsistencies

#45

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…

As far as I know, -webkit-font-smoothing doesn't change weight, it changes rasterization. What you describe in Photoshop also isn't weight, it's rasterization.[1] See my post below. This is developer error from not understanding the font-weight implementation. The real answer is browser implementors use an algorithm to determine the nearest available weight. Succeeded standards, depending on how up-to-date the browse…

Yes, it changes rasterization. It’s because MacOS has a legacy of dilating the pixel outlines when subpixel antialiasing is enabled.

When subpixel antialiasing first appeared on OS X, the FIR filter affected the gamma curve, making the font seem too light or thin. Correcting gamma the right way was expensive at the time, so they changed the rasterizer to dilate the outlines, increasing the contrast of the text.

At that same time, the *nix APIs like Xft just cranked up the coefficients of the filter so that the sum was ~40% higher than it was supposed to be, which also worked. I think that was a better method than sabotaging the outline shape.

Re: Browser Font Rendering Inconsistencies

#46
post #45

Earlier quoted context omitted.

As far as I know, -webkit-font-smoothing doesn't change weight, it changes rasterization. What you describe in Photoshop also isn't weight, it's rasterization.[1] See my post below. This is developer error from not understanding the font-weight implementation. The real answer is browser implementors use an algorithm to determine the nearest available weight. Succeeded standards, depending on how up-to-date the browse…

Yes, it changes rasterization. It’s because MacOS has a legacy of dilating the pixel outlines when subpixel antialiasing is enabled. When subpixel antialiasing first appeared on OS X, the FIR filter affected the gamma curve, making the font seem too light or thin. Correcting gamma the right way was expensive at the time, so they changed the rasterizer to dilate the outlines, increasing the contrast of the text. At th…

That's fascinating, I wasn't aware of such details!

Re: Browser Font Rendering Inconsistencies

#47
Tangential but I made getsnapfont.com to test how fonts look like on various OS/browsers.

Unfortunately most designers I've worked with don't acknowledge these inconsistencies when designing. For them, their 2x retina mac represents the vast majority of users.

Re: Browser Font Rendering Inconsistencies

#48

Why would it be a bug if two browsers don’t render a h1 element the same, if you don’t specify how you want it to look?

That definitely makes it sound more like undefined behavior than a bug.

Implementation defined :P

Re: Browser Font Rendering Inconsistencies

#49

Damn it folks, stop trying to make your designs pixel perfect! There will always be font rendering inconsistencies. It's how the web works. > The cross-platform problem is a harder one to solve as you can't control how the operating system handles font rendering. Bingo. So stop trying! Embrace flexible designs and differences in rendering

I think the problem described in the article is a bit beyond 'pixel perfect', though. the font weight is DRAMATICALLY different. Text being way too thin or too thick can have an impact on readability.

A similar problem occurs with the valuable Japanese font "Yu Gothic", which is available on both Windows and Mac by default (both availability is rare).

(Not surprisingly no English info available) https://neos21.hatenablog.com/entry/2019/01/05/000629

Re: Browser Font Rendering Inconsistencies

#50
post #12

Earlier quoted context omitted.

You don't support Apple users on your website? You don't bother to fix breaking issues for any Apple device? I'm genuinely curious to know what industry you work in since that seems like a huge segment of visitors.

Any websites that I work on, which I don't often anymore, use standards. If its broken in Safari, then Safari needs to support the agreed upon W3C standards. I don't personally do weird cutting edge stuff, its stuff generally that's been supported in Firefox and Chrome stable for years. Safari must implement these, or be discontinued. However, generally, Mac users have always been below 10% of PC users, most of them…

it is required to be an unoptimized Safari instance underneath, with zero access to any sort of GPU or Javascript optimization) but only a small fraction of handsets sold have been iPhones.

3rd party browsers have had access to WKWebView for a while now, so they get almost all the goodies Safari has access to. You can read all about it at "New Chrome for iOS is finally as fast and stable as Safari"--https://arstechnica.com/gadgets/2016/01/new-chrome-for-ios-i....

The iPhone has a little more than 45% of the smartphone market in the United States, which is not nothin’: https://www.statista.com/statistics/236550/percentage-of-us-....

And there are over 1.5 billion active devices in the world--and growing: https://www.macrumors.com/2020/01/28/apple-1-5-billion-activ...

The number of devices running the most current version of Android is pretty small compared to the 80-90% of iOS devices that run the most current operating system. That matters for both web developers and native app developers.

For example, Android 9.0 Pie is only 32.43% of the installed base of Android users. Which means 60%+ are older versions that don't support the latest web features, etc: https://gs.statcounter.com/android-version-market-share/mobi...

On the other hand, iOS 13 is installed on 92% of all iPhones sold in the last 4 years: https://www.imore.com/ios-13-has-been-installed-92-iphones-r...

Anyone who’s website is used by US smartphone users by definition has a lot of iPhone customers.

Post reply on HN