Skip to content
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

Closed
robmck-ms opened this issue Oct 30, 2019 · 11 comments
Closed

Optical size recommended implementation is ambiguous #310

robmck-ms opened this issue Oct 30, 2019 · 11 comments

Comments

@robmck-ms
Copy link
Collaborator

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.

@PeterCon
Copy link
Collaborator

Proposed revisions for the next version, based on a draft by John Hudson and comments from David Berlow and Vlad Levantovsky:

Scale interpretation: Values can be interpreted as text size, in points.typographic points, as defined in the OpenType specification: a physical unit equal to 1/72 of a standard physical inch.

Recommended or required “Regular” value: A value in the range 9 to 1310 to 16 is recommended for typical text settings.

Suggested programmatic interactions: Applications may choose to select an optical-size variant automatically based on the displayedtext size.

Additional information

The Optical size axis can be used as a variation axis within a variable font. It can also be used within a STAT table in non-variable fonts within a family that has optical-size variants to provide a complete characterization of a font in relation to its family within the STAT table. In the STAT table of a non-variable font, a format 2 axis value table is recommended to characterize the range of text sizes for which the optical-size variant is intended.

Typical font implementation of optical size design variants involves adapting glyph proportions, stem weights, and details to be appropriate to specific sizes of displayed text. These adaptations may be both functional and aesthetic, ensuring legibility at smaller sizes and refinement of fine details and overall width at larger sizes. The nature of the adaptations may depend on aspects of the individual typeface design, the characters or scripts involved, targeted devices on which the font may be displayed, and known or intended distance from which text will be viewed.

Type designers may develop size-specific design variations based on print or screen rendering, typically evaluating the design of these variations at a reading distance of 14 to 16 inches. This can be used as a basis for determining appropriate optical size variants for different distances. For example, if the design of a given optical size variant is appropriate for 12 point text viewed from a reading distance of 15 inches, it should also be appropriate for 24 point text viewed from a reading distance of 30 inches.

The scale for the Optical size axis is text size in points. For these purposes, the text size is as determined by the document or application for its intended use; the actual physical size on a display may be different due to document or application zoom settingsplatform or application scaling methods or intended viewing distance.

The target of size-specific design is optical; i.e., tailored to what the reader is seeing. For this reason, Optical size axis variant selection should be determined, so far as possible, by as much information as available regarding displayed size of text as seen by the reader. 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 typical reading distances for applications and devices. This may mean that a nominally specified text size in a document could result in a different Optical size axis variant selection on different platforms and devices, determined by the actual size of text seen by the reader.

Note: User-perceived size is very dependent on viewing distance, not only physical size on the display. For example, when viewing text on a large-screen TV, the physical size on the display will be many times larger than the size perceived by the user. In this case, selecting an Optical size variant based only on the physical size on the display would likely result in reduced legibility for the user.

When translating between document units and the point (1/72 inch) scale for this axis, care should be taken not to assume equivalences between units that may apply on some platforms but not others.

In applications that automatically select an Optical size variant, this should normally be done based on the text size with a default or “100%” zoom level, not on a combination of text size and zoom level. Types of zoom that do not trigger re-layout of text should not change Optical size variant selection, while content enlarging or diminishing operations that change re-layout of text should make a new Optical size variant selection based on the new displayed sized.

If the size of displayed text is smaller or greater than the minimum and maximum extent of the axis range, Optical size axis variant selection should be clamped to the appropriate minimum or maximum axis value, not reset to the default instance.

It is recommended that software provide means to override automatic Optical size variant selection, as may be appropriate for particular platforms, intended use, known viewing distance, or accessibility.

@schriftgestalt
Copy link

Is it possible to use SI units as much as possible (e.g. for the reading distances).

@PeterConstable
Copy link

Revised this sentence:

Type designers may develop size-specific design variations based on print or screen rendering, typically evaluating the design of these variations at a reading distance of 14 to 16 inches, or 35 to 40 cm.

@davelab6
Copy link

davelab6 commented Oct 18, 2020 via email

@schriftgestalt
Copy link

@vlevantovsky
Copy link

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

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 typical reading distances for applications and devices.

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.

Copy link

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.

@PeterConstable
Copy link

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.

@vlevantovsky
Copy link

The second paragraph of the updated description says:

Typical font implementation of optical size design variants involves adapting glyph proportions, stem weights, and details to be appropriate to specific sizes of displayed text. These adaptations may be both functional and aesthetic, ensuring legibility at smaller sizes and refinement of fine details and overall width at larger sizes.

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.

Copy link

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.

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.

@vlevantovsky
Copy link

Like I said, that was a minor comment. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants