RE: Draft of feature encoding changes

Regarding ISO OFF text – it is publicly available, but it’s a PDF document that can only be downloaded in full, not making it possible to link to a particular chapter or feature.

 

I think we can utilize a dual approach where normative references section includes the reference to OFF using main ISO link (https://www.iso.org/standard/74461.html), and we can also use direct links to various OT pages offering it as informative reference with the note that the content is identical to ISO OFF standard. 

 

Also, note that the blue box on the ISO OFF page provides the information and link for free download: https://standards.iso.org/ittf/PubliclyAvailableStandards/

 

Vlad

 

 

From: Garret Rieger [mailto:grieger@google.com] 
Sent: Tuesday, June 20, 2023 8:26 PM
To: w3c-webfonts-wg (public-webfonts-wg@w3.org) <public-webfonts-wg@w3.org>
Subject: Draft of feature encoding changes

 

As discussed on the call this morning I've made a draft of some changes to how we encode the feature tag set included in the request. The PR can be found here: https://github.com/w3c/IFT/pull/149

 

Note, there are a couple deviations from what we discussed:

1. We talked about switching to referencing the ISO OFF specification instead of Microsoft's OpenType spec. However, it appears that ISO OFF isn't publicly available. So I can't easily link to it from the IFT specification. Given that, I think it's more useful for implementers to continue to link to the public OpenType one instead.
2. After thinking about the process of how we could actually add entries to the list after the initial publication I've decided we'll need some versioning mechanism to accomplish future updates since the client and server must be speaking the same encoding. For now since there is only one version, I haven't actually introduced the mechanism yet, but I did note in the appendix that the current list is version 1 and future updates may introduce a new version plus a mechanism to communicate it (likely a new field in client state and request).
3. One thing that I forgot to mention during the call which is important is that the sorted integer list is delta encoded. That means we encode the delta between an entry in the list and the previous entry instead of the absolute value. This means generally most entries should encode in one byte even if we have IDs that are greater than 127. I made one small change to help here and moved the ss01-ss20 and cv01-cv99 encodings to the end of ID space so they don't add large gaps between other unrelated feature tags. With that change everything other than those two groups now have ID's less than 127 which guarantees they will encode in one byte.