-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optical size recommended implementation is ambiguous #310
Comments
Proposed revisions for the next version, based on a draft by John Hudson and comments from David Berlow and Vlad Levantovsky:
|
Is it possible to use SI units as much as possible (e.g. for the reading distances). |
Revised this sentence:
|
SI means size independent?
|
In general, I very much like the proposed updated description, I think it is necessary and appropriate to emphasize the fact that it's the text optical size as seen by the reader that should drive the selection of variation axis value, not the nominally declared point size alone. One minor comment - in the fifth paragraph of the "Additional information" section, the sentence
should be extended to mention display resolution as one of the factors, e.g. [with emphasis added only to highlight the proposed change]: Factors to be taken into account should include the scaling of type on specific platforms and the translation of document and platform units to 1/72 of a physical inch, as well as display resolution and typical reading distances for applications and devices. |
Vlad, can you explain in more detail how you see display resolution being relevant here? I am concerned to avoid overlap of optical size design and instance selection with what has traditionally been the domain of hinting, and which could conceivably by the domain of an axis specifically addressing device resolution. |
I don't like "display resolution" since that term is ambiguous: pixel dimensions, or pixel density. The term gets used in Windows, but in contexts in which it means pixel dimensions. It's not clear to me how pixel dimensions would be relevant for selecting optical size variants. |
The second paragraph of the updated description says:
Let's consider two possible scenarios: a reader viewing text at the normal viewing distance (14-16 inches) on a standard laptop screen (1366 x 768 pixels) vs. viewing same text at the same reading distance on iPad with 2388 x 1668 pixels. The level of contrast, the amount of aesthetic details, and legibility in general that can be rendered at the same size on these two different screens would vary significantly. Hence, my suggestion to include display resolution as one of the factors was simply based on the fact that optical styling / optical size selection may be different based on screen resolution alone, even if nothing else changes. And yes, I am speaking about pixel density here, so if using display resolution as a term is ambiguous, we can say pixel density, or screen resolution defined by pixels per inch, etc. |
Yes, but that is orthogonal to optical size design, which is resolution independent. I really don't want to overload opsz with things that can and, I think, should be handled via other mechanisms. Apart from the traditional hinting mechanisms, we also have concepts like grade, or resolution-specific axes that would work indepedently of and interact with opsz. If I design a 6pt optical size design, I do so either in a way that is independent of rendering—i.e. presuming a high resolution—, or I am targeting a specific rendering at the font level, or I am anticipating tailoring that design to specific rendering, e.g. with hinting. |
Like I said, that was a minor comment. ;-) |
We intended the opsz value to be the document text size in points. Focusing on the document keeps layout consistent within a document, regardless of on-screen rendering, which helps for zooming and accesssibility scenarios (mentioned here: w3c/csswg-drafts#807), and keeps layouts consistent between screen and print.
Unfortunately, the spec's recommended implementation lack any of this detail.
Related: w3c/csswg-drafts#4430
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
The text was updated successfully, but these errors were encountered: