Re: [csswg-drafts] [css-fonts] Proposal to extend CSS font-optical-sizing (#4430)

> > As I understand it, you're arguing that given content styled with font-size: 12pt, a browser running on macOS should apply opsz=16, while a browser running on Windows should use opsz=12 (right?).
> I don't think that's the automatically the correct assumption for Windows. The Mac environment has built-in equivalences — to provide consistency of scaling of text across applications — that don't have parallels on other platforms. So when you go on to say that you will potentially see different opsz selection depending on OS-level resolution settings you've selected, that indicates that opsz selection should take into account those OS-level resolution settings (which is what in effect happens on the Mac because the resolution settings are consistent).

I don't think this is correct (though perhaps we're just misunderstanding each other). `opsz` selection on the Mac does _not_ take OS-level resolution settings into account (and I don't believe it should). The System Preferences panel on my MacBook offers me five different "resolution" (display scaling) options, from "Larger Text" to "More Space", with the ratio between the two extremes being nearly 1.8:1. This affects the size of everything rendered, so that the actual physical size of `font-size:12pt` on the screen varies hugely depending which setting I've chosen -- but the `opsz` value applied remains constant. This is true for both a desktop application like Pages and for browsers.

> Remember, spec'ing CSS font-size 12pt for browser text is not the same thing as spec'ing type in units of 1/72 physical inch for print, so there is always going to need to be a calculation to get the correct opsz selection that takes into account the local relationship of CSS pt or px to the physical unit of the opsz axis scale.

I disagree here: `opsz` selection _should_ be based directly on the CSS `font-size`, and should _not_ be affected by scaling that may be happening. Text styled as `font-size:24pt` might be rendered mere millimeters high, thanks to `transform: scale(...)`, for example, or might be rendered several times larger as the user zooms the page, but it remains _stylistically_ 24-point text and the optical size appropriate to this should be used. Zooming, transforms, OS resolution changes.... they're all simple linear scalings that should not result in a _different_ rendering.

> Apple are just performing this calculation once for all, whereas other platforms may need to perform it based on device and system resolution.

Unfortunately, Apple has established some conventions here that have built-in inconsistencies. If I use an optically-sized font in Pages at 12pt, I get `opsz=12` on the screen, and the same when I print. If I used that same optically-sized font in Safari at `font-size:12pt`, it looks 33% larger on screen, and uses `opsz=16`. Yet when I print the web page, it comes out the same size as the 12pt text from Pages.

One way to view it, I think, is that browsers on macOS have chosen to rescale web content (in comparison to content in native desktop apps) such that the default ("100% zoom") size is enlarged to 133%. So "1pt" in web content is larger on the screen than "1pt" in other applications. That in itself need not be a problem.... but now the `opsz` axis is being set based on this 133% view. That makes it inconsistent with how `opsz` is applied in other applications. And it means that _either_ it will be wrong for printed copies of web content (because the 133% scaling isn't applied to printed output) _or_ there'll be a mismatch between screen display and print, potentially resulting in surprising reflows, etc., when a document is printed.

GitHub Notification of comment by jfkthame
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 23 September 2020 12:11:13 UTC