13 ms·

A 12pt Font Should Be the Same Size Everywhere (2012)

290 points by bshacklett 9y ago

bshacklett 9y ago
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
jenkstom 9y ago
Spoken like someone who doesn't have to wear reading glasses. Us old folks will be fighting this one. ;-)
- rocqua 9y ago
  Let the user specify a zoom factor, but then 12pt text zoomed by a factor X is the same on every display. There is some issue with how this should interact with certain things (like touch distance). Should two buttons that are 2cm apart be 4cm or 2cm apart after scaling by a factor of two? There is a fringe case of a display-based ruler, that essentially shouldn't zoom.
  - mark-r 9y ago
    Ideally you'd want 2 zoom factors, one for visuals and one for touch. But then you'd potentially have buttons that couldn't hold their labels anymore. I think one zoom factor should be sufficient. Given that we can't support actual-size rulers today, I think we've demonstrated that we can live without them. P.S. for low resolution displays it's obvious that clear text and graphics is more important than absolute size.
- jlarocco 9y ago
  A "point" is a unit of measure. If a person wants to zoom in or out, it's up to them, but by definition a point is 1/72 of an inch. We don't change the definition of a mile based on the type of vehicle travelling it, and we shouldn't change the definition of a point based on the type of display viewing it.
  - hinkley 9y ago
    You don't hang out with any sailors or fishermen, do you...
    - javajosh 9y ago
      lol yeah i was about to point out nautical miles and knots, but you beat me to it.
Laylo_ 9y ago
Man, writing for Jumbotrons is going to suck...
- Bromskloss 9y ago
  How so? Do you mean that we should specify sizes normalised to the viewing distance instead of in absolute terms?
  - zokier 9y ago
    See also CSS pixels, which are one of the weirdest units around.
arximboldi 9y ago
I have mixed feelings about this. I get the point about touch: i.e. the button should have a fixed size in proportion to your finger. However in other scenarios I am not sure size should be constant. In most cases, you have to factor in the distance to the viewer. This is, probably "projection angle in the retina" is a more useful invariant. For example, in a big TV that is far from you, you want things to be bigger than in a monitor, that is closer. And in a laptop, you probably want it even smaller. "Design by pixel" takes this into account somewhat indirectly because most display are designed to have their pixel density in inverse proportion to the size of the display, which is also inversely correlated to the expected usage distance. Sometimes technology changes our expectations of definitions and things become small, until designs catch up with the new expected pixel density. We have worked around this problem with pixel density factors on retina/QHD. I agree that all this in the is a evolutionary "hack". But I am not sure that the proposed solution, even though more rational sounding, actually makes things better.
- colechristensen 9y ago
  An inch should be an inch. A pixel should be a pixel. A point should be a point which is defined as 1/72 inch. Those are all physical measurements, meant for the surface of the screen. If you design with them, it means you're designing with the screen size in mind. It's often wrong to design with those measurements. There are relative sizes too. %, em (current size of font), and measurements relative to viewports. That's what designers use very often.
  - protonfish 9y ago
    So you are saying you would want one physical square inch on a phone to be the exact same size one square inch on a projector screen? I have been designing and building interfaces for a couple decades and I have been down the "relative size" path and learned not to do that the hard way. There lies nothing but tears. Sizing to pixels, for some reason, results in the most predictable and consistent appearances.
    - zlynx 9y ago
