Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Text Rendering Hates You

gankra.github.io

Post reply on HN
Print view View original

61–70 of 172 posts

Re: Text Rendering Hates You

#61

Post by bloopernova »

hsivonen wrote: post #26

If it weren't for Windows, we could move on from TrueType outlines (.ttf) to CFF outlines (.otf). .otf works nicely on non-Microsoft rasterizers. It was terrible on XP. Now on Windows 10 it’s less terrible, but .otf fonts on Windows 10 using DirectWrite look bolder and blurrier than using FreeType, Apple, or Adobe rasterizers. If Microsoft adopted the Mac font rendering aesthetic and fixed their CFF rasterizer, we wo…

That's the difference between ttf and otf? And that's why certain fonts look slightly different between platforms!

This is a serious revelation to me. Thank you. I've been having to switch between my Mac laptop, Linux workstation, Windows 10 workstation, and Windows 10 Amazon Workspace a lot. It's been frustrating seeing the small differences but being unable to really figure out what was going on.

Re: Text Rendering Hates You

#62

Post by bloopernova »

seanmcdirmid wrote: post #21
frou_dh wrote: post #7

High-DPI (namely 200+ DPI, aka Retina) text rendering on desktop computers is one of the more impactful hardware developments for programmers in a while. When you're looking at text all day every day, having every single glyph take a massive step up in fidelity (4x the pixel budget!) is not to be sneezed at.

This for sure. I love my iMac 27” 5k simply because how text looks on it so much better than even a 28” 4K. 220 DPI is a magical number

Interesting, my main screen is 160dpi@27", and I would love to try something at 300dpi@27". It's difficult to figure out how much of a difference a screen is going to make at 160 vs 220 vs 300dpi unless you sit down and just work for a few days.

Re: Text Rendering Hates You

#63

Post by ken »

leni536 wrote: post #36
z3t4 wrote: post #24

Earlier quoted context omitted.

With high density monitors on the rise we should get rid of LCD (RGB rainbows) anti alias as its really just a hack.

I strongly disagree, also the way the article describes subpixel antialiasing is not entirely accurate. The thing is the boundaries between pixels don't actually exist, it's just a convention so we can address individual pixels and subpixels within them. But these subpixels are not at the same position within the pixels and this needs to be taken into account for antialiasing. Also regarding hiDPI: I know that you ju…

It’s pretty much arbitrary what we as an industry have decided “text” means (and this has changed over the years), and what features it ought to support. It’s largely “what our technology easily supports today”.

For example, most people expect antialiasing (i.e., subsampling across space) but we seem to have written off the idea of motion blur (i.e., subsampling across time), except in some games.

It’s be technically more accurate to draw a quickly-dragged mouse cursor with a (correctly computed) blur, but that’s not generally easy to render today. And motion blur of moving subpixel antialiased text sounds like a nightmare right now, but with the right abstractions it might not be.

Re: Text Rendering Hates You

#64

Post by stefanfisk »

dictum wrote: post #37

> Mercifully, subpixel has become less relevant over the years: retina displays really don't need it, and the subpixel layout on phones, prevents the trick from working (without major work). On newer versions of macos, subpixel-aa of text is disabled at the OS level by default. Speaking of mercy, I wish Apple had disabled it only on hidpi displays and chosen a longer deprecation window for normal displays. I prefer k…

Have you tried `defaults write -g CGFontRenderingFontSmoothingDisabled -bool NO`? (also needs a reboot)

Re: Text Rendering Hates You

#65

Post by leni536 »

ken wrote: post #63
leni536 wrote: post #36

Earlier quoted context omitted.

I strongly disagree, also the way the article describes subpixel antialiasing is not entirely accurate. The thing is the boundaries between pixels don't actually exist, it's just a convention so we can address individual pixels and subpixels within them. But these subpixels are not at the same position within the pixels and this needs to be taken into account for antialiasing. Also regarding hiDPI: I know that you ju…

It’s pretty much arbitrary what we as an industry have decided “text” means (and this has changed over the years), and what features it ought to support. It’s largely “what our technology easily supports today”. For example, most people expect antialiasing (i.e., subsampling across space) but we seem to have written off the idea of motion blur (i.e., subsampling across time), except in some games. It’s be technically…

Motion blur is only "accurate" if you assume that the viewer's eyeballs remain still and don't follow the moving object. Having said that not blurring isn't accurate either on current LCDs when the viewer follows the object. This is what black frame insertion is meant to correct.

Re: Text Rendering Hates You

#66

Post by amelius »

pekim wrote: post #29
amelius wrote: post #9

It seems that the term "subpixel" is overloaded. In one meaning the term refers to the RGB parts. In another meaning the result looks different when the text is shifted by less than a pixel, even on a monochrome screen.

In the first case, I believe that it's normally referred to as "subpixel antialiasing". And in the second case, "subpixel positioning".

Yes, good point, but what would you call it if you'd apply both concepts at the same time?

Re: Text Rendering Hates You

#67

Post by zamadatix »

otterley wrote: post #56
thrower123 wrote: post #44

Earlier quoted context omitted.

Someday, 90% of people won't be running Windows... It's been said for decades now, but it might happen some day.

If we consider smartphone browsers, that time has already come to pass!

Half sure, 90% no.

Re: Text Rendering Hates You

#68

Post by vardump »

z3t4 wrote: post #24
leni536 wrote: post #2

Another pain point on text AA: Many renderers mix up colorspaces on antialiasing. For example freetype assumes a linear colorspace when calculating the antialiased bitmap but AFAIK both GTK and QT apply it directly on sRGB without any adjusting. The result is apparently thickened fonts when displayed black on white and thinned fonts when displayed white on black. Edit: Some background can be read on [0]. [0] https://…

With high density monitors on the rise we should get rid of LCD (RGB rainbows) anti alias as its really just a hack.

Addressing subpixels according to their spatial location is no way a hack.

Re: Text Rendering Hates You

#69

Post by pcwalton »

commandlinefan wrote: post #47

It seems like you’d need to read at least a few dozen languages fluently to be able to meaningfully reason about some of these issues. I can’t imagine what sort of educational background experts on rendering would have.

I've been doing text rendering professionally for a few years now and I wouldn't consider myself fluent in anything other than English and maybe German (I'm a bit rusty in the latter). I can also speak some Japanese, but, other than that, that's it. The rest of my knowledge is a smattering of weird details about various languages that are useful for writing text renderers but terribly unhelpful for actually understanding the languages.

Re: Text Rendering Hates You

#70

Post by jfk13 »

_fbpt wrote: post #23
sings wrote: post #19

> Synthetic bold: paint every glyph multiple times with a slight offset in your text-direction. Designers forgetting to include a bold version of their web fonts is one of my biggest bug bears. It always stands out, especially on Safari on iOS as you zoom in and out.

I think Chrome (PC/Android) implements synthetic bold by expanding the glyph outline, then drawing it with subpixel off. It's prettier than Firefox's "horizontal-only extrusion", but sometimes leads to funny artifacts at sharp corners.

How Firefox implements synthetic-bold varies across different platforms, actually, depending on the features of the (platform-specific) font rendering backend it's using. It uses the paint-multiple-times-with-a-small-offset approach when the font backend doesn't seem to offer a "better" synthetic-bold option.
Post reply on HN