- From: Rob McKaughan via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Nov 2019 18:38:00 +0000
- To: public-css-archive@w3.org
> @robmck-ms Is this a correct tabular summary of your test results? Mostly, yes, but some updates below: For macos: I discovered that the avar table in the font was causing some problems on macos, so I removed it, and updated the URL in the codepen. (The avar table is not relevant to this test, so unnecessary) This accounts for the strange numbers I saw for macos, and brings us within rounding error of what I'd expect: | OS | Browser / Engine | opsz @ 72pt | opsz @ 72px | 1in / 1 inch | |---|---|---|---|---| | macos | *all* | 95.996 | 72 | ~75% | Currently, there is no "Windows non-browser" line yet as browsers are the only applications that currently support automatic optical size. (DirectWrite does not have an API specifically for optical size selection because it's concidered an app-level decision as it has the context of the rendering intent (e.g. it knows if its zooming or not)). If/when Office supports automatic optical size, it will be based on the point size of the text in the document. I didn't test Windows / Safari as I didn't think there was such a thing anymore. Is there? I couldn't find a Windows webkit build. I tried the codepen on my Android phone. The text size in landscape is much different than portrait, so I don't know what to use as a baseline, so I didn't report on Android. I added a third line to the codepen that forces opsz to 50 to verify that the font does work on Android. -- GitHub Notification of comment by robmck-ms Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-548903672 using your GitHub account
Received on Friday, 1 November 2019 18:38:02 UTC