Revamp the FeatureTagSet encoding scheme.

[garretrieger]

'default included' features can now be omitted from the set by including the ID associated with that feature. This allows the client to fully customize the feature set if the list of default included features does not match what the client's shaper is expected to require for it's current content. For example the default included 'vert' feature could be omitted if no vertical layout is being done.

---

Preview | Diff

[vlevantovsky]

I think it would be worthwhile to also clarify normative / informative nature of references. For as long as we include the normative reference to the official ISO OFF standard, we can also use informative reference to publicly available OpenType spec (with the clarifying note that the content of it is identical to OFF), and then keep using OT links for convenience.

[skef]

When I was first looking at this the "needed"/"not needed" terminology confused me because I took it to refer to the listing rather than the feature it represents. My mistake, but maybe it's worth being a bit wordier.

When I was first thinking about our decisions today I thought I would wind up recommending moving more of the "not needed" category to "needed". I talked myself out of that and I think got a better understanding of what we've arrived at. Accordingly, I think we should communicate something like the following between the section on forming the list and the appendix:

1. As the overall goal of the system is to reduce the amount of bytes transferred by omitting parts of the font that are not needed, it is best to arrive at the most accurate list of needed features as is practical.
2. A font shaper will sometimes make use of features that are not explicitly enabled, either because they are considered enabled by default (e.g. liga) or because a shaper queries the feature in certain contexts (e.g. numr). Therefore the accuracy of the feature list depends in part on the implementation of the shaper itself. Further, for this sort of contextual use, whether a feature will be queried may depend on which codepoints are to be rendered.
3. The assignment of numbered features to the two categories "needed" and "not needed" is based on research current practice in existing shapers. All features noted as "enabled by default" in the registry are included in the "not needed" category, as are any features that are used contextually (under some circumstance) according to (paper X).
4. The assignment of a feature to the "not needed" should not weigh against excluding it from a subset or augmentation (by adding to the list) if it is clear the feature will not be queried or activated. The registered features are split between the two categories so that a request with no non-explicit features specified (possibly because little is known about the shaper) is more likely to produce the same results as using the whole font. This aspect of the categorization should be considered advisory.

[garretrieger]

I think it would be worthwhile to also clarify normative / informative nature of references. For as long as we include the normative reference to the official ISO OFF standard, we can also use informative reference to publicly available OpenType spec (with the clarifying note that the content of it is identical to OFF), and then keep using OT links for convenience.

Done, I've updated the initial "Font Subset" section to reference the OFF standard and include a note that the remainder of the document references open type for convenience.

[garretrieger]

When I was first looking at this the "needed"/"not needed" terminology confused me because I took it to refer to the listing rather than the feature it represents. My mistake, but maybe it's worth being a bit wordier.

When I was first thinking about our decisions today I thought I would wind up recommending moving more of the "not needed" category to "needed". I talked myself out of that and I think got a better understanding of what we've arrived at. Accordingly, I think we should communicate something like the following between the section on forming the list and the appendix:

1. As the overall goal of the system is to reduce the amount of bytes transferred by omitting parts of the font that are not needed, it is best to arrive at the most accurate list of needed features as is practical.
2. A font shaper will sometimes make use of features that are not explicitly enabled, either because they are considered enabled by default (e.g. liga) or because a shaper queries the feature in certain contexts (e.g. numr). Therefore the accuracy of the feature list depends in part on the implementation of the shaper itself. Further, for this sort of contextual use, whether a feature will be queried may depend on which codepoints are to be rendered.
3. The assignment of numbered features to the two categories "needed" and "not needed" is based on research current practice in existing shapers. All features noted as "enabled by default" in the registry are included in the "not needed" category, as are any features that are used contextually (under some circumstance) according to (paper X).
4. The assignment of a feature to the "not needed" should not weigh against excluding it from a subset or augmentation (by adding to the list) if it is clear the feature will not be queried or activated. The registered features are split between the two categories so that a request with no non-explicit features specified (possibly because little is known about the shaper) is more likely to produce the same results as using the whole font. This aspect of the categorization should be considered advisory.

Alright, took a swing at updating the appendix to better explain how the table works plus added a note to not rely on the default inclusion decision for the purposes of selecting features.

[vlevantovsky]

Done, I've updated the initial "Font Subset" section to reference the OFF standard and include a note that the remainder of the document references open type

We also need to update normative / informative references sections to include both ISO OFF and OpenType respectively.

[garretrieger]

Done, I've updated the initial "Font Subset" section to reference the OFF standard and include a note that the remainder of the document references open type

We also need to update normative / informative references sections to include both ISO OFF and OpenType respectively.

Yeah, not sure why open-type is ending up in the normative section. It's only supposed to go there if we link to it with [[! .. ]]. I'll try and figure out what's going on.

[svgeesus]

Yeah, not sure why open-type is ending up in the normative section. It's only supposed to go there if we link to it with [[! .. ]]. I'll try and figure out what's going on.

No, [[! ]] is an override to force what would have been an informative reference to be normative. All references in normative sections are considered normative. A Note: should be an informative section, though.

[garretrieger]

Yeah, not sure why open-type is ending up in the normative section. It's only supposed to go there if we link to it with [[! .. ]]. I'll try and figure out what's going on.

No, [[! ]] is an override to force what would have been an informative reference to be normative. All references in normative sections are considered normative. A Note: should be an informative section, though.

Ah got it, that makes more sense. Unfortunately with the way we're including the open type references directly along side normative text throughout it would be pretty difficult to move them all out to Note's.

[garretrieger]

Yeah, not sure why open-type is ending up in the normative section. It's only supposed to go there if we link to it with [[! .. ]]. I'll try and figure out what's going on.

No, [[! ]] is an override to force what would have been an informative reference to be normative. All references in normative sections are considered normative. A Note: should be an informative section, though.

Ah got it, that makes more sense. Unfortunately with the way we're including the open type references directly along side normative text throughout it would be pretty difficult to move them all out to Note's.

So if we really want the opentype references to be non-normative we may just need to reference only the OFF spec at the cost of the convenience of being able to link directly to relevant sections.

[svgeesus]

the convenience of being able to link directly to relevant sections

I think that is a significant benefit and would not like to see it go.

[garretrieger]

the convenience of being able to link directly to relevant sections

I think that is a significant benefit and would not like to see it go.

At the last call we decided to leave this as is for now (w/ the open type references).

[garretrieger]

This is ready for another look now. @vlevantovsky and @svgeesus could you take another look and approve it it looks good?

[vlevantovsky]

Aside from the actual references to the spec source, I suggest removing "OpenType" references from the spec text (including one occurrence of the "open type" text, which is incorrect use of name). OpenType is a registered trademarked name, and should have a proper attribution when used. Repetitive use of the name in the IFT specification text does not really aid in anything, and seem redundant especially when it is used as part of the link to the relevant spec subclause (e.g. linking to "layout feature tags" would be just as effective as a link to "OpenType layout feature tags").

[garretrieger]

Aside from the actual references to the spec source, I suggest removing "OpenType" references from the spec text (including one occurrence of the "open type" text, which is incorrect use of name). OpenType is a registered trademarked name, and should have a proper attribution when used. Repetitive use of the name in the IFT specification text does not really aid in anything, and seem redundant especially when it is used as part of the link to the relevant spec subclause (e.g. linking to "layout feature tags" would be just as effective as a link to "OpenType layout feature tags").

Sounds good, fixed.

[vlevantovsky]

Looks good, thanks!