Re: Draft of feature encoding changes

Looks like the ISO standard is in spec ref (
https://www.specref.org/?q=open%20font%20format) so I should be able to
link it via bikeshed.

On Wed, Jun 21, 2023 at 10:58 AM Skef Iterum <siterum@adobe.com> wrote:

> Vlad - I was referring specifically to this:
> https://www.iso.org/obp/ui/en/#iso:std:iso-iec:14496:-22:ed-4:v1:en:sec:2
>
> Skef
> ------------------------------
> *From:* Vladimir Levantovsky <vladimir.levantovsky@gmail.com>
> *Sent:* Wednesday, June 21, 2023 6:24 AM
> *To:* Skef Iterum <siterum@adobe.com>
> *Cc:* Garret Rieger <grieger@google.com>; w3c-webfonts-wg <
> public-webfonts-wg@w3.org>
> *Subject:* Re: Draft of feature encoding changes
>
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
> I get it that the ISO website is confusing, but you only have to pay for
> paper copy of the standard. If you follow the blue box “download” link, it
> will bring you to the list of publicly available standards - you scroll
> down to ISO/IEC 14496-22 and download the PDF file after you click through
> the license dialog box. (Or, just use the link in my previous email.)
>
> Thank you,
> Vlad
>
>
> On Jun 20, 2023, at 10:51 PM, Skef Iterum <siterum@adobe.com> wrote:
>
> 
> The fact that there's an HTML preview with only the early sections and
> that asks for money is ... unfortunate.
>
> Skef
> ------------------------------
> *From:* Vladimir Levantovsky <vladimir.levantovsky@gmail.com>
> *Sent:* Tuesday, June 20, 2023 6:49 PM
> *To:* 'Garret Rieger' <grieger@google.com>; 'w3c-webfonts-wg' <
> public-webfonts-wg@w3.org>
> *Subject:* RE: Draft of feature encoding changes
>
>
> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>
>
> 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.
>
>