Comment by ZenPsycho | Hacker News Reader

Comment by ZenPsycho | Hacker News Reader

there is a much less visible, less obvious problem that would be seriously exacerbated by pursuing this.

most software, including iOS, OSX, and windows, has been doing antialiasing of fonts with the wrong gamma for years. this wrong gamma has been masking another problem: scaling a glyph shape without adjusting its weight is the wrong way to set type at a particular size. up til now, font hinting, and the wrong gamma has fudged the appearance of font weight to be “almost right” on low resolution displays. but on high resolution displays, you begin to see a font’s true weight more accurately, since the effect of wrong gamma and font hinting is significantly reduced. the result is small type sizes appear way more light than it “feels” they should.

Apple chose to solve this in a really unfortunate way for devices with high density displays: it applies a fake bolding effect to approximate the effect of the wrong gamma antialiasing. comically, they apply the wrong amount of fake bold, such that the fake bold affects type set at larger sizes way more than it should.

in conclusion: yes, let’s make 12pt the same everywhere: but we will also need to fix all these other hacks on hacks at the same time.

Apple does apply gamma correct blending, at least when rendering text to a solid surface so that subpixel alpha kicks in.

If you render it to a transparent layer and force an RGBA blend, it gets blended in sRGB color space rather than linear RGB, but this is a flaw that can't be easily changed because of legacy reasons. Any design that uses transparency of any kind, text or graphics, would change appearance. I agree that we should have a body { color-space: linear; } though, but good luck in explaining why to coders and users alike.

The fattening that you are complaining about is something else entirely: it mimics the way physical ink bleeds on paper. The weights were under designed to compensate for this, and they replicated this effect virtually.

Classic example of physical ink bleeding is the Courier New font on Windows. It's so light as to be unusable for a lot of things. Why? Because it was rasterised off an IBM Selectric typeball, and they failed to account for the ink bleed that occurs in actual typewriter use, unlike whoever designed the typeball.

Is the "wrong gamma" problem that (pixel intensity)^gamma is proportional to luminance, but the software incorrectly does its antialising calculations directly on pixel intensity? Or something else?

Yes, that's basically it. I think there are at least two different mistakes that can be made.

When a font is rendered you usually calculate the per-pixel coverage. Mistake one is to interpret those coverage values as if they're sRGB colors (so 50% coverage would be #808080 which is a rather dark gray in sRGB, not mid-gray). That makes text look heavier than it should be, and makes diagonal lines look jaggy.

Mistake two is to blend sRGB colors directly rather than converting them to a linear space first. That can give colored fringes on blended images, because the RGB intensities get skewed.

They were replicating the look of small fonts on CRTs where black text on a light background needed thicker lines to compensate for the bleed from neighboring active phosphors "shrinking" the apparent weight.

Reply on news.ycombinator.com