rocqua 9y ago
What is the interaction with zooming? You can't just deny zooming. Users want it, and if you disable it, someone will still monkey-patch it in. A first-order solution is to have 'zooming' be pure scaling. Essentially, instead of ISO defining a milimetre, the user defines it, and it defaults to the ISO definition. This essentially means the system has to handle a screen-size that could change at any given time. Unless you are willing to accept interpolation. But then, what happens when real-distance starts to matter. A stupid example is a ruler app, that obviously breaks upon scaling. Generally, any app that depends on `real hardware' interacting with the screen, this is going to be an issue. Specifically, this is an issue for touch screens. Even more so because 'human hands' are `real hardware'. If two buttons are rendered 2cm apart, and the user scales by a factor of 2x, that would put the buttons 4cm apart. That might be too much of a spread to use comfortably. In general, does it really make sense to treat a 14" screen scaled at 2x as a 7" screen? What about a 15" screen scaled at 3x? If you accept the above as a problem, there are many solutions, but they are either a lot of work, or require 'monkey patching'. Sadly, this means the quote "Resolution independent graphics is a solved problem." not quite right. At least insofar as any chosen system will have trade-offs between ease of development and ease of use. Taking a pessimistic view: Those trade-offs will inevitably fall towards development on occasion, which will train users to think this is stupid anyway. Thus developers get less benefit, and we will see weird monkey patching to attempt to fix this. Maybe at some point, someone walks in and declares "this is a mess, it should have been done right from the start".
- xelxebar 9y ago
  Yeah. These accessibility vs. design issues were what immediately came to me mind to. Though, as simply another tool in the bag, accurate real-world sizing capability seems like it could be used too actually help those issues. Would like to hear more from designers that on the issues and challenges of creating accessible designs.
  - oatmealsnap 9y ago
    It is a best practice (and required by certain WCAG 2.0 guidelines) to allow users to adjust the text size to meet their needs. The 2.1 AA guideline says that websites must scale up to 400% and still be usable. In CSS, I almost entirely use relative units so that I don't need to worry about how things will scale. If the user wants/needs their text to be larger, they will also want/need [any other element] to be larger, as well. Of course, if you let your buttons scale as much as your text does, you can end up with buttons taking up the entire screen. I typically solve that by using max-sizing on an element, rather than using `in` or `cm`...I can't recall ever using physical units in web design.
ZenPsycho 9y ago
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.
taylorbuley 9y ago
Original discussion when submitted by author: https://news.ycombinator.com/item?id=4236429 https://news.ycombinator.com/item?id=4236429
kccqzy 9y ago
The best size is dependent on the distance between the eye and the content. You would use letters less than 10mm on a smartphone screen but you could very well use an inch or more on a big TV screen. As a designer you have no idea whether your web page will be displayed on a tiny screen of a low-end smartphone or a big TV.
- thomastjeffery 9y ago
  A user can scale point sizes to her/his liking. That still means that point sizes should be consistently scaled.
deleted 9y ago
[deleted]
sds111 9y ago
Bill Gates made this same promise when Windows 1 was released. That each monitor and printer would require drivers specific to their model in order that the fonts would be measures in points (or pica) instead of in pixels. Somehow we ended up with all the drivers for each device even though the original promise has been long forgotten. We sacrificed the days of the plain printer with Centronix hardware interface, and the versatility of the Unix lpr spooler where you simply sent a stream out to printers containing control codes you knew would work with your device, like carriage return and linefeed. Then later the Calcomp and HPGL codes. And what did we gain for that trade? I think this link is great, because someone is clearly remembering the promise. Upvote for that.
crazygringo 9y ago
We should standardize on something, but it shouldn't be inches. You might be looking at a phone screen a foot away, or a monitor two feet away, or a TV four feet away, or a projection 10 feet away, or a jumbo display 100 feet away. How does measuring in inches help? Answer: it doesn't at all. Measuring in points used to be a good system, back on the Mac in the old days. The user interface was in 12 pt Chicago, new Word documents defaulted to 12 pt Times New Roman -- 12 pt was the baseline for normal body text both for interface and for content, and everything else made sense relative to that. Then what happened? For some reason, web browsers defaulted to 16 pt. So the text on web pages was too big. Then, laptop screens started packing more pixels in (this is pre-retina) to advertise higher resolutions, and OS interface text became physically smaller -- really hard to read. 16 pt webpages were actually OK though, so now that kind of made sense. Strangely, at the same time, interface text got even smaller -- look at the tiny text OSX now uses in a lot of dialog settings, or the small size Chrome uses for tab titles. (Menus and buttons are usually still OK.) And then bloggers wanted to make webpages easier to read, so they started doing things like 18 pt text (e.g. Medium) and sometimes you see 20 pt or even 22 pt. So now, each letter on Medium takes up about three times the area of a letter in the title of the tab I have open on Chrome. Scale on computer screens no longer makes any sense, and you have to constantly use some combination of monitor resolution and browser zoom to keep all the elements of your screen in any kind of reasonable proportion. So my humble suggestion is: can't we just go back to where 12 pt meant normal computer screen UI text and body text, and everybody stick to that? Forget that points are based on inches, just make everything relative to 12 pts = body text. Then everyone can pick a resolution or zoom level for each device so it's legible for your eyes at your distance... but then everything stays in proportion!
- deathanatos 9y ago
  I've argued in the past[1] (and there were a few good comments in that thread, in response) that most UI elements should be measured in arcdegrees they should consume in the field of view of the user. That is, how large should this text appear, not how big should it be physically rendered, either in pixels or inches. (So some derived unit, like pt.) As I stated in that thread, the display device would need some concept of its own dimensions (easy) and its intended viewing distance (harder, and would probably need to be configurable). The one commenter in that thread notes, I think rightly, that, > once you get to very small screens like phones, there is a tradeoff between keeping font and UI sizes comfortable, and being able to actually fit enough content on the screen without endless scrolling. I am willing to strain my eyes with smaller font sizes on my phone than on my laptop, just so that I can see more than 5 sentences of text at the same time. I think is particularly applies as blog fonts get larger and larger. > web browsers defaulted to 16 pt Are you sure? I don't ever remember this being the case; it's always been 12pt (usually a serif font, often Times New Roman). Are you sure you're not mixing that up w/ 16px (which I believe in CSS, 12pt == 16px)? [1]: https://news.ycombinator.com/item?id=14002821 https://news.ycombinator.com/item?id=14002821
throwaway613834 9y ago
Apparently I'm not the first person to say this, but why not use angles (e.g. arcseconds) instead of length?
- deathanatos 9y ago
  A small, previous discussion of this suggestion[1]. (And I completely agree, for most use cases.) [1]: https://news.ycombinator.com/item?id=14002821 https://news.ycombinator.com/item?id=14002821
Doffity 9y ago
One physical square inch on your phone should be the exact same size as one square inch on a projector screen, is that really what you're saying?
- bshacklett 9y ago
  I believe @recursive put it very well: > If they're not the same, then they're not inches. I'm not saying that UI elements should necessarily be the same size, but the option should be available. Having a point be equal from display to display doesn't mean that relative scaling isn't impossible; it just means that you need to use different units for those cases (which is probably most of the time). Points really aren't all that useful on computer monitors at present; you're better off using EMs, percentage or possibly pixels depending on what your goal is. This leaves a gap, however, when it actually is advantageous to know for certain what size a UI element will be at display-time.
jancsika 9y ago
Let's back up a little and talk about pixel sizes: Suppose I render "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" in DejaVu Sans Mono with a normal font-weight: once at size "12px", and then again at "11.65px". (Note: those are pixel sizes, not point sizes.) Assume that string is all a single non-wrapping line and rendered to an HTML5 canvas using a web browser, and that I have loaded some known version of my font using the "@font-face" syntax in CSS. What should the width be in each case when I measure using the "measureText" method? If a given platform's font stack renders that string substantially wider-- say, 7 pixels wider-- than every other platform (all of which return a values within half a pixel of each other), is that a bug? If so, is there a specification somewhere that requires a platform's font stack to produce a pixel-sized result for a pixel-sized font within some threshold? Or are font stack devs within their rights to justify whatever the metrics are based on other aesthetic or perceptual qualities of their renderer?
- iainmerrick 9y ago
  That happens all the time, and unfortunately it isn't regarded as a bug. There's no specification or agreement that requires font renderers to match up. Font rendering used to be all about bitmaps, then as TrueType matured it was all about aggressively hinting (and auto-hinting) to fit the pixel grid, and we haven't fully gotten away from that. Of all the main OSes, I think OS X and iOS do the least hinting, but I don't know if they do no hinting; and many people dislike the blurry text on OS X. (I don't see any complaints about blurriness on iOS, though, where you always have really high screen resolution now.) It would be technically feasible for all font renderers to product identical output (or at least to provide such an option) but nobody seems to care enough to push for it.
  - jancsika 9y ago
    tl;dr - without a spec nothing will ever change Thanks for the reply-- it's what I gathered from doing a little digging into extant font stacks but wasn't sure if I had skipped over an obscure specification somewhere. So here's the deal-- maybe a year ago, I tested Windows, OSX, and old-school GNU (via Ubuntu 14.04) and got font metric results within a half a pixel of each other for the test I outlined above. New-school GNU, however, was about 7 pixels wider. Again, this was for the same version of a mono-spaced font, loaded from the same font file shipped with my test program. I also got reports from users of other GNU/Linux distros about the discrepancy-- these were distros that also used the newer GNU font stack. Since that time I've seen reports about this discrepancy affecting other software. One final data point-- I also noticed that the newer GNU font stack seems to quantize pixel sizes that aren't whole numbers. For example, assume size "11.3px" generates a particular output. Then "11.33px" would generate the same output, and only when you get to, say, "11.37px" do you get a different output. Not sure if those numbers accurately reflect the quanta, but it was something like that. And again, this only happened with the newer GNU font stack and not with any of the other platforms. Now maybe there's some super beautifully readable output that comes from that algo, but OSX's gold standard of readability doesn't seem to do that... I didn't take the time to narrow this down any further than that, nor drill down to figure out what part of the font stack causes the discrepancy, or when it happened. Without a spec to which I can refer I'm 99% sure I'll get a response from a font-stack dev that this is the way fonts work and it's my app that is broken. And confirming that likely response isn't worth the effort it would take to precisely describe this bug on an issue list. As an aside-- my solution to this in my program is to do a sanity check at startup, do some sizing adjustments to make sure fonts fit appropriately into their boxes if necessary, and print out a message for users when the oddball GNU situation is detected. I have to print the message because the diagrams printed in the program are supposed to be pixel-exact, and oddball GNU users will notice extra space at the end of the boxes. (Which is a feature, because if those boxes were tight fitting oddball-GNU-font-stack users would potentially move them closer together and generate overlaps for sane-font-stack users...) Edit: clarifications
pdkl95 9y ago
For a very detailed discussion of font rendering from the historical compromises that caused sever line length problems, and how to properly render with reliable sizes at at any display ppi, I recommend reading this[1] paper by Maxim Shemanarev and the AGG project. A key reason we have font size problems today was Microlsoft's decision aggressively hint their display fonts. The hinting was so strong, many glyphs had their horizontal position forcibly quantized on the pixel grid. Thus 1% changes in font size might round to different pixels, with unpredictably and error accumulating into huge differences in length for each line. Scaling font size could make dialog unusable, so a lot of software used fixed px sizes so the GUI was predictable. Microsoft finally addressed this problem in recent versions of Windows, but it will take time to undo the "Only 96 ppi exists" damage. Font rendering is complicated! [1] http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...
smpetrey 9y ago
A point is a terrible unit for displays. No point in attempting a solution when ‘px’ is a viable solution already. Use ‘px’ where you can and then use ‘pt’ for your print styles.
- bshacklett 9y ago
  That's what puts me in the situation that caused me to start looking into this, though. I've got two displays; one high-dpi and one not. Without scaling the entire display on the High-DPI display, I can't use my terminal app on both screens because the type will either be too big or too small. If points were actually points, I could use a 12pt or 14pt font on both displays and be perfectly happy. I'd still have to deal with how it changed the number of available columns, but that's a solvable problem.
  - iainmerrick 9y ago
    What's wrong with scaling the entire high-DPI display? At least assuming you mean an OS-level thing that scales up font sizes and UI elements, not just scaling the raw pixels.
    - bshacklett 9y ago
      I don't want to scale up all of the UI controls just so that I can have type that's readable. I can fit a lot on the screen by keeping the scaling level down and just zooming into web sites when necessary, but it's a lot harder to do that with a terminal app.
      - iainmerrick 9y ago
        Hmm, I still don't quite follow the problem, sorry. If you need to scale up the terminal text to read it, don't you still need to scale up the other parts of the UI, so you can see those too? On the Mac at least, it seems to me this stuff works reasonably well. You can set the overall scaling per-screen, and you can set the (scaled) font size used by the Terminal. It's really not clear to me why you'd need to change both the UI scaling and the font size on a particular screen.
BugsJustFindMe 9y ago
I was kinda hoping that this would be about how HN uses too small fonts for everything so that I have to zoom to 120% before it becomes comfortable to view on my laptop.
- Jaruzel 9y ago
  I was going to debunk this, and suggest that you just set your default font size in your browser to bigger than 16px/12pt, but having just tested it, yes you are right, comment text is locked at about 13px in the HN CSS. That's a bit naughty. :(
v768 9y ago
It is strange to refer to measurements in inches when complaining about a lack of dimensional standards...
- kaslai 9y ago
  It's not so strange when you consider the fact that the point is defined with respect to the inch.
thiagocsf 9y ago
The irony of clamoring for a standard measurement and then proceeding to use imperial units isn’t lost on me.
scoot 9y ago
The biggest offender is is Outlook on macOS. You can pinch to zoom when editing an email, and it will remember your zoom level for subsequent emails created. There's no way to reset it to the default, and so no way to tell even roughly how big the text will look for the recipient (screen size notwithstanding).
kkotak 9y ago
I know printing is not in Vogue anymore, but there are still requirements from customers that need printing. The CSS spec for printing is beyond dismal. No two printouts from different devices let alone browsers look alike or have the same page breaks.
- erichurkman 9y ago
  If you're printing & care about fidelity, and can print to PDF first, use PrinceXML. Not affiliated, just a long term user.
kavya_praveen 9y ago
The only reason pixels appear to work is that everyone uses pixels in display setting, so changes to seem to work and people continue to use them to size things. They might as well just call them "screen resolution" or something, because they sure aren't resolution.
endergen 9y ago
I created this Lifesized module and demos at one point to explore how much more we relate to objects drawn at their real size. https://github.com/francoislaberge/lifesized https://github.com/francoislaberge/lifesized Imagine buying shoes in Browser on a monitor and getting a better feel for its look via it being rendered on screen at its real size. Also we should have an API for getting the Pixels Per Inch in browsers, it's a lie of 72 dpi everywhere currently regardless of the realdpi.
tomxor 9y ago
So... it should be 5 inches on a 52" screen and also 5 inches on a 7" smart phone screen? I guess users are gona have to find a way to wrap the rest of the 52 inches around their face when trying to read that example text other wise it's wasted space. Looking at the problem holistically is not optional when it comes to perception.
kavya_praveen 9y ago
The only reason pixels appear to the display settings. And so they change to seem to work and people continue to use them to size things. They might as well just call them "screen resolution" or something, because they sure aren't resolution.
xpaulbettsx 9y ago
The problem is that if you want this, you now decide that scaling is not on integral or simple fractional scales (i.e. 2x or 2.5x), but on any arbitrary floating point scale (i.e. 2.0245x), which makes shipping bitmap assets generally pretty problematic. We decide that, in order to make writing applications easier, we will _approximate_ font sizes, because in most applications, it's Going To Be Okay. It sucks that certain ones like DTP apps get the raw end of the deal, but at the end of the day, it's better for most people using computers that we don't try to perfectly abstract away the exact pixel density and dimensions of your display.
- lucaspiller 9y ago
  If you are designing an application today, why would you use bitmap assets? Logos, buttons, icons, and other UI are all going to be designed in a vector graphics program, so just export them as SVG and be done with it. SVG is even supported well enough in web browsers to use without issue. Take a look at the Stripe website for example, most of the images there are SVG.
  - TheCoreh 9y ago
    SVG is often pixel-hinted to match pixel edges and provide visually pleasing lines and shapes at low resolution
- iainmerrick 9y ago
  Floating point scaling for bitmaps sounds bad, but often it's actually OK. It helps if PPI is very high, which these days usually it is. The iPhone 6 Plus (and I imagine the 7+ and 8+) scales its screen in hardware from 1242x2208 to 1080x1920 and it looks fine. If you really need UI graphics to be completely crisp, you can always use vectors.
makecheck 9y ago
I wish default sizes didn’t matter so much. In theory, anything that’s too small can be Accessibility-sized to something that you like better. In practice, you just give up after encountering a bunch of “Butto…” with “Titl…” and decide to suffer through whatever improper size was chosen. (Or if you’re really unlucky, it’s one of those interfaces where improperly-fitting text just plain disappears without leaving anything behind.) The number one rule with text should be: respect the user’s choice.
bitbang 9y ago
As somebody who regularly has to set up an 8 way projector blend to create a 120 ft x 20 ft screen for presentation graphics... Hell no.
- bshacklett 9y ago
  That's an argument against using points for measurement, not for the current definition of a point.
  - bitbang 9y ago
    True, but the author of that article doesn't seem to understand that.
justinjlynn 9y ago
But which definition of "Point" should be used? It's ambiguous (see https://en.wikipedia.org/wiki/Point_(typography)#Varying_standards https://en.wikipedia.org/wiki/Point_(typography)#Varying_sta... ). At this point, if you demand length equality, use well defined absolute units (i.e. mm, cm, in). However, you've going to have to make some difficult decisions between using absolute units and small-screen support. Relative units permit dynamic rescaling but in so doing one has to give up the explicit length equality demand. If you really want to, you can use device/media queries and varying stylesheets to get around this; but for all that is holy, please don't demand 12pt be 12pt everywhere -- we can't even all agree on what a point is without (implicit and unreliable) context.
thriftwy 9y ago
Even on wall TV? Flagging.
tastytech108 9y ago
We should standardize on something, at least so we have a model everyone can go off of.
ngrilly 9y ago
I don't understand how this article never mentions CSS reference pixel: https://www.w3.org/TR/css-values-3/#reference-pixel https://www.w3.org/TR/css-values-3/#reference-pixel
blattimwind 9y ago
> Computer hardware and software people could never figure out a reliable way to communicate the diagonal display size. It was just easier for the hardware and software to communicate the screen resolution and just punt on factoring in how packed the pixels were when rendering computer graphics. There was never commitment by the computer industry to deliver display output that matched real-world measurements. No, this is a HTML/browser problem. Since the days of DDC (late 90s) this worked plug-n-play. If, for example, you set a PDF viewer to 100 % then you will practically always get a 1:1 size reproduction that is basically dead nuts on.
deleted 9y ago
[deleted]
nottorp 9y ago
I get the rant about font sizes and i agree with it, however the OP should keep in mind that displays are of wildly varying sizes and aspect ratios, and physical measurements don't really help much. For example, I'd rather have the 5 inch box be 3 inches on a 7" tablet, and 5 inch on my 24" monitor. If you go the path of pretty design with typographical conventions you end up with those web pages that show 2 lines of text on mobiles and take up 15% of your screen on a 30" monitor.
kozak 9y ago
The same angular size.
simonelaird 9y ago
A point is defined as 1/72 inch. An Inch should be an inch and a pixel should be a pixel, this is not that hard.
- vetinari 9y ago
  Step one would be to persuade manufacturers not to lie about device dimensions in EDID. Then software would have a fighting chance of knowing, how many pixels are in an inch. Good luck with projector manufacturers ;).
shamas 9y ago
So this person is proposing that every random site gets to determine the size I want to have my font and wants to make it the same regardless of device? Way to only think of the designers.

290 points by bshacklett 9y ago

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

jenkstom 9y ago

Spoken like someone who doesn't have to wear reading glasses. Us old folks will be fighting this one. ;-)

rocqua 9y ago
Let the user specify a zoom factor, but then 12pt text zoomed by a factor X is the same on every display. There is some issue with how this should interact with certain things (like touch distance). Should two buttons that are 2cm apart be 4cm or 2cm apart after scaling by a factor of two? There is a fringe case of a display-based ruler, that essentially shouldn't zoom.
- mark-r 9y ago
  Ideally you'd want 2 zoom factors, one for visuals and one for touch. But then you'd potentially have buttons that couldn't hold their labels anymore. I think one zoom factor should be sufficient. Given that we can't support actual-size rulers today, I think we've demonstrated that we can live without them. P.S. for low resolution displays it's obvious that clear text and graphics is more important than absolute size.
jlarocco 9y ago
A "point" is a unit of measure. If a person wants to zoom in or out, it's up to them, but by definition a point is 1/72 of an inch. We don't change the definition of a mile based on the type of vehicle travelling it, and we shouldn't change the definition of a point based on the type of display viewing it.
- hinkley 9y ago
  You don't hang out with any sailors or fishermen, do you...
  - javajosh 9y ago
    lol yeah i was about to point out nautical miles and knots, but you beat me to it.

Laylo_ 9y ago

Man, writing for Jumbotrons is going to suck...

Bromskloss 9y ago
How so? Do you mean that we should specify sizes normalised to the viewing distance instead of in absolute terms?
- zokier 9y ago
  See also CSS pixels, which are one of the weirdest units around.

arximboldi 9y ago

I have mixed feelings about this. I get the point about touch: i.e. the button should have a fixed size in proportion to your finger. However in other scenarios I am not sure size should be constant. In most cases, you have to factor in the distance to the viewer. This is, probably "projection angle in the retina" is a more useful invariant. For example, in a big TV that is far from you, you want things to be bigger than in a monitor, that is closer. And in a laptop, you probably want it even smaller. "Design by pixel" takes this into account somewhat indirectly because most display are designed to have their pixel density in inverse proportion to the size of the display, which is also inversely correlated to the expected usage distance. Sometimes technology changes our expectations of definitions and things become small, until designs catch up with the new expected pixel density. We have worked around this problem with pixel density factors on retina/QHD. I agree that all this in the is a evolutionary "hack". But I am not sure that the proposed solution, even though more rational sounding, actually makes things better.

colechristensen 9y ago
An inch should be an inch. A pixel should be a pixel. A point should be a point which is defined as 1/72 inch. Those are all physical measurements, meant for the surface of the screen. If you design with them, it means you're designing with the screen size in mind. It's often wrong to design with those measurements. There are relative sizes too. %, em (current size of font), and measurements relative to viewports. That's what designers use very often.
- protonfish 9y ago
  So you are saying you would want one physical square inch on a phone to be the exact same size one square inch on a projector screen? I have been designing and building interfaces for a couple decades and I have been down the "relative size" path and learned not to do that the hard way. There lies nothing but tears. Sizing to pixels, for some reason, results in the most predictable and consistent appearances.
  - zlynx 9y ago

rocqua 9y ago

What is the interaction with zooming? You can't just deny zooming. Users want it, and if you disable it, someone will still monkey-patch it in. A first-order solution is to have 'zooming' be pure scaling. Essentially, instead of ISO defining a milimetre, the user defines it, and it defaults to the ISO definition. This essentially means the system has to handle a screen-size that could change at any given time. Unless you are willing to accept interpolation. But then, what happens when real-distance starts to matter. A stupid example is a ruler app, that obviously breaks upon scaling. Generally, any app that depends on `real hardware' interacting with the screen, this is going to be an issue. Specifically, this is an issue for touch screens. Even more so because 'human hands' are `real hardware'. If two buttons are rendered 2cm apart, and the user scales by a factor of 2x, that would put the buttons 4cm apart. That might be too much of a spread to use comfortably. In general, does it really make sense to treat a 14" screen scaled at 2x as a 7" screen? What about a 15" screen scaled at 3x? If you accept the above as a problem, there are many solutions, but they are either a lot of work, or require 'monkey patching'. Sadly, this means the quote "Resolution independent graphics is a solved problem." not quite right. At least insofar as any chosen system will have trade-offs between ease of development and ease of use. Taking a pessimistic view: Those trade-offs will inevitably fall towards development on occasion, which will train users to think this is stupid anyway. Thus developers get less benefit, and we will see weird monkey patching to attempt to fix this. Maybe at some point, someone walks in and declares "this is a mess, it should have been done right from the start".

