W3C home > Mailing lists > Public > public-css-testsuite@w3.org > February 2017

Re: Ahem font and anti-aliasing

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 1 Feb 2017 12:40:14 +0900
Cc: Gérard Talbot <css21testsuite@gtalbot.org>, "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-Id: <FB3A2530-1CAF-4831-9A83-258B1804082E@rivoal.net>
To: "Myles C. Maxfield" <mmaxfield@apple.com>

> On Feb 1, 2017, at 10:00, Myles C. Maxfield <mmaxfield@apple.com> wrote:
> 
> The exact math used to compute antialiasing is a property of the rasterizer software. The rasterizer uses hints from various sources to determine which kind of antialiasing to apply. Some of these signals may be from the font, some may be from the user’s preferences, some may be from system defaults, and some may be from a higher-level construction like CSS. Every rasterizer pays attention to different signals when performing this determination.
> 
> Which environment and platforms are you interested in?

I don't know about all environments, but at least on OS X (currently checking on 10.11.6) with a retina display, ahem has non sharp edges on Firefox and Chrome (and Presto-based Opera, if anyone is curious). As far as I can tell, there is no such problem in Safari, or if there is, it reproduces in more limited circumstances that I have not been able to trigger. I do not have a high DPI windows or linux environment to check these same browsers in a different OS, or IE/Edge. This also reproduces on Firefox and Chrome for Android at some zoom levels.

I've attached 2 reftests to this mail based on the common filled green 100px ref. You you look carefully, while the test and the ref look similar, the ahem box is actually very slightly larger in Chrome and Firefox. In ahem-001.html, this makes the green box slightly larger in the test than in the ref, and in ahem-002.html this causes a very thin red border to appear around the green box. The difference is very subtle, but sufficient to make ref-tests fail.

Is this a bug in the font rasterizers, or is this an allowed way to rasterize ahem as currently defined? If this is not a bug, can ahem be defined in a way that makes it unambiguous that we want sharp edges? If this cannot be done purely from a theoretical spec point of view, can it still be done in practice given how existing rasterizers work? If no, should we give up on writing reftests that use ahem on one side and images/backgrounds/borders/svg... on the other side?

—Florian

PS: http://jsbin.com/sozebo/ is same test as ahem-002.html using ahem via @font-face with a data url, for testing in environments when installing a font is not practical





Received on Wednesday, 1 February 2017 03:40:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 1 February 2017 03:40:49 UTC