simoncozens / feature-tags

A curated guide to the OpenType Specification feature tag repository

OpenType Feature Database

Want to know what all of the OpenType features do? What order they're processed in? How to access them in client software? What code should go in each feature? The OpenType Feature Database has you covered!

The idea of the Feature Database is a kind of "user's guide" to go side-by-side with the more formal feature descriptions in the OpenType spec, giving more background and describing (and demonstrating) how the features are used in practice.

Omissions and Suggestions

If you are aware of:

• Ways to access a feature in a major client application
• Common uses of a feature
• Script-specific behaviour of a feature
• Shaper-specific behaviour of a feature

not listed in the database, or mistakes in the text, please file an issue. (Or better, a pull request.)

License

This data is licensed under the Apache license. See LICENSE.

feature-tags's Issues

Processing phases

Some of your processing phase assignments don’t make sense to me, especially the ‘Common’ phase features, which include both GPOS and GSUB features (and those GSUB features includes ccmp and locl, which should be in the pre-processing phase).

I would expect to see all GSUB processed before any GPOS, and for that to be the case for all scripts.

If I select a script that is processed by USE, I am confused because your processing phases do not correspond to the USE processing phases.

If I select dev2 script, nothing shows up in any of the processing phases except Orthographic. Spot checked bng2 and found the same issue, so suspect this might be a problem for all the Indic shaping engine scripts?

Add more state metadata

Current there are 123 *.yml files, broken down as:

• 44 Discretionary
• 42 Required
• 5 Default
• 32 with no state

Eg, A popular FeatureTag with unspecified state is tnum and pnum, while lnum and onum are marked discretionary.

Also, tags like cv02 aren't easy to grep for.

Comments on 'rphf'

In Devanagari, non-final ra+virama should be substituted by reph.

This is true of many Indic scripts; why specify one without saying it’s just an example? Reph only applies initially: “non-final” is too broad. Not every initial ra+virama should be substituted by reph: that’s just the default behavior in some scripts.

This feature replaces consonant+virama with the reph form of the consonant. [...] The context of application is restricted to a syllabic cluster.

In USE, the context of application is further restricted to the first three glyphs in a cluster. It doesn’t check whether the glyphs are for consonants or viramas.

Meta: Add links to live site

Tiny thing but links to https://simoncozens.github.io/feature-tags/ could be added to top of README and the repo metadata itself :)

'fin2', 'fin3', and 'med2' are confusing

The descriptions of the Syriac topographical features are confusing. Behdad explains it well:

 * 'fin2' and 'fin3' are alternate versions of 'isol' when appearing at the
end of the word.

 * 'med2' is an alternate version of 'fina' when not appearing at the end of
the word.

How confusing...

The descriptions of 'fin2' and 'fin2' say “The Syriac letter alaph (U+0710) has multiple final forms”. Although this is true, it is not relevant to 'fin2' and 'fin3', which are not final forms in the topographical sense.

'fin2' selects an alternative isolated form, but its example string is “ܒܐ”, in which the alaph has a final form.

The description of 'med2' says “The Syriac letter alaph (U+0710) is not normally a joining character but can join to the right in the middle of a word if the preceding character is right-joining.” In fact, the Syriac alaph is a right-joining letter, just like an Arabic alef.

The examples use Noto Sans Syriac, which uses the Estrangela style by default. Estrangela is relatively simple: it does not distinguish its 'med2' and 'fina' forms, nor its 'fin2', 'fin3', and 'isol' forms. It is therefore a bad font for the examples. A West Syriac font would make the examples clearer.

'abvf' example does not match description

The description for 'abvf' explains how U+17BE KHMER VOWEL SIGN OE is split into a top part and a left part. However, the rendered example only includes the top part.

The original Noto Sans Khmer does include the left part though. Maybe something went wrong in the subsetter.

LICENSE, README, etc

Please add standard project files :)

Permalinks

I went to the page, popped "zero" into the first 'filter by tag' input, and then wanted to share the link to a colleague to tell them about that feature... but the URL didn't update with my query, so there's no permalink to share.

'rand' example does not work

The example for 'rand' specifies font-feature-settings: 'rand' 1. In HarfBuzz’s implementation, that requests glyph 1 from the alternate substitution rule. To enable randomness, set the value to 255. However, since HarfBuzz enables 'rand' by default, it would be even better to not use font-feature-settings at all, and just let it work automatically.

'afrc' example does not match description

The description of 'afrc' says it is for nut fractions, but the example uses a font in which 'afrc' produces a mutton fraction.

'cfar' should not be discouraged

DaunPenh uses 'cfar' to control which subjoined consonant is below the other. Both Uniscribe and HarfBuzz support it.

For example, here is ⟨ង្រ្គ⟩ (ngrkô):

Compare ⟨ង្គ្រ⟩ (ngkrô):

It seems like a useful feature. Why do you say it is discouraged? Although it is possible to get the same behavior by using a contextual lookup in 'blws', by that logic most features are redundant and should be discouraged. When the shaper’s cluster analysis allows the font to use a feature with a simpler, non-contextual lookup type, I think that feature should be encouraged.