xelxebar 9y ago
Yeah. These accessibility vs. design issues were what immediately came to me mind to. Though, as simply another tool in the bag, accurate real-world sizing capability seems like it could be used too actually help those issues. Would like to hear more from designers that on the issues and challenges of creating accessible designs.
- oatmealsnap 9y ago
  It is a best practice (and required by certain WCAG 2.0 guidelines) to allow users to adjust the text size to meet their needs. The 2.1 AA guideline says that websites must scale up to 400% and still be usable. In CSS, I almost entirely use relative units so that I don't need to worry about how things will scale. If the user wants/needs their text to be larger, they will also want/need [any other element] to be larger, as well. Of course, if you let your buttons scale as much as your text does, you can end up with buttons taking up the entire screen. I typically solve that by using max-sizing on an element, rather than using `in` or `cm`...I can't recall ever using physical units in web design.

ZenPsycho 9y ago

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.

taylorbuley 9y ago

Original discussion when submitted by author: https://news.ycombinator.com/item?id=4236429 https://news.ycombinator.com/item?id=4236429

kccqzy 9y ago

The best size is dependent on the distance between the eye and the content. You would use letters less than 10mm on a smartphone screen but you could very well use an inch or more on a big TV screen. As a designer you have no idea whether your web page will be displayed on a tiny screen of a low-end smartphone or a big TV.

