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

The sad state of font rendering on Linux (2018)

pandasauce.org

Post reply on HN
Print view View original

91–100 of 104 posts

Re: The sad state of font rendering on Linux (2018)

#91

Post by 6yyyyyy »

bradfitz wrote: post #88
sunnyps wrote: post #32

Earlier quoted context omitted.

So you haven't used a 32 inch 4K monitor which is ~135 ppi? What do you get at that size, a 5K or 6K monitor? Not many of those available and they have specific requirements like higher display port or thunderbolt bandwidth. There's also an entire world of users still on 720p and 1080p displays. They deserve better font rendering even if it doesn't affect us personally.

I haven't. I have 5K and 6K monitors. That's indeed privileged, but only for a bit until that's soon commonplace and cheap. So this all sounds like a very temporary problem at this point for something so subjective. Every time this topic comes up it's the same "but I like the look of $OS rendering the best" comments.

High PPI screens have been around for 10 years or so, and they still cost about twice as much as a standard PPI screen the same size.

Put yourself in the shoes of the average computer purchaser: Would you rather buy a high PPI monitor, or two standard PPI monitors? To me this is a no-brainer.

Re: The sad state of font rendering on Linux (2018)

#92

Post by jchw »

zajio1am wrote: post #90
jchw wrote: post #22

Earlier quoted context omitted.

See the jump from 17pt to 18pt? That's wrong. (Also, the small sizes are just completely obliterated IMO.) Font outlines are scalable; they should have the same relative weight no matter what pt/px size you render them at, and they should have the same proportions. Non-scalable rendering is incorrect (although techniques like hinting and gridfitting do intentionally sacrifice scalability for better legibility, but I…

Rendering of vector fonts to fixed grid of pixels leads to incorrect results in principle. Introducing blur where there is a sharp edge in vector data is also a wrong result. You can just choose which kind of wrongs is more annoying - whether distortion due to grid-fitting or blur due to naive rendering and antialiasing.

There is no objectively "best" way to render vector typefaces to a raster, but that's not because all of the options are equally correct, it's because options that are more accurate to a font might look subjectively worse. There's nothing "incorrect" that a raster rendering of a shape can't convey the signal with perfect fidelity, but that doesn't mean that all rendering of vectors to raster is equally correct.

Like fine, let's put aside somewhat intentional things like hinting and grid-fitting with accumulating error for a minute. Some FreeType configurations dramatically fuck up the visual weight of fonts, making the regular style in a type face look fairly bold. The damn font looks wrong. It's not "wrong" as in I disagree with what the designers intended for the type face, it's wrong as in it looks nothing like the designers intended and it looks nothing like the parameters you put in to render the font. There is basically no perspective where this output is desired, it's just a bad rendering.

There's definitely a bit of subjectivity in exactly where to draw the line, but there is definitely still a line you can cross that just goes into blatantly wrong territory. The relative visual weight of a glyph is not supposed to be influenced by its size on screen.

Re: The sad state of font rendering on Linux (2018)

#94

Post by adrian_b »

not_a_bot_4sho wrote: post #27
scblock wrote: post #7

Windows has the worst font rendering of all modern operating systems. Wanting anything like Windows font rendering is insane. Windows 10 makes it near impossible to properly turn off subpixel hinting without also turning off all anti-aliasing, which on a QD-OLED screen makes for horrific color fringing. Windows 11 is better, but still pretty weak. Linux is roughly as good as Mac OS, both of which are miles better tha…

I suppose this is a subjective area. I would rank Windows on top, Mac as a close second, and Linux ... well, I love Linux for reasons other than UI.

While the font rendering method matters, the differences between operating systems are typically much smaller than the differences in quality between typefaces.

Linux had a very bad appearance in the past with a default configuration, and it still does not look good in most distributions, but that is not due to bad rendering algorithms, but it is due to the fact that the default free typefaces are usually not very good.

For several decades, the first thing that I have always done after installing Linux was to delete all default typefaces and replace them with some high-quality typefaces, most of which I have bought, with a couple taken from a Mac OS and a Windows that I had bought in the past (which I have stopped using many years ago, except for the few typefaces that I have kept from them).

Because of this policy, any text on my Linux computers has always looked much better than on any of the Windows or Mac OS computers that I have used at work.

Re: The sad state of font rendering on Linux (2018)

#95

Post by perching_aix »

nomel wrote: post #87
hnuser123456 wrote: post #71

Earlier quoted context omitted.

CRT resolution was moreso limited by GPUs than the monitor itself. They don't have fixed pixels like LCD/OLED.

> GPUs than the monitor itself. No, it was limited by the bandwidth of the beam driving system, which the manufactures, obviously, tried to maximize. This limit is what set the shadow mask and RGB sub pixels/strip widths. The electron beam couldn't make different color, different colored phosphor patches were used. But, since bandwidth is mostly resolution * refresh, you could trade between the two: more refresh, les…

Yeah, DDC and EDID were standardized in '94, and were widely available and working well by '98 - if you were on Windows at least, running fresh hardware.

