5 ms·

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 be

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.

jpeloquin 9y ago
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?
- iainmerrick 9y ago
  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.
- kevin_thibedeau 9y ago
  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.
jochung 9y ago
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.
- TazeTSchnitzel 9y ago
  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.

jpeloquin 9y ago

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?

iainmerrick 9y ago
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.
kevin_thibedeau 9y ago
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.

jochung 9y ago

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.

TazeTSchnitzel 9y ago
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.