thomastjeffery 9y ago
A user can scale point sizes to her/his liking. That still means that point sizes should be consistently scaled.

deleted 9y ago

[deleted]

sds111 9y ago

Bill Gates made this same promise when Windows 1 was released. That each monitor and printer would require drivers specific to their model in order that the fonts would be measures in points (or pica) instead of in pixels. Somehow we ended up with all the drivers for each device even though the original promise has been long forgotten. We sacrificed the days of the plain printer with Centronix hardware interface, and the versatility of the Unix lpr spooler where you simply sent a stream out to printers containing control codes you knew would work with your device, like carriage return and linefeed. Then later the Calcomp and HPGL codes. And what did we gain for that trade? I think this link is great, because someone is clearly remembering the promise. Upvote for that.

crazygringo 9y ago

We should standardize on something, but it shouldn't be inches. You might be looking at a phone screen a foot away, or a monitor two feet away, or a TV four feet away, or a projection 10 feet away, or a jumbo display 100 feet away. How does measuring in inches help? Answer: it doesn't at all. Measuring in points used to be a good system, back on the Mac in the old days. The user interface was in 12 pt Chicago, new Word documents defaulted to 12 pt Times New Roman -- 12 pt was the baseline for normal body text both for interface and for content, and everything else made sense relative to that. Then what happened? For some reason, web browsers defaulted to 16 pt. So the text on web pages was too big. Then, laptop screens started packing more pixels in (this is pre-retina) to advertise higher resolutions, and OS interface text became physically smaller -- really hard to read. 16 pt webpages were actually OK though, so now that kind of made sense. Strangely, at the same time, interface text got even smaller -- look at the tiny text OSX now uses in a lot of dialog settings, or the small size Chrome uses for tab titles. (Menus and buttons are usually still OK.) And then bloggers wanted to make webpages easier to read, so they started doing things like 18 pt text (e.g. Medium) and sometimes you see 20 pt or even 22 pt. So now, each letter on Medium takes up about three times the area of a letter in the title of the tab I have open on Chrome. Scale on computer screens no longer makes any sense, and you have to constantly use some combination of monitor resolution and browser zoom to keep all the elements of your screen in any kind of reasonable proportion. So my humble suggestion is: can't we just go back to where 12 pt meant normal computer screen UI text and body text, and everybody stick to that? Forget that points are based on inches, just make everything relative to 12 pts = body text. Then everyone can pick a resolution or zoom level for each device so it's legible for your eyes at your distance... but then everything stays in proportion!

