4 ms·

I ran across this article today while looking for information on PPI Awareness of web browsers. In particular, I'm looking at Hyper, an Electron-based terminal,

I ran across this article today while looking for information on PPI Awareness of web browsers. In particular, I'm looking at Hyper, an Electron-based terminal, and how I might be able to get the same type size from monitor to monitor. As web applications and high-DPI monitors become more common, I can see more practial need for a measurement which is truly resolution-independent. I believe points really should have been this measurement, but were co-opted early on with Windows and Macintosh specifying a specific PPI (96ppi and 72ppi respectively) as a function of the OS as opposed to what the monitor actually reported. Can we fix how points are handled, or do we need to go to mm or some other measurement at this point?

Bromskloss 9y ago
> Can we fix how points are handled, or do we need to go to mm or some other measurement at this point? I'd be happy to go with the millimetre anyway. It seems to me that the cleanest way to look at the _point_ is as simply a unit of length, satisfying, in its modern "desktop publishing point" incarnation, 1 pt = 0.3528 mm = 0.01389 inches. From that perspective, any unit is as good as any other, and I would personally use the millimetre. Using anything other than the point might even be preferable, if it removes some uncertainty about how it should be interpreted.
zokier 9y ago
> I believe points really should have been this measurement, but were co-opted early on with Windows and Macintosh specifying a specific PPI (96ppi and 72ppi respectively) as a function of the OS as opposed to what the monitor actually reported. > Can we fix how points are handled, or do we need to go to mm or some other measurement at this point? Points and millimeters are handled identically on all systems I know of. Point is not really any special unit, it is just 1/72 inches. As for the overall theme of the article, at least at some point Firefox was perfectly able to do completely resolution independent rendering, realizing the authors wish that 12pt should be 12pt. I haven't really followed the situation lately, but I wouldn't expect the situation to be significantly worse these days.
- xelxebar 9y ago
  One problem with mm as a unit for type is that it's not immediately obvious what we're measuring the length of. The point specifically refers to the maximum height of the minuscule 'm' or something like that. Then with things like antialasing and hinting, the intrinsic size of a font ends up both physically and psychologically a different size. I'm not yet convinced the problem is as clean and obvious as it seems at first glance.
  - couchand 9y ago
    Well generally typeface size is measured from the top of a capital letter (cap height) to the lowest point of the descenders, regardless of the units used for measurement. And you don't even have to get to antialiasing and hinting to see issues with perceptual typeface size... Look across faces and you'll see wild differences in cap height, ascenders, and descenders relative to the x-height.
kps 9y ago
X11 allowed resolution independence (run 'xdpyinfo | grep dimensions' and the report includes the physical size, which will almost certainly be wrong) and in the days of pixel fonts shipped with two sets, for 75dpi and 100dpi, corresponding to the two common display densities of the time. The ‘free desktops’ could have built on this when vector fonts took over, but ignored it in their zeal to imitate Windows.
- vetinari 9y ago
  > but ignored it in their zeal to imitate Windows. You are letting your zeal affect your judgement. Of course the free desktops did explore the resolution issue. They came to similar result that the proprietary counterparts did, namely that: 1) hardware lies about it capabilities. There are entire product lines that use the same EDIDs. For manufacturers, that it simpler to just copy an existing ROM for a new product, that to bother with customizing. Customers do not care anyway. 2) hardware may have no knowledge at all, what the pixel density is. How do you imagine, that a projector measures and reports it's density? In the case of a projector, it might even change mid-flight, with the intent to change the entire size of the picture, not it's sharpness. 3) meanwhile, there were practical concerns with software. What kind of bitmap assets are you going to recommend to developers to prepare? They won't ship for the entire continuum of densities. That's why Apple approach was practical - just ship two or three.
  - kps 9y ago
    This predated EDID, and digital displays generally. The point was that Gnome & KDE actually regressed from base X11 and painted themselves into a 100dpi corner. Technologically, scaling for physical display resolution and scaling for legibility are substantially the same; done right, either would enable the other.
endergen 9y ago
I started messing with getting the real pixels per inch in electron here, maybe this project helps? It's not ready for primetime except on macOS. https://github.com/francoislaberge/lifesized https://github.com/francoislaberge/lifesized

Bromskloss 9y ago

> Can we fix how points are handled, or do we need to go to mm or some other measurement at this point? I'd be happy to go with the millimetre anyway. It seems to me that the cleanest way to look at the _point_ is as simply a unit of length, satisfying, in its modern "desktop publishing point" incarnation, 1 pt = 0.3528 mm = 0.01389 inches. From that perspective, any unit is as good as any other, and I would personally use the millimetre. Using anything other than the point might even be preferable, if it removes some uncertainty about how it should be interpreted.

zokier 9y ago

> I believe points really should have been this measurement, but were co-opted early on with Windows and Macintosh specifying a specific PPI (96ppi and 72ppi respectively) as a function of the OS as opposed to what the monitor actually reported. > Can we fix how points are handled, or do we need to go to mm or some other measurement at this point? Points and millimeters are handled identically on all systems I know of. Point is not really any special unit, it is just 1/72 inches. As for the overall theme of the article, at least at some point Firefox was perfectly able to do completely resolution independent rendering, realizing the authors wish that 12pt should be 12pt. I haven't really followed the situation lately, but I wouldn't expect the situation to be significantly worse these days.

xelxebar 9y ago
One problem with mm as a unit for type is that it's not immediately obvious what we're measuring the length of. The point specifically refers to the maximum height of the minuscule 'm' or something like that. Then with things like antialasing and hinting, the intrinsic size of a font ends up both physically and psychologically a different size. I'm not yet convinced the problem is as clean and obvious as it seems at first glance.
- couchand 9y ago
  Well generally typeface size is measured from the top of a capital letter (cap height) to the lowest point of the descenders, regardless of the units used for measurement. And you don't even have to get to antialiasing and hinting to see issues with perceptual typeface size... Look across faces and you'll see wild differences in cap height, ascenders, and descenders relative to the x-height.

kps 9y ago

X11 allowed resolution independence (run 'xdpyinfo | grep dimensions' and the report includes the physical size, which will almost certainly be wrong) and in the days of pixel fonts shipped with two sets, for 75dpi and 100dpi, corresponding to the two common display densities of the time. The ‘free desktops’ could have built on this when vector fonts took over, but ignored it in their zeal to imitate Windows.

vetinari 9y ago
> but ignored it in their zeal to imitate Windows. You are letting your zeal affect your judgement. Of course the free desktops did explore the resolution issue. They came to similar result that the proprietary counterparts did, namely that: 1) hardware lies about it capabilities. There are entire product lines that use the same EDIDs. For manufacturers, that it simpler to just copy an existing ROM for a new product, that to bother with customizing. Customers do not care anyway. 2) hardware may have no knowledge at all, what the pixel density is. How do you imagine, that a projector measures and reports it's density? In the case of a projector, it might even change mid-flight, with the intent to change the entire size of the picture, not it's sharpness. 3) meanwhile, there were practical concerns with software. What kind of bitmap assets are you going to recommend to developers to prepare? They won't ship for the entire continuum of densities. That's why Apple approach was practical - just ship two or three.
- kps 9y ago
  This predated EDID, and digital displays generally. The point was that Gnome & KDE actually regressed from base X11 and painted themselves into a 100dpi corner. Technologically, scaling for physical display resolution and scaling for legibility are substantially the same; done right, either would enable the other.

endergen 9y ago

I started messing with getting the real pixels per inch in electron here, maybe this project helps? It's not ready for primetime except on macOS. https://github.com/francoislaberge/lifesized https://github.com/francoislaberge/lifesized