- From: Rob McKaughan via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Oct 2019 19:56:33 +0000
- To: public-css-archive@w3.org
To wrap my head around all this, I did some testing to see what values of opsz browsers were using and how they actually render on screen. Quick summary: Macos is using unexpected values for opsz, and does not render 72pt at 72 physical points on-screen as measured with a ruler (in fact, it's 54pt which is 3/4 of 72, which may be interesting here). Windows Firefox uses values of opsz that are based on css px, while MSHTML-based Edge sets opsz based on css pt. All the Windows browsers render 72pt as 72 physical points as measured on screen with a ruler. (96dpi monitor with the OS at 100% scaling). ## Test environment I created a new version of Selawik Variable Test that adds an opsz axis. This font includes ligature glyphs that will show parameters that were given to the rasterizer (this comes thanks to some clever hinting tricks by @gr3gh, with tips from @nedley so that the hints execute even on macos), documented [here](https://github.com/unicode-org/text-rendering-tests/blob/master/fonts/Selawik-README.md). The new version of Selawik Variable Test is [here](https://github.com/robmck-ms/text-rendering-tests/blob/master/fonts/Selawik-variable.ttf). The opsz axis in this font doesn't have any visual differences (the fvar table is the only table that it appears in). However, if you use the \axis2 ligature, then it will show you the normalized opsz coordinate used to render the font. The axis is defined as being from 0 to 100, which means the normalized coordinate is just the opsz coordinate / 100. (Note: there may be rounding errors due to axis coordinates being 2.14 fixed-point internally, thus the \axis2hex ligature gives you the exact normalized 2.14 value). For measuring physical type size, you can also use the em-dash in Selawik as this glyph is the full UPM width. (Theoretically, you can also measure the distance between an ascender and descender, but you have to account for the difference between vertical metrics in the font and it's UPM value, so the length of the emdash is easier). I've created a codepen for everyone to use to try out this font on various browsers and OSes: https://codepen.io/robmck/pen/GRREgzG (Thanks to @lorp for hosting the font). Now here's the interesting bits: ## Windows * Edge (MSHTML-based). This gives the values I'd expect. Text set in 72pt is rendered with opsz=72. Text set in 72px is rendered with opsz=54 (see hex value) which is 72 * 4/3. When I measure text on a 96dpi screen at 100% scaling, I get text that is 1 inch (72pt) high.  * Firefox. 72pt is rendered with opsz=96, and 72px is rendered with opsz=72. This indicates that Firefox is using px for opsz, not pt. However, the text is the same size on screen as Edge-MSHTML.  * Chrome Canary 80.0.3951. Shows normalized values of 1.0 (thus opsz=100) for all sizes. I had thought automatic style scaling was turned on in Canary, but maybe not (@drott?).  ## macos * Safari. 72pt is rendered with opsz=93.274, and 72px is rendered with opsz=52.954 (I used the hex values here to make sure there wasn't any rounding issues in the display of \axis2, which only shows 4 significant digits). These are unexpected values. Based on @litherum's description, I would have expected values like Windows Firefox. Perhaps something in my config? (Macbook Pro, macos 10.13.6). The physical size of the emdash is 0.75 inch = 54 typographic points. I note that this is 72/96 of 1 inch.  * Chrome Canary 80.0.3951. Same values and physical size as Safari.  * Firefox. Same values and physical size as Safari.  ## Thoughts I had hoped there'd be more commonality here. Both opsz values and physical sizes differ. From CSS/web folks, what would be expected here? -- GitHub Notification of comment by robmck-ms Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-547118864 using your GitHub account
Received on Monday, 28 October 2019 19:56:35 UTC