deathanatos 9y ago
I've argued in the past[1] (and there were a few good comments in that thread, in response) that most UI elements should be measured in arcdegrees they should consume in the field of view of the user. That is, how large should this text appear, not how big should it be physically rendered, either in pixels or inches. (So some derived unit, like pt.) As I stated in that thread, the display device would need some concept of its own dimensions (easy) and its intended viewing distance (harder, and would probably need to be configurable). The one commenter in that thread notes, I think rightly, that, > once you get to very small screens like phones, there is a tradeoff between keeping font and UI sizes comfortable, and being able to actually fit enough content on the screen without endless scrolling. I am willing to strain my eyes with smaller font sizes on my phone than on my laptop, just so that I can see more than 5 sentences of text at the same time. I think is particularly applies as blog fonts get larger and larger. > web browsers defaulted to 16 pt Are you sure? I don't ever remember this being the case; it's always been 12pt (usually a serif font, often Times New Roman). Are you sure you're not mixing that up w/ 16px (which I believe in CSS, 12pt == 16px)? [1]: https://news.ycombinator.com/item?id=14002821 https://news.ycombinator.com/item?id=14002821

throwaway613834 9y ago

Apparently I'm not the first person to say this, but why not use angles (e.g. arcseconds) instead of length?

deathanatos 9y ago
A small, previous discussion of this suggestion[1]. (And I completely agree, for most use cases.) [1]: https://news.ycombinator.com/item?id=14002821 https://news.ycombinator.com/item?id=14002821

Doffity 9y ago

One physical square inch on your phone should be the exact same size as one square inch on a projector screen, is that really what you're saying?

bshacklett 9y ago
I believe @recursive put it very well: > If they're not the same, then they're not inches. I'm not saying that UI elements should necessarily be the same size, but the option should be available. Having a point be equal from display to display doesn't mean that relative scaling isn't impossible; it just means that you need to use different units for those cases (which is probably most of the time). Points really aren't all that useful on computer monitors at present; you're better off using EMs, percentage or possibly pixels depending on what your goal is. This leaves a gap, however, when it actually is advantageous to know for certain what size a UI element will be at display-time.

jancsika 9y ago

Let's back up a little and talk about pixel sizes: Suppose I render "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" in DejaVu Sans Mono with a normal font-weight: once at size "12px", and then again at "11.65px". (Note: those are pixel sizes, not point sizes.) Assume that string is all a single non-wrapping line and rendered to an HTML5 canvas using a web browser, and that I have loaded some known version of my font using the "@font-face" syntax in CSS. What should the width be in each case when I measure using the "measureText" method? If a given platform's font stack renders that string substantially wider-- say, 7 pixels wider-- than every other platform (all of which return a values within half a pixel of each other), is that a bug? If so, is there a specification somewhere that requires a platform's font stack to produce a pixel-sized result for a pixel-sized font within some threshold? Or are font stack devs within their rights to justify whatever the metrics are based on other aesthetic or perceptual qualities of their renderer?

iainmerrick 9y ago
That happens all the time, and unfortunately it isn't regarded as a bug. There's no specification or agreement that requires font renderers to match up. Font rendering used to be all about bitmaps, then as TrueType matured it was all about aggressively hinting (and auto-hinting) to fit the pixel grid, and we haven't fully gotten away from that. Of all the main OSes, I think OS X and iOS do the least hinting, but I don't know if they do no hinting; and many people dislike the blurry text on OS X. (I don't see any complaints about blurriness on iOS, though, where you always have really high screen resolution now.) It would be technically feasible for all font renderers to product identical output (or at least to provide such an option) but nobody seems to care enough to push for it.
- jancsika 9y ago
  tl;dr - without a spec nothing will ever change Thanks for the reply-- it's what I gathered from doing a little digging into extant font stacks but wasn't sure if I had skipped over an obscure specification somewhere. So here's the deal-- maybe a year ago, I tested Windows, OSX, and old-school GNU (via Ubuntu 14.04) and got font metric results within a half a pixel of each other for the test I outlined above. New-school GNU, however, was about 7 pixels wider. Again, this was for the same version of a mono-spaced font, loaded from the same font file shipped with my test program. I also got reports from users of other GNU/Linux distros about the discrepancy-- these were distros that also used the newer GNU font stack. Since that time I've seen reports about this discrepancy affecting other software. One final data point-- I also noticed that the newer GNU font stack seems to quantize pixel sizes that aren't whole numbers. For example, assume size "11.3px" generates a particular output. Then "11.33px" would generate the same output, and only when you get to, say, "11.37px" do you get a different output. Not sure if those numbers accurately reflect the quanta, but it was something like that. And again, this only happened with the newer GNU font stack and not with any of the other platforms. Now maybe there's some super beautifully readable output that comes from that algo, but OSX's gold standard of readability doesn't seem to do that... I didn't take the time to narrow this down any further than that, nor drill down to figure out what part of the font stack causes the discrepancy, or when it happened. Without a spec to which I can refer I'm 99% sure I'll get a response from a font-stack dev that this is the way fonts work and it's my app that is broken. And confirming that likely response isn't worth the effort it would take to precisely describe this bug on an issue list. As an aside-- my solution to this in my program is to do a sanity check at startup, do some sizing adjustments to make sure fonts fit appropriately into their boxes if necessary, and print out a message for users when the oddball GNU situation is detected. I have to print the message because the diagrams printed in the program are supposed to be pixel-exact, and oddball GNU users will notice extra space at the end of the boxes. (Which is a feature, because if those boxes were tight fitting oddball-GNU-font-stack users would potentially move them closer together and generate overlaps for sane-font-stack users...) Edit: clarifications

pdkl95 9y ago

For a very detailed discussion of font rendering from the historical compromises that caused sever line length problems, and how to properly render with reliable sizes at at any display ppi, I recommend reading this[1] paper by Maxim Shemanarev and the AGG project. A key reason we have font size problems today was Microlsoft's decision aggressively hint their display fonts. The hinting was so strong, many glyphs had their horizontal position forcibly quantized on the pixel grid. Thus 1% changes in font size might round to different pixels, with unpredictably and error accumulating into huge differences in length for each line. Scaling font size could make dialog unusable, so a lot of software used fixed px sizes so the GUI was predictable. Microsoft finally addressed this problem in recent versions of Windows, but it will take time to undo the "Only 96 ppi exists" damage. Font rendering is complicated! [1] http://www.antigrain.com/research/font_rasterization/index.html http://www.antigrain.com/research/font_rasterization/index.h...

smpetrey 9y ago

A point is a terrible unit for displays. No point in attempting a solution when ‘px’ is a viable solution already. Use ‘px’ where you can and then use ‘pt’ for your print styles.

bshacklett 9y ago
That's what puts me in the situation that caused me to start looking into this, though. I've got two displays; one high-dpi and one not. Without scaling the entire display on the High-DPI display, I can't use my terminal app on both screens because the type will either be too big or too small. If points were actually points, I could use a 12pt or 14pt font on both displays and be perfectly happy. I'd still have to deal with how it changed the number of available columns, but that's a solvable problem.
- iainmerrick 9y ago
  What's wrong with scaling the entire high-DPI display? At least assuming you mean an OS-level thing that scales up font sizes and UI elements, not just scaling the raw pixels.
  - bshacklett 9y ago
    I don't want to scale up all of the UI controls just so that I can have type that's readable. I can fit a lot on the screen by keeping the scaling level down and just zooming into web sites when necessary, but it's a lot harder to do that with a terminal app.
    - iainmerrick 9y ago
      Hmm, I still don't quite follow the problem, sorry. If you need to scale up the terminal text to read it, don't you still need to scale up the other parts of the UI, so you can see those too? On the Mac at least, it seems to me this stuff works reasonably well. You can set the overall scaling per-screen, and you can set the (scaled) font size used by the Terminal. It's really not clear to me why you'd need to change both the UI scaling and the font size on a particular screen.

BugsJustFindMe 9y ago

I was kinda hoping that this would be about how HN uses too small fonts for everything so that I have to zoom to 120% before it becomes comfortable to view on my laptop.

Jaruzel 9y ago
I was going to debunk this, and suggest that you just set your default font size in your browser to bigger than 16px/12pt, but having just tested it, yes you are right, comment text is locked at about 13px in the HN CSS. That's a bit naughty. :(

v768 9y ago

It is strange to refer to measurements in inches when complaining about a lack of dimensional standards...

kaslai 9y ago
It's not so strange when you consider the fact that the point is defined with respect to the inch.

thiagocsf 9y ago

The irony of clamoring for a standard measurement and then proceeding to use imperial units isn’t lost on me.

scoot 9y ago

The biggest offender is is Outlook on macOS. You can pinch to zoom when editing an email, and it will remember your zoom level for subsequent emails created. There's no way to reset it to the default, and so no way to tell even roughly how big the text will look for the recipient (screen size notwithstanding).

kkotak 9y ago

I know printing is not in Vogue anymore, but there are still requirements from customers that need printing. The CSS spec for printing is beyond dismal. No two printouts from different devices let alone browsers look alike or have the same page breaks.

erichurkman 9y ago
If you're printing & care about fidelity, and can print to PDF first, use PrinceXML. Not affiliated, just a long term user.

kavya_praveen 9y ago

The only reason pixels appear to work is that everyone uses pixels in display setting, so changes to seem to work and people continue to use them to size things. They might as well just call them "screen resolution" or something, because they sure aren't resolution.

endergen 9y ago

I created this Lifesized module and demos at one point to explore how much more we relate to objects drawn at their real size. https://github.com/francoislaberge/lifesized https://github.com/francoislaberge/lifesized Imagine buying shoes in Browser on a monitor and getting a better feel for its look via it being rendered on screen at its real size. Also we should have an API for getting the Pixels Per Inch in browsers, it's a lie of 72 dpi everywhere currently regardless of the realdpi.

tomxor 9y ago

So... it should be 5 inches on a 52" screen and also 5 inches on a 7" smart phone screen? I guess users are gona have to find a way to wrap the rest of the 52 inches around their face when trying to read that example text other wise it's wasted space. Looking at the problem holistically is not optional when it comes to perception.

kavya_praveen 9y ago

The only reason pixels appear to the display settings. And so they change to seem to work and people continue to use them to size things. They might as well just call them "screen resolution" or something, because they sure aren't resolution.

xpaulbettsx 9y ago

The problem is that if you want this, you now decide that scaling is not on integral or simple fractional scales (i.e. 2x or 2.5x), but on any arbitrary floating point scale (i.e. 2.0245x), which makes shipping bitmap assets generally pretty problematic. We decide that, in order to make writing applications easier, we will _approximate_ font sizes, because in most applications, it's Going To Be Okay. It sucks that certain ones like DTP apps get the raw end of the deal, but at the end of the day, it's better for most people using computers that we don't try to perfectly abstract away the exact pixel density and dimensions of your display.

lucaspiller 9y ago
If you are designing an application today, why would you use bitmap assets? Logos, buttons, icons, and other UI are all going to be designed in a vector graphics program, so just export them as SVG and be done with it. SVG is even supported well enough in web browsers to use without issue. Take a look at the Stripe website for example, most of the images there are SVG.
- TheCoreh 9y ago
  SVG is often pixel-hinted to match pixel edges and provide visually pleasing lines and shapes at low resolution
iainmerrick 9y ago
Floating point scaling for bitmaps sounds bad, but often it's actually OK. It helps if PPI is very high, which these days usually it is. The iPhone 6 Plus (and I imagine the 7+ and 8+) scales its screen in hardware from 1242x2208 to 1080x1920 and it looks fine. If you really need UI graphics to be completely crisp, you can always use vectors.

makecheck 9y ago

I wish default sizes didn’t matter so much. In theory, anything that’s too small can be Accessibility-sized to something that you like better. In practice, you just give up after encountering a bunch of “Butto…” with “Titl…” and decide to suffer through whatever improper size was chosen. (Or if you’re really unlucky, it’s one of those interfaces where improperly-fitting text just plain disappears without leaving anything behind.) The number one rule with text should be: respect the user’s choice.

bitbang 9y ago

As somebody who regularly has to set up an 8 way projector blend to create a 120 ft x 20 ft screen for presentation graphics... Hell no.

bshacklett 9y ago
That's an argument against using points for measurement, not for the current definition of a point.
- bitbang 9y ago
  True, but the author of that article doesn't seem to understand that.

justinjlynn 9y ago

But which definition of "Point" should be used? It's ambiguous (see https://en.wikipedia.org/wiki/Point_(typography)#Varying_standards https://en.wikipedia.org/wiki/Point_(typography)#Varying_sta... ). At this point, if you demand length equality, use well defined absolute units (i.e. mm, cm, in). However, you've going to have to make some difficult decisions between using absolute units and small-screen support. Relative units permit dynamic rescaling but in so doing one has to give up the explicit length equality demand. If you really want to, you can use device/media queries and varying stylesheets to get around this; but for all that is holy, please don't demand 12pt be 12pt everywhere -- we can't even all agree on what a point is without (implicit and unreliable) context.

thriftwy 9y ago

Even on wall TV? Flagging.

tastytech108 9y ago

We should standardize on something, at least so we have a model everyone can go off of.

ngrilly 9y ago

I don't understand how this article never mentions CSS reference pixel: https://www.w3.org/TR/css-values-3/#reference-pixel https://www.w3.org/TR/css-values-3/#reference-pixel

blattimwind 9y ago

> Computer hardware and software people could never figure out a reliable way to communicate the diagonal display size. It was just easier for the hardware and software to communicate the screen resolution and just punt on factoring in how packed the pixels were when rendering computer graphics. There was never commitment by the computer industry to deliver display output that matched real-world measurements. No, this is a HTML/browser problem. Since the days of DDC (late 90s) this worked plug-n-play. If, for example, you set a PDF viewer to 100 % then you will practically always get a 1:1 size reproduction that is basically dead nuts on.

deleted 9y ago

[deleted]

nottorp 9y ago

I get the rant about font sizes and i agree with it, however the OP should keep in mind that displays are of wildly varying sizes and aspect ratios, and physical measurements don't really help much. For example, I'd rather have the 5 inch box be 3 inches on a 7" tablet, and 5 inch on my 24" monitor. If you go the path of pretty design with typographical conventions you end up with those web pages that show 2 lines of text on mobiles and take up 15% of your screen on a 30" monitor.

kozak 9y ago

The same angular size.

simonelaird 9y ago

A point is defined as 1/72 inch. An Inch should be an inch and a pixel should be a pixel, this is not that hard.

vetinari 9y ago
Step one would be to persuade manufacturers not to lie about device dimensions in EDID. Then software would have a fighting chance of knowing, how many pixels are in an inch. Good luck with projector manufacturers ;).

shamas 9y ago

So this person is proposing that every random site gets to determine the size I want to have my font and wants to make it the same regardless of device? Way to only think of the designers.