Live data from Hacker News

Death to px, long live ch

shkspr.mobi

41–50 of 86 posts

Re: Death to px, long live ch

#41
post #25

Earlier quoted context omitted.

what the spec says doesn't really matter though, the spec is just nonsense people wrote down to try to back-explain decisions that the browsers had already made. pixels are pixels, and no browser implements them as a fractional-inch measurement. in every actual implementation i'm aware of, they're a hardware based unit.

They aren't hardware based. As I say in the first link, pixels mostly don't exist in hardware. Screens very rarely contain a matrix of individual squares. For example - https://global.samsungdisplay.com/29043/

Pixels very much exist in hardware outside mobile. Microsoft’s clear type even exploited the specific layout of color channels in discrete hardware pixels. Mobile displays are all over the place, but most other displays use standard RGB layouts.

Re: Death to px, long live ch

#42

What happened to em?

That's what I wondered. I found the spec*. I'd vaguely thought that 1em was the width of "M" but apparently it's just the font-size, and the connection between font-size and the actual size of the text is very font dependent. So 1ch is defined to be the advance width of "0" (zero), so it's actually telling you something about the current font. * https://www.w3.org/TR/css-values-4/#font-relative-lengths

I know this is an irrelevant factoid and literally does not matter at all, but it's a tad more meta that just em = font size. Prepare to be bored:

The em unit/point size in typography was based on the height of the lead sorts you were using. [0] (A sort is basically a little lead stamp with a single letter jutting out on the front face. [1]) Its almost always larger that any dimenion of the actual character, since the sorts are just clamped together when doing the actual typesetting, so you want a gapless grid of lead to keep everything in place. [2] You couldn't have any spacing between letters/lines if the castings themselves were only as tall or wide as the character.

That meant the em height was a real physicial thing you could measure with a ruler, commonly in points, where 1/72 of an inch = 1 point. When you ordered typefaces from foundaries, you'd specify what point size you wanted, so all of your large-point headings would line up in one slug, which you'd clamp above another slug of body copy text all sized to a smaller point size. That tied an em to both the size of text, but only in the context of 1 font family. You could leave the em size the same and cast a glyph larger on the same size of sort, changing the baseline, line-height/ledding and letter-spacing/tracking. Now it doesn't line up with your other font faces with the same em size, even if they clamp together just fine.

But in modern typesetting, you don't have a physicial em-height lead block to deal with. Internally, the font uses it's own unitless values to describe both the vector shape of the glyphs, as well as units like the line height, letter spacing, and em height. It's no longer a "real" measurement you could actually measure. It's a relative one that acts like the unit value when scaling fonts. [3] If you render a font at 12pt, the text rendering scales the relative em unit until it would be 12pt or 1/6in, and then apply that scaling factor to all glyphs.

That means, digital fonts are emulating the same weird use for ems as a proxy for both the size of the glyphs AND the size of the lines/spaces between characters. If you shrink the internal em unit inside a font file, the size of glyphs increase, but so will the line height/letter spacing and other font metrics.

So... all of that together, yep the em unit is 100% dependant on the font's own settings, but it's not the font size itself. It's a sort of base-unit for everything else in the font, where 1em is defined as being a certain height in the internal font domain AND being the height of whatever the font renderer says the point size is. If you halve the em height and double the point size, you end up with exactly the same raster ouput. It also means you can't look at the screen and find any part of the letters/lines that is precisely 1em, like you could for simplier glyph-size-based unit like 1ex or 1ch. (Unless there's an em-dash... but even then, making the em-dash exactly 1em long is just convention.)

[0] https://www.thomasphinney.com/2011/03/point-size/#:~:text=ou...

[1] https://en.wikipedia.org/wiki/Sort_(typesetting)

[2] https://commons.wikimedia.org/wiki/File:Sorts_on_composing_s...

[3] https://www.thomasphinney.com/2011/03/point-size/#:~:text=Ty...

Re: Death to px, long live ch

#43
post #25

Earlier quoted context omitted.

They aren't hardware based. As I say in the first link, pixels mostly don't exist in hardware. Screens very rarely contain a matrix of individual squares. For example - https://global.samsungdisplay.com/29043/

Pixels very much exist in hardware outside mobile. Microsoft’s clear type even exploited the specific layout of color channels in discrete hardware pixels. Mobile displays are all over the place, but most other displays use standard RGB layouts.

You've described the exact problem. Sub pixel rendering exploits the fact that most display pixels aren't discrete logical squares.

https://en.wikipedia.org/wiki/Subpixel_rendering

Re: Death to px, long live ch

#44
post #43

Earlier quoted context omitted.

Pixels very much exist in hardware outside mobile. Microsoft’s clear type even exploited the specific layout of color channels in discrete hardware pixels. Mobile displays are all over the place, but most other displays use standard RGB layouts.

You've described the exact problem. Sub pixel rendering exploits the fact that most display pixels aren't discrete logical squares. https://en.wikipedia.org/wiki/Subpixel_rendering

Right, but there's still an addressable set of display units that convert an RGB signal to actual glowing lights, right?

It seems like defining px to be perceptual is one of those compatibility hacks that probably helped a ton back in the day, but we have perceptual units and now we're stuck with that baggage.

I don't have much of an opinion on this (I use em) but it has taken me by surprise a few times.

Re: Death to px, long live ch

#46
post #10

What I want to know is who decided to break px, the last thing we need is yet another screwball physical measurement, css was already full of them. But what "tut tut, everybody is using px and these new hi-dpi displays are rendering things really tiny, we can't have that" and now px as a useful unit is ruined. Is there a way to use real pixels? My, admittedly quick, search says no. at least nothing jumps out at me fr…

px is still a useful unit. the user's operating system applying a scaling fator doesn't make it not useful. if the user's operating system is configured to draw pixels at a 1:1 ratio, your pixels will be drawn at a 1:1 ratio. if the user's operating system is configured to draw pixels at a 2:1 or 3:1 ratio, you as a web developer don't get to override that, but you're still addressing pixels directly. if you want to…

[deleted]

Re: Death to px, long live ch

#48
The article links to

https://shkspr.mobi/blog/2018/11/the-myth-of-the-pixel-perfe...

which confuses me, because I definitely remember pixels being visible when I was growing up. I remember the first time I got a 1080p monitor. I felt a visceral terror at the fact that I could no longer see the pixels.

Re: Death to px, long live ch

#49
post #27

I'm still waiting for operating systems to adopt true physical units. You know, that trick PostScript printers have doing since the 80s (running at 300dpi no less). I realize there are large screen projectors in the wild, that's solvable problem. Bitmaps icons are also an issue, but again, solvable.

Real physical units make sense when you're printing on paper.

I don't see how they make sense on screens. A one square inch image is fairly large on my phone, not too big on my desktop monitor, and pretty darn small on my tv. That's not to say that pixels make sense to use for layout at those scales either, but before everybody got into high dpi with scaling, it kind of worked... If you were comfortable with tiny text, you ran a higher resolution and if you needed things big, you ran a lower resolution.

Re: Death to px, long live ch

#50
post #8

I also did some experiment with ch many years ago. I found that 60ch is ideal width for block text for easy reading. too bad it is pretty hard to make websites with only 60ch wide.

Why's it hard? I just tested it by applying 60ch width to TFA. It hardly changed, it was already not much wider than that.

This website layout (tall brick surrounded by voids) was very popular in the 2000s.

Post reply on HN