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

[Feature tags] Document default behavior of text rendering systems #290

Open
NorbertLindenberg opened this issue Aug 24, 2019 · 2 comments

Comments

@NorbertLindenberg
Copy link

The documentation of feature tags is written under the assumption that there are “applications” that interpret font tables directly, choose which features to apply by default, provide a user interface to let the user override the defaults, and apply the features.

There may be a few applications that actually do this, but the vast majority don’t. Instead, applications rely on text rendering systems provided by the operating system or by web browsers, or possibly bundled with the application, to do most of this for them. Some applications might provide a user interface to let the user override the defaults, or modify the defaults based on application needs; most rely on the defaults.

So, what this documentation should really specify is the standard behavior of OpenType text rendering systems. To some extent this is influenced by the shaping engine that the rendering system selects for text runs based on the Unicode characters in the text runs.

I propose the following changes:

① Replace the sections “UI suggestion” and “ Script/language sensitivity” in the documentation for each feature with a section “Default behavior” that contains one of the following statements (examples name some features where the statement would be used):

– This feature is disabled by default. (Examples: dlig, lnum.)

– This feature is enabled by default. (Examples: clig, liga, locl, ccmp, rlig, mark, mkmk.)

– This feature is by default enabled for certain scripts as described in shaping engine documentation, disabled otherwise. (Examples: cfar, cjct, ljmo, rkrf, pres.)

– This feature is by default enabled for vertical text, and disabled for horizontal text. (Example: vert.)

– This feature is by default enabled for horizontal text, and disabled for vertical text. (Example: kern.)

② Update the “Feature interaction” sections to clearly state what text rendering systems do by default, and what are recommendations to application developers. For example, in the description of the “vhal” feature, what is the “it” in “it deactivates the ‘kern’ feature”?

③ Rename the “Recommended implementation” section to “Usage in fonts”.

④ Rename the “Application interface” section to “Interpretation by rendering systems”. Replace any use of “application” in this section with “rendering system”.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

@NorbertLindenberg
Copy link
Author

NorbertLindenberg commented Aug 18, 2020

Lots of useful information on this page, unfortunately not up to date:
https://blog.fontlab.com/font-tech/opentype-layout/opentype-layout-feature-classification/

@PeterCon PeterCon self-assigned this Aug 25, 2020
@PeterCon
Copy link
Collaborator

An update to the feature tag registry of this sort is a good idea, but also would be a large work item. So, this doesn't seem like it should be a high priority for an OT1.8.4 update.

Also, I wonder if an change on this order should wait to see if the community starts working on a comprehensive set of shaping specs? If so, that might inform how the feature registry entries should be organized.

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

2 participants