Do browsers render system fonts and webfonts differently?

Adam Jagosz

https://www.codeclouds.com/blog/why-web-fonts-matter-a-short-history-and-future-of-font-rendering/

Web Fonts as an Alternative

Any font rendered by the system is going to look different from OS to OS, even if it is a “web safe font”. The same font files on different operating systems may even produce different results!

The answer is to use web fonts, which are hosted online and partially rendered by the browser. Things like Google Web Fonts and Font Awesome are examples. The browser itself if responsible for most of the rendering process, however the subpixel rendering or anti-aliasing differs from OS to OS. For example, Google Chrome and Firefox may look slightly different, but Firefox on Ubuntu, Mac, and Windows will all render the font the same way – meaning that they will look identical in size, thickness, and spacing on all operating systems. Mac for example, won’t use subpixel rendering, but it will line up with other operating systems on the same browser just fine.

I came upon this article and I was a bit baffled. Is any browser going to render the same font differently when it’s installed in the OS and differently when it’s a webfont?

Another laughable bit,

Vector graphics are clear and highly scalable, but their file sizes can be larger and this means they have issues being displayed on a lot of devices. To get vector images into a format that digital devices can handle, they must be turned into rasters: images of a set size, composed of pixels.

Matthew Smith

Is any browser going to render the same font differently when it’s installed in the OS and differently when it’s a webfont?

Yes (well, I suppose it depends).

For one, there is no way for you to determine if the desktop font I have downloaded locally on my machine is the exact same as the web font you are trying to serve.
The difference might be as small as having different versions (e.g. 1.1 vs 1.2) to as large as having two different fonts with the same name (Garamond). Granted, most foundries distinguish their version of a font (like Garamond) by including their foundry name in the actual font name.

Secondly, a foundry may build their desktop and web fonts differently. In some cases, a foundry may choose to "equalize" their vertical metrics in their web font (for the sake of consistency across browsers), but the desktop font may have differing values.

Thomas Phinney

If it is the exact same file, whether it is a local (OS installed) font or a web font is irrelevant: the browser will render it identically.

But, as Matthew suggests, unless you are personally involved in the hosting of the web font, you may have great difficulty determining if they are exactly the same font (or derived in some way that does not affect the on-screen rendering).

Georg Seifert

I had some examples where Safari would render installed fonts differently than system fonts. It is some time ago, so I don't know if that is still the case. One case what that Safari would not support sbix-webfonts, but would render the system emojis just fine. That doesn’t mean that regular text would be different but it means that there are different code paths and thous it could be different.

Adam Jagosz

I agree comparing font files is tricky, so the article might not be wrong, but it gives the wrong reasons. The phrasing suggests that the exact same fonts will be treated differently by the browsers, as if OS fonts are rendered natively by the OS to a greater degree. (As Georg suggests, that sometimes might be the case though, but that’s probably monkey patching things in the OS, right?)

Adam Twardoch

Well, SF is a variable font on macOS and **I think** Chrome will render it via CoreText. But Chrome will render a variable webfont via FreeType. Not sure though. 

I know that Chrome will employ a FreeType-based rendering path for variable web fonts. But I'm not sure what it will do for installed variable fonts. 

Adam Twardoch

Then, there is the notion of ots (the OT Sanitizer library), used by Chrome and Firefox, I think. The library will be used to check web fonts, and will reject SFNT tables that it doesn't like (so you may not get, say, GPOS kerning). But I don't think the browsers will run ots on installed fonts — again, something I haven't tried in a long time. 

Adam Twardoch

And then, macOS CoreText will render fonts that, for example, only have three 0.3 cmap and don't have the 3.1 cmap at all. Or fonts that start with 'true' rather than \00\01\00\00. But I'm not sure such fonts would be rendered as web fonts. 

Georg Seifert

Are you sure Chrome is using FreeType. It did use CoreText a year ago as it shoed the same mistakes as Safari/MacOS (keeping the LSB constant).

Adam Twardoch

As you can see from the issues listed below, Chrome switches between FreeType and the systen renderer depending on the particular font flavor, and particular OS. I think the newest Chrome uses FreeType for all variable fonts on all Windows and on macOS <10.12, and for CFF2 variable fonts on all systems, but on macOS 10.12 and newer, it uses CoreText for TT-flavored variable fonts. It’s complicated, but my understanding is that they use FreeType as a fallback but prefer to use the system. 

https://bugs.chromium.org/p/chromium/issues/detail?id=714553

https://bugs.chromium.org/p/chromium/issues/detail?id=713529

https://bugs.chromium.org/p/chromium/issues/detail?id=815251

John Savard

What is a web browser?

It is a program to read an HTML file from the web, given its web address, and to render the contents of that file. Instructions in the HTML file may call for downloading other files like images.

When text is printed as part of rendering, if that text is in a font installed on the computer, the web browser can just be lazy and say "write text to window" using the common garden-variety OS call.

Now, it may be that Windows and MacOS have a provision where a web browser can download a web font, and then the operating system will install it in a sandbox or something. At least in the early days of web fonts, though, I would have thought that the browser basically did all the rendering itself, and so it wouldn't be at all surprising if results were slightly different from what the OS would do.

Adam Jagosz said:

Another laughable bit,

Vector graphics are clear and highly scalable, but their file sizes can be larger and this means they have issues being displayed on a lot of devices. To get vector images into a format that digital devices can handle, they must be turned into rasters: images of a set size, composed of pixels.

Laughable to an extent.

To see text on your screen, the vector images do have to be turned into raster images, composed of dots in a specific location. Laser printers need dots too, just smaller ones.

However, it is not necessary for the rasterization of True Type fonts to be done manually, instead the "digital device" known as a computer is perfectly capable of carrying it out when text is displayed.

So it is half true - rasterization is a required step in the process of rendering text with a font - but hilariously false in claiming that rasterization must take place before fonts are usable with computers.