> This monitor could do something like 75Hz at 800x600, and I think Assuming both modes were meant with 24-bit color ("true color"), that'd mean 17.36 Hz tops then for the FHD mode, ignoring video timing requirements. I don't think you were using that monitor at 17 Hz.

Even if you fell back to 16 bit color, that's still at most 26 Hz, which is miserable enough on a modern sample-and-hold style display, let alone on a strobed one from back in the day. And that is to say nothing of the mouse input feel.

Re: The sad state of font rendering on Linux (2018)

#96

Post by lostmsu »

carlosjobim wrote: post #83
forrestthewoods wrote: post #81

Earlier quoted context omitted.

4K @ 32” is not particularly high density. It’s waaaay lower density than a phone or MacBook.

Then buy a high pixel density screen if you want to have one. They're really good for working with text and other computing related stuff, and they're not expensive. Philips have a very good one at 27 inches.

> 27 inches

bwahaahaha, and you are talking about eye strain. Number one thing I do if I want to improve QoL for my eyes is getting a larger monitor so I could see more without looking like the last guy from the famous human evolution culminating in sitting in front of computer pic.

Re: The sad state of font rendering on Linux (2018)

#97

Post by hagbard_c »

nomel wrote: post #50
vouaobrasil wrote: post #35

Earlier quoted context omitted.

On the other hand, subpixel rendering is absent from MacOS and makes it very difficult to using regular ol' 1920x1080 screens with modern MacOS. Yes, those Retina displays look nice, but it's a shame that lower res screens do not because they work perfectly fine except for the font rendering.

My first (and last) 1920x1080 monitor was 50lb CRT I picked up on the side of the road, in 2003. I haven't owned a smartphone with a screen resolution that low, in over 10 years. I think it's an amazing feat of marketing, by display companies, that people still put up with such low resolutions.

> I think it's an amazing feat of marketing, by display companies, that people still put up with such low resolutions.

Stereo audio is still fine even though 5.1 exists

300 dpi printers are still useable even though 2400 dpi printers exist

double-glass windows are still fine even though triple-glass windows exist

2-wheel drive cars are still fine even though 4-wheel drive cars exist

Just because something new appears on the market that new thing does not need to take over from all predecessors when those predecessors are good enough for the intended purpose, especially not when the new thing comes with its costs - power use and higher demands on GPUs in case of display with higher resolutions than really needed.

Re: The sad state of font rendering on Linux (2018)

#98

Post by nomel »

hagbard_c wrote: post #97
nomel wrote: post #50

Earlier quoted context omitted.

My first (and last) 1920x1080 monitor was 50lb CRT I picked up on the side of the road, in 2003. I haven't owned a smartphone with a screen resolution that low, in over 10 years. I think it's an amazing feat of marketing, by display companies, that people still put up with such low resolutions.

> I think it's an amazing feat of marketing, by display companies, that people still put up with such low resolutions. Stereo audio is still fine even though 5.1 exists 300 dpi printers are still useable even though 2400 dpi printers exist double-glass windows are still fine even though triple-glass windows exist 2-wheel drive cars are still fine even though 4-wheel drive cars exist Just because something new appears…

And feet are fine, even though shoes exist.

Fire is fine, even though ovens exist.

We're animals, that are perfectly fine living naked in the wild (some still do today). It's all complete excess. Feel free to abandon the progression of tech, but, I challenge you to use a modern panel for a couple months, then try to go back to 1080p. It's like the console players who claimed 30fps was serviceable, fine. Sure, but nobody wants to go back to 30fps after they've used 60hz, or 144hz, for a non-negligible amount of time.

I also use a 1080p from time to time, it's servicable, but it's not comfortable, and it provides a far far inferior experience.

Re: The sad state of font rendering on Linux (2018)

#99

Post by [deleted] »

perching_aix wrote: post #95
nomel wrote: post #87

Earlier quoted context omitted.

> GPUs than the monitor itself. No, it was limited by the bandwidth of the beam driving system, which the manufactures, obviously, tried to maximize. This limit is what set the shadow mask and RGB sub pixels/strip widths. The electron beam couldn't make different color, different colored phosphor patches were used. But, since bandwidth is mostly resolution * refresh, you could trade between the two: more refresh, les…

Yeah, DDC and EDID were standardized in '94, and were widely available and working well by '98 - if you were on Windows at least, running fresh hardware. > This monitor could do something like 75Hz at 800x600, and I think Assuming both modes were meant with 24-bit color ("true color"), that'd mean 17.36 Hz tops then for the FHD mode, ignoring video timing requirements. I don't think you were using that monitor at 17…

[deleted]

Re: The sad state of font rendering on Linux (2018)

#100

Post by LargoLasskhyfv »

hnuser123456 wrote: post #70
lttlrck wrote: post #57

Earlier quoted context omitted.

It's still a perfectly serviceable resolution. Of course 16:19 pushed down display costs leading to the demise of 1920x1200 which is unforgivable ;-) Those 120 pixels were sorely missed.

You can still get 16:10, they're just classed as "business professional" models with matching price tag.

Buy them refurbished instead, then.
Post reply on HN