From behdad at behdad.org Mon Apr 1 09:58:12 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 1 Apr 2024 01:58:12 -0600 Subject: [MPEG-OTSPEC] format field names In-Reply-To: References: Message-ID: I personally support this change. Thank you Peter, behdad http://behdad.org/ On Sat, Mar 30, 2024 at 11:04?AM Peter Constable via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > I?d like to hear other?s opinions: > > > > While preparing revisions for OpenType 1.9.1 and proposed revisions to OFF > 5th Edn WD, I noticed in sections for OT Layout tables that some tables > that have a format field have a field name that reflects the table it is > contained in. > > > > - GPOS lookup subtables: ?posFormat? > - GSUB lookup subtables: ?substFormat? > - Coverage tables: ?coverageFormat? > - CaretValue tables: ?caretValueFormat? > - Anchor tables: ?anchorFormat? > - BaseCoord tables: ?baseCoordFormat? > > > > This convention isn?t followed elsewhere in the spec: > > - not in CFF / CFF2 FontDICTSelect > - not in cmap subtables > - not in COLR Paint, ClipList or ClipBox tables > - not in DSIG SignatureRecord > - not in ItemVariationStore or in DeltaSetIndexMap tables > > > > I?m inclined to rename fields like ?posFormat? to simply ?format?, and > have started to implement that in draft content for OT 1.9.1 > . > But this is nothing more than wanting consistency?it?s not as though having > redundant info in the field names creates confusion. > > > > Anyone with a strong opinion for making these field name changes, or for _ > *not*_ making these changes? > > > > > > > > Peter > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsheeter at google.com Tue Apr 2 02:52:15 2024 From: rsheeter at google.com (Rod Sheeter) Date: Mon, 1 Apr 2024 17:52:15 -0700 Subject: [MPEG-OTSPEC] format field names In-Reply-To: References: Message-ID: +1, good change. Cheers, Rod S. On Mon, Apr 1, 2024 at 12:58?AM Behdad Esfahbod via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > I personally support this change. > > Thank you Peter, > > behdad > http://behdad.org/ > > > On Sat, Mar 30, 2024 at 11:04?AM Peter Constable via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > >> I?d like to hear other?s opinions: >> >> >> >> While preparing revisions for OpenType 1.9.1 and proposed revisions to >> OFF 5th Edn WD, I noticed in sections for OT Layout tables that some >> tables that have a format field have a field name that reflects the table >> it is contained in. >> >> >> >> - GPOS lookup subtables: ?posFormat? >> - GSUB lookup subtables: ?substFormat? >> - Coverage tables: ?coverageFormat? >> - CaretValue tables: ?caretValueFormat? >> - Anchor tables: ?anchorFormat? >> - BaseCoord tables: ?baseCoordFormat? >> >> >> >> This convention isn?t followed elsewhere in the spec: >> >> - not in CFF / CFF2 FontDICTSelect >> - not in cmap subtables >> - not in COLR Paint, ClipList or ClipBox tables >> - not in DSIG SignatureRecord >> - not in ItemVariationStore or in DeltaSetIndexMap tables >> >> >> >> I?m inclined to rename fields like ?posFormat? to simply ?format?, and >> have started to implement that in draft content for OT 1.9.1 >> . >> But this is nothing more than wanting consistency?it?s not as though having >> redundant info in the field names creates confusion. >> >> >> >> Anyone with a strong opinion for making these field name changes, or for _ >> *not*_ making these changes? >> >> >> >> >> >> >> >> Peter >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Tue Apr 2 07:06:16 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Tue, 02 Apr 2024 01:06:16 -0400 Subject: [MPEG-OTSPEC] mapping out dmap Message-ID: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> Should dmap be able to delete glyphs from cmap for a particular subfont? Several people have said they would like that feature. If so, should it do so with a -1 glyphID? (i.g. 65535 for a 16-bit font and 2^24 - 1 = 16777215 for a 24-bit glyph ID, and, should it ever be supported, 4294967295 for a 32-bit glyphID? The value would depend on table and version/format. Are we OK with format 14 and dmap at this point? Thanks, liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From vladimir.levantovsky at gmail.com Tue Apr 2 19:58:40 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Tue, 2 Apr 2024 13:58:40 -0400 Subject: [MPEG-OTSPEC] AHG meeting agenda for Tuesday, April 9 Message-ID: Dear all, The AHG meeting is a week away, and this will be our last opportunity to review the drafts of input submissions in preparation for the SC29/WG3 meeting at the end of April. So far, these are the tentative agenda topics for AHG to discuss: - DMAP updates: https://github.com/harfbuzz/boring-expansion- spec/blob/main/iso_docs/WG03-dmap-2024-03.pdf - 'fvar' changes and clarifications for improved handling of duplicate axis names: https://github.com/harfbuzz/boring-expansion- spec/blob/main/iso_docs/WG03-fvar-2024-03.pdf - changes and clarifications to 'hdmx', LTSH, and JSTF tables based on public feedback: https://github.com/harfbuzz/boring-expansion- spec/blob/main/iso_docs/WG03-varc-and-other-updates-03.pdf - updates to "Feature Variations: New LookupVariation Mechanism" and updated condition negation proposal: https://github.com/ adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf - updated VARC hint guidance for CFF2: https://github.com/ adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf - CFF2 hint ordering: https://github.com/adobe-type-tools/opentype- spec-drafts/blob/main/cff2hintorder.pdf - various updates and synchronization between OFF and OT texts (including proposed revisions to 'palt' and 'kern' documentation (see https://github.com/ jcitpc/CJKFont/blob/main/docs/palt_kern.md ) - versioning of the ConditionSet table and related changes introduced in the most recent revision of the Working Draft (subclause 6.2.9). Please let me know if I missed anything. Also, if you make any updates to current documents - please reply to this email with either the updated links or notifications if / when any content updates have been made in place, without changing the document links / locations. As a reminder, the next SC29/WG3 meeting will be held on April 22-26. The input submission deadlines for the next WG meeting are as follows: - April 15: deadline for registration of input contributions; - April 17: upload deadline for registered input contributions. The direct emails with the meeting invite including Zoom info will follow soon. Again, due to public availability of the AHG list archive, this info will not be shared on the AHG email list - please contact me directly if you would like to be added as an invitee and have not been a participant in any prior AHG meetings. Thank you, Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Wed Apr 3 08:46:14 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Wed, 03 Apr 2024 02:46:14 -0400 Subject: [MPEG-OTSPEC] hdmx, vdmx, LTSH - deprecate or update? JSTF too? Message-ID: Hello! Right now, the Google Fonts propsal updates LTSH to support 24-bit glyphIDs (and, if necessary, 32-bit offsets of course). hdmx just had a description updated to note that numGlyphs can come from the new MAXP table. I was actioned to ask this list, should we deprecate hdmx, LTSH, vdmx, or update them? And what about JSTF? Deprecate, or update, or both? liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/OFF/OT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From liam at fromoldbooks.org Thu Apr 4 06:44:59 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Thu, 04 Apr 2024 00:44:59 -0400 Subject: [MPEG-OTSPEC] fvar and hoi updated Message-ID: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> I keep thinking of koi carp for some reason. https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs The new text says what happens (based on what Harfbuzz does) if the min/max values for duplicated axisTags are different. (scroll down past the list of files to get to WG03-fvar-2024-04.pdf and the Markdown and LibreOffice files) liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From pconstable at microsoft.com Thu Apr 4 19:51:00 2024 From: pconstable at microsoft.com (Peter Constable) Date: Thu, 4 Apr 2024 17:51:00 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] fvar and hoi updated In-Reply-To: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> References: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> Message-ID: Hi, Liam: "The default (initial value) shall be taken from the non-hidden axis entry." This doesn't make sense to me. Text can't be laid out or glyphs rasterized without a full specification of an instance. There isn't some initial state that layout or rasterization processing begins with that doesn't include an instance specification. A statement I would expect but don't see is that normalization is calculated independently for each axis using its min/default/max values in conjunction with the "user" coordinate for each axis (clamped to the axis min/max range). Peter -----Original Message----- From: mpeg-otspec On Behalf Of Liam R. E. Quin via mpeg-otspec Sent: Wednesday, April 3, 2024 9:45 PM To: MPEG OT Spec list Subject: [EXTERNAL] [MPEG-OTSPEC] fvar and hoi updated I keep thinking of koi carp for some reason. https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs The new text says what happens (based on what Harfbuzz does) if the min/max values for duplicated axisTags are different. (scroll down past the list of files to get to WG03-fvar-2024-04.pdf and the Markdown and LibreOffice files) liam -- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org/ _______________________________________________ mpeg-otspec mailing list mpeg-otspec at lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec From dcrossland at google.com Thu Apr 4 19:56:45 2024 From: dcrossland at google.com (Dave Crossland) Date: Thu, 4 Apr 2024 11:56:45 -0600 Subject: [MPEG-OTSPEC] [EXTERNAL] fvar and hoi updated In-Reply-To: References: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> Message-ID: On Thu, Apr 4, 2024, 11:51?AM Peter Constable via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > Hi, Liam: > > "The default (initial value) shall be taken from the non-hidden axis > entry." > > This doesn't make sense to me. Text can't be laid out or glyphs rasterized > without a full specification of an instance. > How is that not a full specification of an instance...? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorp at lorp.org Thu Apr 4 21:20:16 2024 From: lorp at lorp.org (Laurence Penney) Date: Thu, 4 Apr 2024 20:20:16 +0100 Subject: [MPEG-OTSPEC] fvar and hoi updated In-Reply-To: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> References: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> Message-ID: WG03-fvar-2024-04.pdf I?ve done a rewrite, which resolves a few issues. * "font to use multiple" -> "font to have multiple" * "user interfaces or API access" -> "user interfaces and API access" * It was not defined which axis?s range and defaultValue would be used if all axes are hidden. * To avoid scope issues, I?ve made it all one paragraph. * Clamping noted last, since it may override what happened with setting default. * Also added a final sentence clarifying that independent adjustment is never allowed. ---- For smooth animation, and for non-linear interpolation, it may be necessary for a font to have multiple axes with the same axisTag. In such a font, at most one of those axes shall be visible (i.e. have its HIDDEN_AXIS bit set to zero). The VariationAxisRecord for such a visible axis shall appear first in the array of axes, before the records for any of the other axes with that same axisTag. For an axisTag used by multiple axes, the range of values exposed to user interfaces and API access for that axisTag shall be taken from the minValue and maxValue of the first axis having that axisTag; similarly, if a user interface or API requires a default, then the defaultValue of the first axis having that axisTag shall be used. Where the ranges of the axes with a given axisTag differ in minValue or maxValue, the value shall be clamped to be within the minValue and maxValue of each axis. Independent adjustment of multiple axes with the same axisTag must not be offered or processed under any circumstances. - Laurence > On 4 Apr 2024, at 05:44, Liam R. E. Quin via mpeg-otspec wrote: > > I keep thinking of koi carp for some reason. > > https://github.com/harfbuzz/boring-expansion-spec/tree/main/iso_docs > > The new text says what happens (based on what Harfbuzz does) if the > min/max values for duplicated axisTags are different. > > (scroll down past the list of files to get to > WG03-fvar-2024-04.pdf > and the Markdown and LibreOffice files) > > liam > > > -- > Liam Quin, https://www.delightfulcomputing.com/ > Available for XML/Document/Information Architecture/XSLT/ > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec From liam at fromoldbooks.org Fri Apr 5 08:34:03 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Fri, 05 Apr 2024 02:34:03 -0400 Subject: [MPEG-OTSPEC] fvar and hoi updated In-Reply-To: References: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> Message-ID: On Thu, 2024-04-04 at 20:20 +0100, Laurence Penney wrote: > WG03-fvar-2024-04.pdf > > I?ve done a rewrite, which resolves a few issues. Thank you for this, that's awesome. I'd remove "under any circumstances" but otherwise looks good to me. I think what i?m hearing is that there are no objections so far overall to the fvar clarifications, but the wording needs (or needed) cleaning up more, so that's a good place to be. The wording needs to match the implementations and the way existing fonts work, or at least not outlaw that, but harfbuzz i think wants exactly one (the first) axis of a duplicated set to be the visible/main one, and that seems to work with your text. We may need to add, For interoperability, the first such axis should be visible. Thanks, liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From skef at skef.org Fri Apr 5 16:10:55 2024 From: skef at skef.org (Skef Iterum) Date: Fri, 5 Apr 2024 07:10:55 -0700 Subject: [MPEG-OTSPEC] Updates to Adobe proposals Message-ID: <2f222515-b729-4551-9e23-b5ed06f6560e@skef.org> I have updated Adobe's current proposals in the following way: 1. varchintguide.pdf has proper cross-references and looks more generally like a standard ISO proposal. Liam also took a look at the draft and provided valuable feedback. https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/varchintguide.pdf 2. newfeatvar_spec.pdf has been substantially rewritten to a) be more generally like a standard ISO spec, b) incorporate the material in negation.pdf, and c) reorder and rework the material on conditions, condition sets, and the Feature Variations mechanism. The latter was partly because I found it was clearer to discuss conditions before variations but also to prepare for the addition of conditional variable composites (which I understand Behdad is working on). Added or changed text is highlighted, other text exists in the current specification, although not always in the same place. https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/newfeatvar_spec.pdf 3. negation.pdf is now retired (having been incorporated into newfeatvar_spec.pdf). 4. As we have discussed Peter is going to work the equivalent of the content of cff2hintorder.pdf into his updates, so that is also retired. I'm working on the requested test font. Thanks, Skef -------------- next part -------------- An HTML attachment was scrubbed... URL: From eb2mmrt at gmail.com Fri Apr 5 16:37:00 2024 From: eb2mmrt at gmail.com (MURATA) Date: Fri, 5 Apr 2024 23:37:00 +0900 Subject: [MPEG-OTSPEC] Updated Working Draft text is now available for public review In-Reply-To: References: Message-ID: Vladimir, Thank you for the updated text. These days, ISO is much more strict than before. The text of the standard is strongly required to follow ISO/IEC Directives, Part 2 , and ISO House Style . There are 43 occurrences of "may not" in the current text, but "may not" is prohibited (see 7.6 in the directives). There are 544 occurrences of ?must? in the current text, but "must" is allowed only when it represents external constraints (e.g., legal requirements and natural laws). All these expressions have to be rewritten. I guess that many other editorial requirements will be required. Regards, Makoto 2024?3?21?(?) 0:38 Vladimir Levantovsky via mpeg-otspec < mpeg-otspec at lists.aau.at>: > Dear all, > > I am pleased to let you know that the updated text of the WD of ISO/IEC > 14496-22 5th edition Open font format > is > now available for download. > Your review and comments would be much appreciated. > > Thank you, > Vladimir > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -- -- ???????????????????? ?? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Fri Apr 5 17:16:00 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Fri, 5 Apr 2024 11:16:00 -0400 Subject: [MPEG-OTSPEC] Updated Working Draft text is now available for public review In-Reply-To: References: Message-ID: <813DBAF0-A629-4288-8710-C952327FCC70@gmail.com> An HTML attachment was scrubbed... URL: From skef at skef.org Sun Apr 7 17:02:43 2024 From: skef at skef.org (Skef Iterum) Date: Sun, 7 Apr 2024 08:02:43 -0700 Subject: [MPEG-OTSPEC] Interaction between delta-set indices and non-variable values Message-ID: <38b734a5-ef69-4f27-aa6b-83208fde56d8@skef.org> I've been looking through the spec and want to ask a question about delta-set indices (7.2.3.1 in Vladimir's latest). The whole point of delta-set indices is: * They are arrays, indexed by some external field (generally a GID) * They allow the outer, inner pairs to be packed into 3, 2, or (I think) even 1 byte when that's possible. OK, but these values map into an Item Variation Store, and that section (7.2.3.2) says: A complete delta-set index involves an outer-level index into the ItemVariationData subtable array, plus an inner-level index to a delta-set row within that subtable. A special meaning is assigned to a delta-set index 0xFFFF/0xFFFF (that is, outer-level and inner-level portions are both 0xFFFF): this is used to indicate that there is no variation data for a given item. Functionally, this would be equivalent to referencing delta-set data consisting of only deltas of 0 for all regions. So 0xFFFF,0xFFFF is used as the index pair for something that doesn't vary. And you'll often need these (or some substitute) in a delta-set index because all the elements (e.g. glyphs) are typically represented in a delta-set index. However, just on the face of it it seems like you'll need 16 bits of representation for the outer and 16 for the inner in the delta-set index just because those are both 0xFFFF. Is that wrong, or did our ancestors not notice this interaction? (I'm hoping it's wrong.) Skef (One can add a zero-delta row to some subtable in the IVS and just use its inner and outer indices to work around this, but obviously that's not ideal.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Mon Apr 8 21:54:58 2024 From: skef at skef.org (Skef Iterum) Date: Mon, 8 Apr 2024 12:54:58 -0700 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation Message-ID: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> A note on conditions as defined in WG03-varc-and-other-updates-03.pdf (up for review tomorrow morning). When I sketched out the VARC condition idea I had them arranged in if/else if/.../else sequences. From my reading of the document they're currently in "if" form -- a condition set can be attached to a component and if it is it will only be used if the condition set evaluates to true. There's nothing wrong with that semantic; it may be preferable because it's simpler. However, the most common case with this system is that you want one shape to render in some region of design space (defined by the condition set) and another shape to render outside of that. And negating a condition /set/ can be expensive and/or tricky. So I would recommend that one of these two things change: * The if/else if/.../else semantic is restored * Some way of negating a condition set is added to the specification We talked about the possibility of condition set negation in a previous meeting but didn't come to any conclusions. It's tricky because the table has no versioning. If we wanted to hack negations into the current format the way to do that might be to add a new condition format (possibly 5 if newfeatvar_spec.pdf is accepted) that looks something like: ConditionTableFormat5 *Type??????????????????? Name Description* uint16????????????????? Format Format (set to 5) When present in a condition set this condition indicates the set should apply when at least one of the other conditions is false and not otherwise. That is, it makes the condition set apply when it would normally not and vice-versa. There should be at most one format 5 condition in a condition set and it should be the first. If this is preferred it could be used to replace/simplify the trueLookupIndexListOffset/falseLookupIndexListOffset pair in the LookupCondition record of newfeatvar_spec.pdf to just lookupIndexListOffset (because one could just follow the record with the "positive" condition set with another record with the negated one when needed). Skef -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Thu Apr 11 10:18:29 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 02:18:29 -0600 Subject: [MPEG-OTSPEC] Interaction between delta-set indices and non-variable values In-Reply-To: <38b734a5-ef69-4f27-aa6b-83208fde56d8@skef.org> References: <38b734a5-ef69-4f27-aa6b-83208fde56d8@skef.org> Message-ID: Hi Skef, On Sun, Apr 7, 2024 at 9:02?AM Skef Iterum via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > I've been looking through the spec and want to ask a question about > delta-set indices (7.2.3.1 in Vladimir's latest). > > The whole point of delta-set indices is: > > - They are arrays, indexed by some external field (generally a GID) > - They allow the outer, inner pairs to be packed into 3, 2, or (I > think) even 1 byte when that's possible. > > OK, but these values map into an Item Variation Store, and that section > (7.2.3.2) says: > > A complete delta-set index involves an outer-level index into the > ItemVariationData subtable array, plus an inner-level index to a delta-set > row within that subtable. A special meaning is assigned to a delta-set > index 0xFFFF/0xFFFF (that is, outer-level and inner-level portions are both > 0xFFFF): this is used to indicate that there is no variation data for a > given item. Functionally, this would be equivalent to referencing delta-set > data consisting of only deltas of 0 for all regions. > > So 0xFFFF,0xFFFF is used as the index pair for something that doesn't > vary. And you'll often need these (or some substitute) in a delta-set index > because all the elements (e.g. glyphs) are typically represented in a > delta-set index. > > However, just on the face of it it seems like you'll need 16 bits of > representation for the outer and 16 for the inner in the delta-set index > just because those are both 0xFFFF. > > Is that wrong, or did our ancestors not notice this interaction? (I'm > hoping it's wrong.) > The ancestor did know this indeed. Note that the 0xFFFF/0xFFFF convention was added around 2019; after the initial varfonts release in 2016. > Skef > > (One can add a zero-delta row to some subtable in the IVS and just use its > inner and outer indices to work around this, but obviously that's not > ideal.) > Indeed. That's the preferred solution when DeltaSetIndexMap is involved. And exactly why the fonttools VarStore.optimize() takes a parameter for whether to use 0xFFFF/0xFFFF or not. If we were to design this from scratch, I would have suggested any "all 0xFF bytes" would mean no variation. But that's not backwards compatible. You might ask where is 0xFFFF/0xFFFF used anyway. It was a rather speculative addition. However, it's nice to be able to say "any indices into DeltSetMapIndex beyond the number of items get the value of 0xFFFF/0xFFFF" instead of saying they don't vary... This arises in avar2 for example. b -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Thu Apr 11 10:20:54 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 02:20:54 -0600 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> Message-ID: Hi Skef, I'm a bit uncomfortable encoding if/else in VARC. As you said on the call, the current design seems like a practical compromise. As for negation, we *can* add a flag to the component to negate the condition. Maybe that's the right approach. But I feel like the conditionSet itself should contain the negation. That would reduce sharing though. A "negate the rest" condition type sounds good to me. behdad http://behdad.org/ On Mon, Apr 8, 2024 at 1:55?PM Skef Iterum via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > A note on conditions as defined in WG03-varc-and-other-updates-03.pdf (up > for review tomorrow morning). > > When I sketched out the VARC condition idea I had them arranged in if/else > if/.../else sequences. From my reading of the document they're currently in > "if" form -- a condition set can be attached to a component and if it is it > will only be used if the condition set evaluates to true. > > There's nothing wrong with that semantic; it may be preferable because > it's simpler. However, the most common case with this system is that you > want one shape to render in some region of design space (defined by the > condition set) and another shape to render outside of that. And negating a > condition *set* can be expensive and/or tricky. So I would recommend that > one of these two things change: > > - The if/else if/.../else semantic is restored > - Some way of negating a condition set is added to the specification > > We talked about the possibility of condition set negation in a previous > meeting but didn't come to any conclusions. It's tricky because the table > has no versioning. If we wanted to hack negations into the current format > the way to do that might be to add a new condition format (possibly 5 if > newfeatvar_spec.pdf is accepted) that looks something like: > > ConditionTableFormat5 > > *Type Name Description* > > uint16 Format Format (set to > 5) > > When present in a condition set this condition indicates the set should > apply when > at least one of the other conditions is false and not otherwise. That is, > it makes the > condition set apply when it would normally not and vice-versa. There > should be at > most one format 5 condition in a condition set and it should be the first. > > If this is preferred it could be used to replace/simplify the > trueLookupIndexListOffset/falseLookupIndexListOffset pair in the > LookupCondition record of newfeatvar_spec.pdf to just lookupIndexListOffset > (because one could just follow the record > with the "positive" condition set with another record with the negated one > when needed). > > Skef > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Thu Apr 11 14:26:55 2024 From: skef at skef.org (Skef Iterum) Date: Thu, 11 Apr 2024 05:26:55 -0700 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> Message-ID: <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> I'm still trying to think through all of this stuff, but I tentatively think that if we added a hack to negate a condition set then we'll have enough. To see the issues involved it may be easiest to work backwards. It's not an accident that most programming languages contain the combination of boolean expressions (with AND, OR, NOT and some equivalent of parentheses) + an if/else if/.../else structure. The former lets you express anything you need to, typically quite compactly. The latter expresses a set of alternatives such that it's guaranteed you'll only get one of them. With arbitrary boolean expressions it's easy to fake up the if/else if/else. If you would have had if A ??? R else if B ??? S else if C ??? T else if D ??? U else ??? V you can just do if A ??? R if ~A & B ??? S if ~A & ~B & C ??? T if ~A & ~B & ~C & D ??? U if ~A & ~B & ~C & ~D ??? V at the cost of a bit more computation (typically). This kind of generality was (presumably) thought to be /over/-general for variable fonts, and I don't disagree. But it's worth noting what you lose if you lack /both/ arbitrary boolean expressions /and/ if/else if/.../else. Say we add condition set negation. Then if you have a fairly typical case like the following (where brackets indicate a set) if [A & C] ??? R else ??? S You can replace that with if [A & C] ??? R if ~[A & C] ??? S However, /at a single level/ that doesn't extend further. So if you have if [A & C] ??? R else if [D & E] ??? S else ??? T (which is just adding a third case), there's no easy way to adapt that into pure "if" conditions using the tools available. And that's what I've been worried about -- it seems annoying not to be able to have three alternatives (with non-trivial conditions) spread out over the design space. However, it seems like you can accomplish the equivalent with an extra level. Assume R, S, and T are "existing" components. Then you can just do a: if [D & E] ??? S if ~[D & E] ??? T b: if [A & C] ??? R if ~[A & C] ??? a Now b has the right qualities. In effect, a sometimes has the "wrong" contents when [A & C] applies but you never /see/ it in that case. So like I said I want to think about this a bit more but I tentatively think the thing to do is add means of negating the condition set (and I think the Format 5 condition hack would be fine for that, actually), and remove the "else" from the lookup-based feature variations mechanism to simplify it. Skef On 4/11/24 01:20, Behdad Esfahbod wrote: > Hi Skef, > > I'm a bit uncomfortable encoding if/else in VARC. As you said on the > call, the current design seems like a practical compromise. As for > negation, we *can* add a flag to the component to negate the > condition. Maybe that's the right approach. But I feel like the > conditionSet itself should contain the negation. That would reduce > sharing though. > > A "negate the rest" condition type sounds good to me. > > behdad > http://behdad.org/ > > > On Mon, Apr 8, 2024 at 1:55?PM Skef Iterum via mpeg-otspec > wrote: > > A note on conditions as defined in > WG03-varc-and-other-updates-03.pdf (up for review tomorrow morning). > > When I sketched out the VARC condition idea I had them arranged in > if/else if/.../else sequences. From my reading of the document > they're currently in "if" form -- a condition set can be attached > to a component and if it is it will only be used if the condition > set evaluates to true. > > There's nothing wrong with that semantic; it may be preferable > because it's simpler. However, the most common case with this > system is that you want one shape to render in some region of > design space (defined by the condition set) and another shape to > render outside of that. And negating a condition /set/ can be > expensive and/or tricky. So I would recommend that one of these > two things change: > > * The if/else if/.../else semantic is restored > * Some way of negating a condition set is added to the specification > > We talked about the possibility of condition set negation in a > previous meeting but didn't come to any conclusions. It's tricky > because the table has no versioning. If we wanted to hack > negations into the current format the way to do that might be to > add a new condition format (possibly 5 if newfeatvar_spec.pdf is > accepted) that looks something like: > > ConditionTableFormat5 > > *Type Name??????????????????????????????? Description* > > uint16 Format????????????????????????????? Format (set to 5) > > When present in a condition set this condition indicates the > set should apply when > at least one of the other conditions is false and not > otherwise. That is, it makes the > condition set apply when it would normally not and vice-versa. > There should be at > most one format 5 condition in a condition set and it should > be the first. > > If this is preferred it could be used to replace/simplify the > trueLookupIndexListOffset/falseLookupIndexListOffset pair in the > LookupCondition record of newfeatvar_spec.pdf to just > lookupIndexListOffset (because one could just follow the record > with the "positive" condition set with another record with the > negated one when needed). > > Skef > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Thu Apr 11 17:44:49 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 09:44:49 -0600 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> Message-ID: Thanks Skef. I think I found the right approach for this (taking ideas from COLRv1 paint tree / graph). Ignoring your other proposals, we add these: We add new Condition's that implement AND of a bunch of Conditions (like the current ConditionSet does), another for OR, and another for NEGATE: struct ConditionAnd { uint16 format; // 2 uint16 conditionCount; // Number of conditions for this conjunction expression. Offset32To conditionOffsets[conditionCount]; } struct ConditionOr { uint16 format; // 3 uint16 conditionCount; // Number of conditions for this disjunction expression. Offset32To conditionOffsets[conditionCount]; } struct ConditionNegate { uint16 format; // 4 Offset32To condition; } WDYT? behdad http://behdad.org/ On Thu, Apr 11, 2024 at 6:26?AM Skef Iterum wrote: > I'm still trying to think through all of this stuff, but I tentatively > think that if we added a hack to negate a condition set then we'll have > enough. > > To see the issues involved it may be easiest to work backwards. It's not > an accident that most programming languages contain the combination of > boolean expressions (with AND, OR, NOT and some equivalent of parentheses) > + an if/else if/.../else structure. The former lets you express anything > you need to, typically quite compactly. The latter expresses a set of > alternatives such that it's guaranteed you'll only get one of them. > > With arbitrary boolean expressions it's easy to fake up the if/else > if/else. If you would have had > > if A > R > else if B > S > else if C > T > else if D > U > else > V > > you can just do > > if A > R > if ~A & B > S > if ~A & ~B & C > T > if ~A & ~B & ~C & D > U > if ~A & ~B & ~C & ~D > V > > at the cost of a bit more computation (typically). > > This kind of generality was (presumably) thought to be *over*-general for > variable fonts, and I don't disagree. But it's worth noting what you lose > if you lack *both* arbitrary boolean expressions *and* if/else > if/.../else. Say we add condition set negation. Then if you have a fairly > typical case like the following (where brackets indicate a set) > > if [A & C] > R > else > S > > You can replace that with > > if [A & C] > R > if ~[A & C] > S > > However, *at a single level* that doesn't extend further. So if you have > > if [A & C] > R > else if [D & E] > S > else > T > > (which is just adding a third case), there's no easy way to adapt that > into pure "if" conditions using the tools available. And that's what I've > been worried about -- it seems annoying not to be able to have three > alternatives (with non-trivial conditions) spread out over the design > space. > > However, it seems like you can accomplish the equivalent with an extra > level. Assume R, S, and T are "existing" components. Then you can just do > > a: > if [D & E] > S > if ~[D & E] > T > > b: > if [A & C] > R > if ~[A & C] > a > > Now b has the right qualities. In effect, a sometimes has the "wrong" > contents when [A & C] applies but you never *see* it in that case. > > So like I said I want to think about this a bit more but I tentatively > think the thing to do is add means of negating the condition set (and I > think the Format 5 condition hack would be fine for that, actually), and > remove the "else" from the lookup-based feature variations mechanism to > simplify it. > > Skef > On 4/11/24 01:20, Behdad Esfahbod wrote: > > Hi Skef, > > I'm a bit uncomfortable encoding if/else in VARC. As you said on the call, > the current design seems like a practical compromise. As for negation, we > *can* add a flag to the component to negate the condition. Maybe that's the > right approach. But I feel like the conditionSet itself should contain the > negation. That would reduce sharing though. > > A "negate the rest" condition type sounds good to me. > > behdad > http://behdad.org/ > > > On Mon, Apr 8, 2024 at 1:55?PM Skef Iterum via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > >> A note on conditions as defined in WG03-varc-and-other-updates-03.pdf (up >> for review tomorrow morning). >> >> When I sketched out the VARC condition idea I had them arranged in >> if/else if/.../else sequences. From my reading of the document they're >> currently in "if" form -- a condition set can be attached to a component >> and if it is it will only be used if the condition set evaluates to true. >> >> There's nothing wrong with that semantic; it may be preferable because >> it's simpler. However, the most common case with this system is that you >> want one shape to render in some region of design space (defined by the >> condition set) and another shape to render outside of that. And negating a >> condition *set* can be expensive and/or tricky. So I would recommend >> that one of these two things change: >> >> - The if/else if/.../else semantic is restored >> - Some way of negating a condition set is added to the specification >> >> We talked about the possibility of condition set negation in a previous >> meeting but didn't come to any conclusions. It's tricky because the table >> has no versioning. If we wanted to hack negations into the current format >> the way to do that might be to add a new condition format (possibly 5 if >> newfeatvar_spec.pdf is accepted) that looks something like: >> >> ConditionTableFormat5 >> >> *Type Name Description* >> >> uint16 Format Format (set >> to 5) >> >> When present in a condition set this condition indicates the set should >> apply when >> at least one of the other conditions is false and not otherwise. That is, >> it makes the >> condition set apply when it would normally not and vice-versa. There >> should be at >> most one format 5 condition in a condition set and it should be the first. >> >> If this is preferred it could be used to replace/simplify the >> trueLookupIndexListOffset/falseLookupIndexListOffset pair in the >> LookupCondition record of newfeatvar_spec.pdf to just lookupIndexListOffset >> (because one could just follow the record >> with the "positive" condition set with another record with the negated >> one when needed). >> >> Skef >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorp at lorp.org Thu Apr 11 21:17:30 2024 From: lorp at lorp.org (Laurence Penney) Date: Thu, 11 Apr 2024 20:17:30 +0100 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> Message-ID: <76925532-EEC3-4DB1-9B69-1E8B14A006C9@lorp.org> Personally I like this a lot. Each node on the condition tree can be very cheaply cached once evaluated, too. I like the idea of if..else on top of this, since, as Skef noted elsewhere, it is a common case to include one component on true, and a different component on false. Or is it sufficient that, for the else branch, we use a negate condition and point to the (cached result of the) just-evaluated node? - L > On 11 Apr 2024, at 16:44, Behdad Esfahbod via mpeg-otspec wrote: > > Thanks Skef. > > I think I found the right approach for this (taking ideas from COLRv1 paint tree / graph). Ignoring your other proposals, we add these: > > We add new Condition's that implement AND of a bunch of Conditions (like the current ConditionSet does), another for OR, and another for NEGATE: > > struct ConditionAnd > { > uint16 format; // 2 > uint16 conditionCount; // Number of conditions for this conjunction expression. > Offset32To conditionOffsets[conditionCount]; > } > > struct ConditionOr > { > uint16 format; // 3 > uint16 conditionCount; // Number of conditions for this disjunction expression. > Offset32To conditionOffsets[conditionCount]; > } > > struct ConditionNegate > { > uint16 format; // 4 > Offset32To condition; > } > > WDYT?behdad > http://behdad.org/ > > From behdad at behdad.org Thu Apr 11 21:21:07 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 13:21:07 -0600 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <76925532-EEC3-4DB1-9B69-1E8B14A006C9@lorp.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <76925532-EEC3-4DB1-9B69-1E8B14A006C9@lorp.org> Message-ID: On Thu, Apr 11, 2024 at 1:17?PM Laurence Penney wrote: > Personally I like this a lot. Each node on the condition tree can be very > cheaply cached once evaluated, too. > > I like the idea of if..else on top of this, since, as Skef noted > elsewhere, it is a common case to include one component on true, and a > different component on false. Or is it sufficient that, for the else > branch, we use a negate condition and point to the (cached result of the) > just-evaluated node? > The latter sounds better to me. Otherwise just representing this in APIs will become more cumbersome. I'm also fine burning a bit of VarComponent flags to negate the result (on top of this proposal). > - L > > > On 11 Apr 2024, at 16:44, Behdad Esfahbod via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > > > > Thanks Skef. > > > > I think I found the right approach for this (taking ideas from COLRv1 > paint tree / graph). Ignoring your other proposals, we add these: > > > > We add new Condition's that implement AND of a bunch of Conditions (like > the current ConditionSet does), another for OR, and another for NEGATE: > > > > struct ConditionAnd > > { > > uint16 format; // 2 > > uint16 conditionCount; // Number of conditions for this conjunction > expression. > > Offset32To conditionOffsets[conditionCount]; > > } > > > > struct ConditionOr > > { > > uint16 format; // 3 > > uint16 conditionCount; // Number of conditions for this disjunction > expression. > > Offset32To conditionOffsets[conditionCount]; > > } > > > > struct ConditionNegate > > { > > uint16 format; // 4 > > Offset32To condition; > > } > > > > WDYT?behdad > > http://behdad.org/ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Thu Apr 11 21:34:41 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 13:34:41 -0600 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <76925532-EEC3-4DB1-9B69-1E8B14A006C9@lorp.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <76925532-EEC3-4DB1-9B69-1E8B14A006C9@lorp.org> Message-ID: On Thu, Apr 11, 2024 at 1:17?PM Laurence Penney wrote: > Personally I like this a lot. Each node on the condition tree can be very > cheaply cached once evaluated, too. > > I like the idea of if..else on top of this, since, as Skef noted > elsewhere, it is a common case to include one component on true, and a > different component on false. Or is it sufficient that, for the else > branch, we use a negate condition and point to the (cached result of the) > just-evaluated node? > Note that caching is unlikely to be of significant value here, since each component is at a different point in the designspace, so you cannot reuse the cached value really. > - L > > > On 11 Apr 2024, at 16:44, Behdad Esfahbod via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > > > > Thanks Skef. > > > > I think I found the right approach for this (taking ideas from COLRv1 > paint tree / graph). Ignoring your other proposals, we add these: > > > > We add new Condition's that implement AND of a bunch of Conditions (like > the current ConditionSet does), another for OR, and another for NEGATE: > > > > struct ConditionAnd > > { > > uint16 format; // 2 > > uint16 conditionCount; // Number of conditions for this conjunction > expression. > > Offset32To conditionOffsets[conditionCount]; > > } > > > > struct ConditionOr > > { > > uint16 format; // 3 > > uint16 conditionCount; // Number of conditions for this disjunction > expression. > > Offset32To conditionOffsets[conditionCount]; > > } > > > > struct ConditionNegate > > { > > uint16 format; // 4 > > Offset32To condition; > > } > > > > WDYT?behdad > > http://behdad.org/ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Thu Apr 11 22:40:35 2024 From: skef at skef.org (Skef Iterum) Date: Thu, 11 Apr 2024 13:40:35 -0700 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> Message-ID: This proposal is a particular way of supporting arbitrary boolean expressions in OFF. That does have the benefit of "just doing it" -- it's certainly preferable to adding significantly more complexity while falling short of total generality. However, there were presumably reasons this route wasn't taken to begin with, probably having to do with complexity, and those would have to be discussed. I.e.: Is this too much rope? This direction would be fine with me if it's fine with the group, but I feel that would a discussion for the upcoming, more onerous phase of work, not to squeeze in before the up coming deadline. Skef On 4/11/24 08:44, Behdad Esfahbod wrote: > Thanks Skef. > > I think I found the right approach for this (taking ideas from COLRv1 > paint tree / graph). Ignoring your other proposals, we add these: > > We add new Condition's?that?implement AND of a bunch of Conditions > (like the current ConditionSet does), another for OR, and another for > NEGATE: > > struct ConditionAnd > { > ? uint16 format; // 2 > ? uint16 conditionCount; // Number of conditions for this conjunction > expression. > ? Offset32To conditionOffsets[conditionCount]; > } > > struct ConditionOr > { > ? uint16 format; // 3 > ? uint16 conditionCount; // Number of conditions for this disjunction > expression. > ? Offset32To conditionOffsets[conditionCount]; > } > > struct ConditionNegate > { > ? uint16 format; // 4 > ? Offset32To condition; > } > > WDYT? > behdad > http://behdad.org/ > > > On Thu, Apr 11, 2024 at 6:26?AM Skef Iterum wrote: > > I'm still trying to think through all of this stuff, but I > tentatively think that if we added a hack to negate a condition > set then we'll have enough. > > To see the issues involved it may be easiest to work backwards. > It's not an accident that most programming languages contain the > combination of boolean expressions (with AND, OR, NOT and some > equivalent of parentheses) + an if/else if/.../else structure. The > former lets you express anything you need to, typically quite > compactly. The latter expresses a set of alternatives such that > it's guaranteed you'll only get one of them. > > With arbitrary boolean expressions it's easy to fake up the > if/else if/else. If you would have had > > if A > ??? R > else if B > ??? S > else if C > ??? T > else if D > ??? U > else > ??? V > > you can just do > > if A > ??? R > if ~A & B > ??? S > if ~A & ~B & C > ??? T > if ~A & ~B & ~C & D > ??? U > if ~A & ~B & ~C & ~D > ??? V > > at the cost of a bit more computation (typically). > > This kind of generality was (presumably) thought to be > /over/-general for variable fonts, and I don't disagree. But it's > worth noting what you lose if you lack /both/ arbitrary boolean > expressions /and/ if/else if/.../else. Say we add condition set > negation. Then if you have a fairly typical case like the > following (where brackets indicate a set) > > if [A & C] > ??? R > else > ??? S > > You can replace that with > > if [A & C] > ??? R > if ~[A & C] > ??? S > > However, /at a single level/ that doesn't extend further. So if > you have > > if [A & C] > ??? R > else if [D & E] > ??? S > else > ??? T > > (which is just adding a third case), there's no easy way to adapt > that into pure "if" conditions using the tools available. And > that's what I've been worried about -- it seems annoying not to be > able to have three alternatives (with non-trivial conditions) > spread out over the design space. > > However, it seems like you can accomplish the equivalent with an > extra level. Assume R, S, and T are "existing" components. Then > you can just do > > a: > if [D & E] > ??? S > if ~[D & E] > ??? T > > b: > if [A & C] > ??? R > if ~[A & C] > ??? a > > Now b has the right qualities. In effect, a sometimes has the > "wrong" contents when [A & C] applies but you never /see/ it in > that case. > > So like I said I want to think about this a bit more but I > tentatively think the thing to do is add means of negating the > condition set (and I think the Format 5 condition hack would be > fine for that, actually), and remove the "else" from the > lookup-based feature variations mechanism to simplify it. > > Skef > > On 4/11/24 01:20, Behdad Esfahbod wrote: >> Hi Skef, >> >> I'm a bit uncomfortable encoding if/else in VARC. As you said on >> the call, the current design seems like a practical compromise. >> As for negation, we *can* add a flag to the component to negate >> the condition. Maybe that's the right approach. But I feel like >> the conditionSet itself should contain the negation. That would >> reduce sharing though. >> >> A "negate the rest" condition type sounds good to me. >> >> behdad >> http://behdad.org/ >> >> >> On Mon, Apr 8, 2024 at 1:55?PM Skef Iterum via mpeg-otspec >> wrote: >> >> A note on conditions as defined in >> WG03-varc-and-other-updates-03.pdf (up for review tomorrow >> morning). >> >> When I sketched out the VARC condition idea I had them >> arranged in if/else if/.../else sequences. From my reading of >> the document they're currently in "if" form -- a condition >> set can be attached to a component and if it is it will only >> be used if the condition set evaluates to true. >> >> There's nothing wrong with that semantic; it may be >> preferable because it's simpler. However, the most common >> case with this system is that you want one shape to render in >> some region of design space (defined by the condition set) >> and another shape to render outside of that. And negating a >> condition /set/ can be expensive and/or tricky. So I would >> recommend that one of these two things change: >> >> * The if/else if/.../else semantic is restored >> * Some way of negating a condition set is added to the >> specification >> >> We talked about the possibility of condition set negation in >> a previous meeting but didn't come to any conclusions. It's >> tricky because the table has no versioning. If we wanted to >> hack negations into the current format the way to do that >> might be to add a new condition format (possibly 5 if >> newfeatvar_spec.pdf is accepted) that looks something like: >> >> ConditionTableFormat5 >> >> *Type Name Description* >> >> uint16 Format????????????????????????????? Format (set to 5) >> >> When present in a condition set this condition indicates >> the set should apply when >> at least one of the other conditions is false and not >> otherwise. That is, it makes the >> condition set apply when it would normally not and >> vice-versa. There should be at >> most one format 5 condition in a condition set and it >> should be the first. >> >> If this is preferred it could be used to replace/simplify the >> trueLookupIndexListOffset/falseLookupIndexListOffset pair in >> the LookupCondition record of newfeatvar_spec.pdf to just >> lookupIndexListOffset (because one could just follow the record >> with the "positive" condition set with another record with >> the negated one when needed). >> >> Skef >> >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Thu Apr 11 23:08:39 2024 From: skef at skef.org (Skef Iterum) Date: Thu, 11 Apr 2024 14:08:39 -0700 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> Message-ID: <4a679519-99f8-43b7-b810-ff1232d0091f@skef.org> Just to add a bit more about this: I wouldn't want the condition mechanism for VARC to differ substantially from that of Feature Variations. So this raises the question of how it will work in the latter context. Is the idea that we continue to (rather uselessly) go through the indirection of a condition set? Do we rev the FeatureVariationRecord system to eliminate the condition set and alter the specification of the LookupVariationRecord similarly? Do we just change the LookupVariationRecord (which is new, so it's not a rev) on the theory that it will almost always be used, and the indirection through the ConditionSet for the FeatureVariationRecord doesn't matter enough to worry about? I suppose if we go this way I would favor changing the LookupVariationRecord and leaving the FeatureVariationRecord as is (so, supporting the new formats but still going though a condition set). Skef On 4/11/24 13:40, Skef Iterum via mpeg-otspec wrote: > > This proposal is a particular way of supporting arbitrary boolean > expressions in OFF. That does have the benefit of "just doing it" -- > it's certainly preferable to adding significantly more complexity > while falling short of total generality. > > However, there were presumably reasons this route wasn't taken to > begin with, probably having to do with complexity, and those would > have to be discussed. I.e.: Is this too much rope? > > This direction would be fine with me if it's fine with the group, but > I feel that would a discussion for the upcoming, more onerous phase of > work, not to squeeze in before the up coming deadline. > > Skef > > On 4/11/24 08:44, Behdad Esfahbod wrote: >> Thanks Skef. >> >> I think I found the right approach for this (taking ideas from COLRv1 >> paint tree / graph). Ignoring your other proposals, we add these: >> >> We add new Condition's?that?implement AND of a bunch of Conditions >> (like the current ConditionSet does), another for OR, and another for >> NEGATE: >> >> struct ConditionAnd >> { >> ? uint16 format; // 2 >> ? uint16 conditionCount; // Number of conditions for this conjunction >> expression. >> ? Offset32To conditionOffsets[conditionCount]; >> } >> >> struct ConditionOr >> { >> ? uint16 format; // 3 >> ? uint16 conditionCount; // Number of conditions for this disjunction >> expression. >> ? Offset32To conditionOffsets[conditionCount]; >> } >> >> struct ConditionNegate >> { >> ? uint16 format; // 4 >> ? Offset32To condition; >> } >> >> WDYT? >> behdad >> http://behdad.org/ >> >> >> On Thu, Apr 11, 2024 at 6:26?AM Skef Iterum wrote: >> >> I'm still trying to think through all of this stuff, but I >> tentatively think that if we added a hack to negate a condition >> set then we'll have enough. >> >> To see the issues involved it may be easiest to work backwards. >> It's not an accident that most programming languages contain the >> combination of boolean expressions (with AND, OR, NOT and some >> equivalent of parentheses) + an if/else if/.../else structure. >> The former lets you express anything you need to, typically quite >> compactly. The latter expresses a set of alternatives such that >> it's guaranteed you'll only get one of them. >> >> With arbitrary boolean expressions it's easy to fake up the >> if/else if/else. If you would have had >> >> if A >> ??? R >> else if B >> ??? S >> else if C >> ??? T >> else if D >> ??? U >> else >> ??? V >> >> you can just do >> >> if A >> ??? R >> if ~A & B >> ??? S >> if ~A & ~B & C >> ??? T >> if ~A & ~B & ~C & D >> ??? U >> if ~A & ~B & ~C & ~D >> ??? V >> >> at the cost of a bit more computation (typically). >> >> This kind of generality was (presumably) thought to be >> /over/-general for variable fonts, and I don't disagree. But it's >> worth noting what you lose if you lack /both/ arbitrary boolean >> expressions /and/ if/else if/.../else. Say we add condition set >> negation. Then if you have a fairly typical case like the >> following (where brackets indicate a set) >> >> if [A & C] >> ??? R >> else >> ??? S >> >> You can replace that with >> >> if [A & C] >> ??? R >> if ~[A & C] >> ??? S >> >> However, /at a single level/ that doesn't extend further. So if >> you have >> >> if [A & C] >> ??? R >> else if [D & E] >> ??? S >> else >> ??? T >> >> (which is just adding a third case), there's no easy way to adapt >> that into pure "if" conditions using the tools available. And >> that's what I've been worried about -- it seems annoying not to >> be able to have three alternatives (with non-trivial conditions) >> spread out over the design space. >> >> However, it seems like you can accomplish the equivalent with an >> extra level. Assume R, S, and T are "existing" components. Then >> you can just do >> >> a: >> if [D & E] >> ??? S >> if ~[D & E] >> ??? T >> >> b: >> if [A & C] >> ??? R >> if ~[A & C] >> ??? a >> >> Now b has the right qualities. In effect, a sometimes has the >> "wrong" contents when [A & C] applies but you never /see/ it in >> that case. >> >> So like I said I want to think about this a bit more but I >> tentatively think the thing to do is add means of negating the >> condition set (and I think the Format 5 condition hack would be >> fine for that, actually), and remove the "else" from the >> lookup-based feature variations mechanism to simplify it. >> >> Skef >> >> On 4/11/24 01:20, Behdad Esfahbod wrote: >>> Hi Skef, >>> >>> I'm a bit uncomfortable encoding if/else in VARC. As you said on >>> the call, the current design seems like a practical compromise. >>> As for negation, we *can* add a flag to the component to negate >>> the condition. Maybe that's the right approach. But I feel like >>> the conditionSet itself should contain the negation. That would >>> reduce sharing though. >>> >>> A "negate the rest" condition type sounds good to me. >>> >>> behdad >>> http://behdad.org/ >>> >>> >>> On Mon, Apr 8, 2024 at 1:55?PM Skef Iterum via mpeg-otspec >>> wrote: >>> >>> A note on conditions as defined in >>> WG03-varc-and-other-updates-03.pdf (up for review tomorrow >>> morning). >>> >>> When I sketched out the VARC condition idea I had them >>> arranged in if/else if/.../else sequences. From my reading >>> of the document they're currently in "if" form -- a >>> condition set can be attached to a component and if it is it >>> will only be used if the condition set evaluates to true. >>> >>> There's nothing wrong with that semantic; it may be >>> preferable because it's simpler. However, the most common >>> case with this system is that you want one shape to render >>> in some region of design space (defined by the condition >>> set) and another shape to render outside of that. And >>> negating a condition /set/ can be expensive and/or tricky. >>> So I would recommend that one of these two things change: >>> >>> * The if/else if/.../else semantic is restored >>> * Some way of negating a condition set is added to the >>> specification >>> >>> We talked about the possibility of condition set negation in >>> a previous meeting but didn't come to any conclusions. It's >>> tricky because the table has no versioning. If we wanted to >>> hack negations into the current format the way to do that >>> might be to add a new condition format (possibly 5 if >>> newfeatvar_spec.pdf is accepted) that looks something like: >>> >>> ConditionTableFormat5 >>> >>> *Type Name Description* >>> >>> uint16 Format????????????????????????????? Format (set to 5) >>> >>> When present in a condition set this condition indicates >>> the set should apply when >>> at least one of the other conditions is false and not >>> otherwise. That is, it makes the >>> condition set apply when it would normally not and >>> vice-versa. There should be at >>> most one format 5 condition in a condition set and it >>> should be the first. >>> >>> If this is preferred it could be used to replace/simplify >>> the trueLookupIndexListOffset/falseLookupIndexListOffset >>> pair in the LookupCondition record of newfeatvar_spec.pdf to >>> just lookupIndexListOffset (because one could just follow >>> the record >>> with the "positive" condition set with another record with >>> the negated one when needed). >>> >>> Skef >>> >>> _______________________________________________ >>> mpeg-otspec mailing list >>> mpeg-otspec at lists.aau.at >>> https://lists.aau.at/mailman/listinfo/mpeg-otspec >>> > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Thu Apr 11 23:21:45 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Thu, 11 Apr 2024 17:21:45 -0400 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <4a679519-99f8-43b7-b810-ff1232d0091f@skef.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <4a679519-99f8-43b7-b810-ff1232d0091f@skef.org> Message-ID: On Thu, 2024-04-11 at 14:08 -0700, Skef Iterum via mpeg-otspec wrote: > > I wouldn't want the condition mechanism for VARC to differ > substantially from that of Feature Variations. For that matter i don?t think we can introduce large changes at this point. However, there has certainly been discussion on the list around negated conditions, and using the same mechanism as elsewhere would make it a smaller addition, maybe? -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From pconstable at microsoft.com Thu Apr 11 23:23:01 2024 From: pconstable at microsoft.com (Peter Constable) Date: Thu, 11 Apr 2024 21:23:01 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] fvar and hoi updated In-Reply-To: References: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> Message-ID: The notion of ?initial? has no meaning in this context. From: Dave Crossland Sent: Thursday, April 4, 2024 10:57 AM To: Peter Constable Cc: Liam R. E. Quin ; MPEG OT Spec list Subject: Re: [MPEG-OTSPEC] [EXTERNAL] fvar and hoi updated On Thu, Apr 4, 2024, 11:51?AM Peter Constable via mpeg-otspec > wrote: Hi, Liam: "The default (initial value) shall be taken from the non-hidden axis entry." This doesn't make sense to me. Text can't be laid out or glyphs rasterized without a full specification of an instance. How is that not a full specification of an instance...? -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Thu Apr 11 23:23:23 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Thu, 11 Apr 2024 17:23:23 -0400 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> Message-ID: <7b2fbb791ddba0d018d3da0f9a82d0d0d02b4736.camel@fromoldbooks.org> On Thu, 2024-04-11 at 13:40 -0700, Skef Iterum via mpeg-otspec wrote: > > This direction would be fine with me if it's fine with the group, but > I feel that would a discussion for the upcoming, more onerous phase > of work, not to squeeze in before the up coming deadline. Note that if it's squeezed in and then there are comments saying there are problems with it, it can be squeezed out. Much more easily than squeezing it in later :-) liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From liam at fromoldbooks.org Thu Apr 11 23:39:12 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Thu, 11 Apr 2024 17:39:12 -0400 Subject: [MPEG-OTSPEC] [EXTERNAL] fvar and hoi updated In-Reply-To: References: <1671dfd8f6707242f8128e7025ca2fd415dea3ba.camel@fromoldbooks.org> Message-ID: <62550f85a90a9511fe452facdfb6b892e11bb0ec.camel@fromoldbooks.org> On Thu, 2024-04-11 at 21:23 +0000, Peter Constable wrote: > > > > The notion of ?initial? has no meaning in this context. Thanks, my bad - this came up in the meeting too, and Laurence i think already suggested better (and correct!) wording before the meeting. I'll try & post later today. -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From skef at skef.org Thu Apr 11 23:46:17 2024 From: skef at skef.org (Skef Iterum) Date: Thu, 11 Apr 2024 14:46:17 -0700 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <7b2fbb791ddba0d018d3da0f9a82d0d0d02b4736.camel@fromoldbooks.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <7b2fbb791ddba0d018d3da0f9a82d0d0d02b4736.camel@fromoldbooks.org> Message-ID: I understand, but there are reasons the processes discourage this sort of thing. It's not just pro-forma. Put this this way: Suppose this is added to the draft that was tentatively approved on Tuesday, and then at the working group meeting someone says "this is a significant change and we never discussed it, I no longer approve of this proposal". Then is there even an opportunity to pull it out, given that the documents are already registered and uploaded? Is it worth the risk of losing the other changes? Skef On 4/11/24 14:23, Liam R. E. Quin wrote: > On Thu, 2024-04-11 at 13:40 -0700, Skef Iterum via mpeg-otspec wrote: >> This direction would be fine with me if it's fine with the group, but >> I feel that would a discussion for the upcoming, more onerous phase >> of work, not to squeeze in before the up coming deadline. > Note that if it's squeezed in and then there are comments saying there > are problems with it, it can be squeezed out. Much more easily than > squeezing it in later :-) > > liam > From behdad at behdad.org Fri Apr 12 00:48:52 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 16:48:52 -0600 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> Message-ID: On Thu, Apr 11, 2024 at 2:40?PM Skef Iterum wrote: > This proposal is a particular way of supporting arbitrary boolean > expressions in OFF. That does have the benefit of "just doing it" -- it's > certainly preferable to adding significantly more complexity while falling > short of total generality. > > However, there were presumably reasons this route wasn't taken to begin > with, probably having to do with complexity, and those would have to be > discussed. I.e.: Is this too much rope? > As someone who was part of the initial varfont initiative, it wasn't done this way because we didn't deem the need. Note that feature variations are a big "if else if else if else..." already. So the need for this kind of negated logic is much less. > This direction would be fine with me if it's fine with the group, but I > feel that would a discussion for the upcoming, more onerous phase of work, > not to squeeze in before the up coming deadline. > Honestly, the new addition is pretty small compared to the whole work. So I'd rather earmark it in than wait. What I want to avoid is VARC going in and implemented, then five years later Condition updated and implemented... > I suppose if we go this way I would favor changing the LookupVariationRecord and leaving the FeatureVariationRecord as is (so, supporting the new formats but still going though a condition set). I agree. b -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Fri Apr 12 00:56:18 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Thu, 11 Apr 2024 18:56:18 -0400 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <7b2fbb791ddba0d018d3da0f9a82d0d0d02b4736.camel@fromoldbooks.org> Message-ID: <6ddb2cdc154076b277f420face014ed528a9d5c9.camel@fromoldbooks.org> On Thu, 2024-04-11 at 14:46 -0700, Skef Iterum wrote: > I understand, but there are reasons the processes discourage this > sort of thing. It's not just pro-forma. I?m not sure whether Vlad is expecting to hold more ?ad hoc? meetings, given the likely change in document stage and process. But first we need to get all the proposals into shape as formal submissions, and resolve any remaining issues we know of. If there is general agreement about negated conditions here on the mailing list, and the mechanism used is not something large and new, they can be rejected yes, but i don't see all of varc being rejected, for example, nor the editorial changes in the "update" document i edited, nor your hinting document, etc. To answer your question about removal, i think it more likely to be in terms of an entire feature, not based on how the feature got into the draft. At the MPEG meeting, people could reject part of a submission, presumably, but i don?t expect that level of detailed review there. Change proposals would come (notionally) from outside, via comments from the individual national standards bodies that make up ISO. So i think it?s worth exploring a simple proposal, and, if it turns out that it can?t be accepted for next week, at least we have it ready to send to NISO or SCC (Canada) or whoever. liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From skef at skef.org Fri Apr 12 01:09:04 2024 From: skef at skef.org (Skef Iterum) Date: Thu, 11 Apr 2024 16:09:04 -0700 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <6ddb2cdc154076b277f420face014ed528a9d5c9.camel@fromoldbooks.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <7b2fbb791ddba0d018d3da0f9a82d0d0d02b4736.camel@fromoldbooks.org> <6ddb2cdc154076b277f420face014ed528a9d5c9.camel@fromoldbooks.org> Message-ID: <93964662-01d2-4ed7-971b-86718d733c18@skef.org> The current newfeatvar_spec document has the negated conditions and reorders the section on condition sets and conditions. This sort of addition would need coordination between the two documents. I'm on PTO Friday through Monday. How is this going to happen before the 17th? On 4/11/24 15:56, Liam R. E. Quin wrote: > If there is general agreement about negated conditions here on the > mailing list, and the mechanism used is not something large and new, > they can be rejected yes, but i don't see all of varc being rejected, > for example, nor the editorial changes in the "update" document i > edited, nor your hinting document, etc. This new proposal isn't about "negated conditions", it replaces negated conditions with general boolean expressions. While it's modest to spec it has implications. Would tools be exposing this? Should they expose it? And what does "general agreement ... here on the mailing list" mean? That no one objects? (Or, maybe that no one other than /me/ objects, because my objections are procedural?) What if some people aren't reading their email for a few days? > To answer your question about removal, i think it more likely to be in > terms of an entire feature, not based on how the feature got into the > draft. At the MPEG meeting, people could reject part of a submission, > presumably, but i don?t expect that level of detailed review there. > Change proposals would come (notionally) from outside, via comments > from the individual national standards bodies that make up ISO. I'm talking about the Working Group meeting later in April. There is a proposal we discussed last Tuesday. You want to change it substantially after it was tentatively approved. Skef -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Fri Apr 12 01:41:55 2024 From: skef at skef.org (Skef Iterum) Date: Thu, 11 Apr 2024 16:41:55 -0700 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <93964662-01d2-4ed7-971b-86718d733c18@skef.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <7b2fbb791ddba0d018d3da0f9a82d0d0d02b4736.camel@fromoldbooks.org> <6ddb2cdc154076b277f420face014ed528a9d5c9.camel@fromoldbooks.org> <93964662-01d2-4ed7-971b-86718d733c18@skef.org> Message-ID: <36d60a44-7e00-487d-9cd9-bafc97db20d1@skef.org> I guess I can answer my own question here: You have your current proposal document and we have newfeatvar_spec.pdf. If you want to propose this change for the April working group meeting /cleanly/ you can do that by making an /additional/ proposal /against/ those two documents, and emailing it here first. (newfeatvar_spec has all of the relevant VARC content because of the editorial direction I took with it.) That would presumably propose to: 1. Eliminate condition formats 2 and 4 from newfeatvar_spec. 2. Change format 3 back to 2. 3. Add the three additional formats. 4. Note in the condition set section that that mechanism has been partially superseded 5. Make the appropriate changes to 6.2.10. This way the alternate system is genuinely severable from the content that has already been discussed and approved as part of the Ad Hoc process. I've already indicated what some of the 6.2.10 changes would be, but they are: 1. The LookupCondition record now just has a conditionOffset and a lookupIndexListOffset, from which lookups are taken when the (now potentially compound) condition at that offset is true. 2. Assuming we're eliminating the condition set, you'll need to note somewhere appropriate that a 0 offset to a condition means the condition is true (as is true of condition sets). I don't recommend getting rid of the conditionSet in the FeatureVariationRecord because of the versioning issues that would introduce. This still raises a lot of questions about lack of input and very short engineering time, but it means that people could take it or leave it at the meeting on its merits, rather than feeling pressured by it's sudden inclusion in a document already tracked for approval. Skef On 4/11/24 16:09, Skef Iterum via mpeg-otspec wrote: > > The current newfeatvar_spec document has the negated conditions and > reorders the section on condition sets and conditions. This sort of > addition would need coordination between the two documents. I'm on PTO > Friday through Monday. How is this going to happen before the 17th? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Fri Apr 12 01:48:36 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 17:48:36 -0600 Subject: [MPEG-OTSPEC] Note on VARC conditions and condition set negation In-Reply-To: <36d60a44-7e00-487d-9cd9-bafc97db20d1@skef.org> References: <1de2dae8-989e-4ae8-80a0-719908deff91@skef.org> <89c8442b-0e7b-4488-a0da-c1ae901887cb@skef.org> <7b2fbb791ddba0d018d3da0f9a82d0d0d02b4736.camel@fromoldbooks.org> <6ddb2cdc154076b277f420face014ed528a9d5c9.camel@fromoldbooks.org> <93964662-01d2-4ed7-971b-86718d733c18@skef.org> <36d60a44-7e00-487d-9cd9-bafc97db20d1@skef.org> Message-ID: I won't be making any changes for next week. Will work for the next deadline, if there's any. behdad http://behdad.org/ On Thu, Apr 11, 2024 at 5:42?PM Skef Iterum via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > I guess I can answer my own question here: You have your current > proposal document and we have newfeatvar_spec.pdf. If you want to > propose this change for the April working group meeting *cleanly* you can > do that by making an *additional* proposal *against* those two documents, > and emailing it here first. (newfeatvar_spec has all of the relevant VARC > content because of the editorial direction I took with it.) > > That would presumably propose to: > > 1. Eliminate condition formats 2 and 4 from newfeatvar_spec. > 2. Change format 3 back to 2. > 3. Add the three additional formats. > 4. Note in the condition set section that that mechanism has been > partially superseded > 5. Make the appropriate changes to 6.2.10. > > This way the alternate system is genuinely severable from the > content that has already been discussed and approved as part of the > Ad Hoc process. > > I've already indicated what some of the 6.2.10 changes would be, > but they are: > > 1. The LookupCondition record now just has a conditionOffset and a > lookupIndexListOffset, from which lookups are taken when the > (now potentially compound) condition at that offset is true. > 2. Assuming we're eliminating the condition set, you'll need to note > somewhere appropriate that a 0 offset to a condition means the > condition is true (as is true of condition sets). > > I don't recommend getting rid of the conditionSet in the > FeatureVariationRecord > because of the versioning issues that would introduce. > > This still raises a lot of questions about lack of input and very short > engineering > time, but it means that people could take it or leave it at the meeting on > its > merits, rather than feeling pressured by it's sudden inclusion in a > document > already tracked for approval. > > Skef > On 4/11/24 16:09, Skef Iterum via mpeg-otspec wrote: > > The current newfeatvar_spec document has the negated conditions and > reorders the section on condition sets and conditions. This sort of > addition would need coordination between the two documents. I'm on PTO > Friday through Monday. How is this going to happen before the 17th? > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Fri Apr 12 06:04:46 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Thu, 11 Apr 2024 22:04:46 -0600 Subject: [MPEG-OTSPEC] TypeCon Meeting? Message-ID: Hi Vlad, Is there any room in the process to have a f2f meeting at TypeCon? Or the ship will have left by then? (I need to know for my own scheduling purpose.) Thanks, behdad http://behdad.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Fri Apr 12 19:06:29 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Fri, 12 Apr 2024 13:06:29 -0400 Subject: [MPEG-OTSPEC] TypeCon Meeting? In-Reply-To: References: Message-ID: Hi Behdad, all, TypeCon 2024 is scheduled in July. At that time, the OFF standard will already be published as a Committee Draft document, and will likely be under ballot. Also, the timing of TypeCon conflicts with the July SC29 / WG3 meeting, which will be held in Japan. I am not sure if having a formal face-to-face AHG meeting to discuss ballot comments would be necessary, and based on my own schedule and MPEG meeting conflict with TypeCon - I will not be able to attend it. Having said this, there is nothing that would preclude a group of people [who are attending the TypeCon in person and are interested in spending time together to discuss the technology improvements] to gather informally and discuss specific details of the current spec and/or implementation, and to provide their comments to the AHG. Thank you, Vladimir On Fri, Apr 12, 2024 at 12:05?AM Behdad Esfahbod via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > Hi Vlad, > > Is there any room in the process to have a f2f meeting at TypeCon? Or the > ship will have left by then? (I need to know for my own scheduling purpose.) > > Thanks, > > behdad > http://behdad.org/ > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eb2mmrt at gmail.com Sat Apr 13 10:06:44 2024 From: eb2mmrt at gmail.com (MURATA) Date: Sat, 13 Apr 2024 17:06:44 +0900 Subject: [MPEG-OTSPEC] TypeCon Meeting? In-Reply-To: References: Message-ID: Folks, "When a document is out for ballot (or commenting at the CD stage), formal discussion during meetings or distribution of positions via formal committee distribution channels are prohibited." This is quoted from the ISO/IEC Directives, Part 1 (f in 0.7). As Vladimir suggested, informal meetings if interested people are fine. Regards, Makoto 2024?4?13?(?) 2:06 Vladimir Levantovsky via mpeg-otspec < mpeg-otspec at lists.aau.at>: > Hi Behdad, all, > > TypeCon 2024 is scheduled in July. At that time, the OFF standard will > already be published as a Committee Draft document, and will likely be > under ballot. Also, the timing of TypeCon conflicts with the July SC29 / > WG3 meeting, which will be held in Japan. > I am not sure if having a formal face-to-face AHG meeting to discuss > ballot comments would be necessary, and based on my own schedule and MPEG > meeting conflict with TypeCon - I will not be able to attend it. > > Having said this, there is nothing that would preclude a group of people > [who are attending the TypeCon in person and are interested in spending > time together to discuss the technology improvements] to gather informally > and discuss specific details of the current spec and/or implementation, and > to provide their comments to the AHG. > > Thank you, > Vladimir > > > On Fri, Apr 12, 2024 at 12:05?AM Behdad Esfahbod via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > >> Hi Vlad, >> >> Is there any room in the process to have a f2f meeting at TypeCon? Or the >> ship will have left by then? (I need to know for my own scheduling purpose.) >> >> Thanks, >> >> behdad >> http://behdad.org/ >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -- -- ???????????????????? ?? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Wed Apr 17 22:32:55 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Wed, 17 Apr 2024 16:32:55 -0400 Subject: [MPEG-OTSPEC] Font Format Break-out meeting next week Message-ID: Dear all, The schedule for the next week's SC29/WG03 meeting has been finalized, and the Font Format Break-out Group meeting is scheduled on Tuesday, April 23rd at 16:00-17:30 local (Central EU) time, which is 14:00-15:30 UTC. I will set up a Zoom meeting and add the details in the meeting calendar. We will be using the same static Zoom link ( https://iso.zoom.us/my/fontformat) with the WG3 meeting Zoom password. Thank you, Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From htl10 at users.sourceforge.net Tue Apr 23 16:09:03 2024 From: htl10 at users.sourceforge.net (Hin-Tak Leung) Date: Tue, 23 Apr 2024 14:09:03 +0000 (UTC) Subject: [MPEG-OTSPEC] Font Format Break-out meeting next week In-Reply-To: References: Message-ID: <337237969.4464379.1713881343420@mail.yahoo.com> Am trying to get in (I think supposedly started 7 minutes ago? Or have I got it wrong?). Can't join with the credentials in the april 9 e-mail . Not happening? On Wednesday 17 April 2024 at 21:33:28 BST, Vladimir Levantovsky via mpeg-otspec wrote: Dear all, The schedule for the next week's SC29/WG03 meeting has been finalized, and the Font Format Break-out Group meeting is scheduled on Tuesday, April 23rd at 16:00-17:30 local (Central EU) time, which is 14:00-15:30 UTC. I will set up a Zoom meeting and add the details in the meeting calendar. We will be using the same static Zoom link (https://iso.zoom.us/my/fontformat) with the WG3 meeting Zoom password. Thank you,Vladimir _______________________________________________ mpeg-otspec mailing list mpeg-otspec at lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec -------------- next part -------------- An HTML attachment was scrubbed... URL: From bberning at spotify.com Tue Apr 23 16:10:12 2024 From: bberning at spotify.com (Bianca Berning) Date: Tue, 23 Apr 2024 15:10:12 +0100 Subject: [MPEG-OTSPEC] Font Format Break-out meeting next week In-Reply-To: <337237969.4464379.1713881343420@mail.yahoo.com> References: <337237969.4464379.1713881343420@mail.yahoo.com> Message-ID: It starts in two hours. Btw, can?t make it today ? On Tue, Apr 23, 2024 at 3:09?PM Hin-Tak Leung via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > Am trying to get in (I think supposedly started 7 minutes ago? Or have I > got it wrong?). Can't join with the credentials in the april 9 e-mail . Not > happening? > On Wednesday 17 April 2024 at 21:33:28 BST, Vladimir Levantovsky via > mpeg-otspec wrote: > > > Dear all, > > The schedule for the next week's SC29/WG03 meeting has been finalized, and > the Font Format Break-out Group meeting is scheduled on Tuesday, April 23rd > at 16:00-17:30 local (Central EU) time, which is 14:00-15:30 UTC. > > I will set up a Zoom meeting and add the details in the meeting calendar. > We will be using the same static Zoom link ( > https://iso.zoom.us/my/fontformat) with the WG3 meeting Zoom password. > > Thank you, > Vladimir > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Tue Apr 23 16:10:04 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 23 Apr 2024 08:10:04 -0600 Subject: [MPEG-OTSPEC] Font Format Break-out meeting next week In-Reply-To: <337237969.4464379.1713881343420@mail.yahoo.com> References: <337237969.4464379.1713881343420@mail.yahoo.com> Message-ID: Is happening. behdad http://behdad.org/ On Tue, Apr 23, 2024 at 8:09?AM Hin-Tak Leung via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > Am trying to get in (I think supposedly started 7 minutes ago? Or have I > got it wrong?). Can't join with the credentials in the april 9 e-mail . Not > happening? > On Wednesday 17 April 2024 at 21:33:28 BST, Vladimir Levantovsky via > mpeg-otspec wrote: > > > Dear all, > > The schedule for the next week's SC29/WG03 meeting has been finalized, and > the Font Format Break-out Group meeting is scheduled on Tuesday, April 23rd > at 16:00-17:30 local (Central EU) time, which is 14:00-15:30 UTC. > > I will set up a Zoom meeting and add the details in the meeting calendar. > We will be using the same static Zoom link ( > https://iso.zoom.us/my/fontformat) with the WG3 meeting Zoom password. > > Thank you, > Vladimir > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bberning at spotify.com Tue Apr 23 16:10:54 2024 From: bberning at spotify.com (Bianca Berning) Date: Tue, 23 Apr 2024 15:10:54 +0100 Subject: [MPEG-OTSPEC] Font Format Break-out meeting next week In-Reply-To: References: <337237969.4464379.1713881343420@mail.yahoo.com> Message-ID: Haha! Ignore me. On Tue, Apr 23, 2024 at 3:10?PM Bianca Berning wrote: > It starts in two hours. > Btw, can?t make it today ? > > On Tue, Apr 23, 2024 at 3:09?PM Hin-Tak Leung via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > >> Am trying to get in (I think supposedly started 7 minutes ago? Or have I >> got it wrong?). Can't join with the credentials in the april 9 e-mail . Not >> happening? >> On Wednesday 17 April 2024 at 21:33:28 BST, Vladimir Levantovsky via >> mpeg-otspec wrote: >> >> >> Dear all, >> >> The schedule for the next week's SC29/WG03 meeting has been finalized, >> and the Font Format Break-out Group meeting is scheduled on Tuesday, April >> 23rd at 16:00-17:30 local (Central EU) time, which is 14:00-15:30 UTC. >> >> I will set up a Zoom meeting and add the details in the meeting calendar. >> We will be using the same static Zoom link ( >> https://iso.zoom.us/my/fontformat) with the WG3 meeting Zoom password. >> >> Thank you, >> Vladimir >> >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Tue Apr 23 16:10:45 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 23 Apr 2024 08:10:45 -0600 Subject: [MPEG-OTSPEC] Font Format Break-out meeting next week In-Reply-To: References: <337237969.4464379.1713881343420@mail.yahoo.com> Message-ID: It's happening now. behdad http://behdad.org/ On Tue, Apr 23, 2024 at 8:10?AM Bianca Berning via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > It starts in two hours. > Btw, can?t make it today ? > > On Tue, Apr 23, 2024 at 3:09?PM Hin-Tak Leung via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > >> Am trying to get in (I think supposedly started 7 minutes ago? Or have I >> got it wrong?). Can't join with the credentials in the april 9 e-mail . Not >> happening? >> On Wednesday 17 April 2024 at 21:33:28 BST, Vladimir Levantovsky via >> mpeg-otspec wrote: >> >> >> Dear all, >> >> The schedule for the next week's SC29/WG03 meeting has been finalized, >> and the Font Format Break-out Group meeting is scheduled on Tuesday, April >> 23rd at 16:00-17:30 local (Central EU) time, which is 14:00-15:30 UTC. >> >> I will set up a Zoom meeting and add the details in the meeting calendar. >> We will be using the same static Zoom link ( >> https://iso.zoom.us/my/fontformat) with the WG3 meeting Zoom password. >> >> Thank you, >> Vladimir >> >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> _______________________________________________ >> mpeg-otspec mailing list >> mpeg-otspec at lists.aau.at >> https://lists.aau.at/mailman/listinfo/mpeg-otspec >> > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From htl10 at users.sourceforge.net Tue Apr 23 16:11:41 2024 From: htl10 at users.sourceforge.net (Hin-Tak Leung) Date: Tue, 23 Apr 2024 14:11:41 +0000 (UTC) Subject: [MPEG-OTSPEC] Font Format Break-out meeting next week In-Reply-To: References: <337237969.4464379.1713881343420@mail.yahoo.com> Message-ID: <727129369.4460336.1713881501981@mail.yahoo.com> Okay, I'll try harder... On Tuesday 23 April 2024 at 15:10:56 BST, Behdad Esfahbod wrote: Is happening. behdad http://behdad.org/ On Tue, Apr 23, 2024 at 8:09?AM Hin-Tak Leung via mpeg-otspec wrote: Am trying to get in (I think supposedly started 7 minutes ago? Or have I got it wrong?). Can't join with the credentials in the april 9 e-mail . Not happening? On Wednesday 17 April 2024 at 21:33:28 BST, Vladimir Levantovsky via mpeg-otspec wrote: Dear all, The schedule for the next week's SC29/WG03 meeting has been finalized, and the Font Format Break-out Group meeting is scheduled on Tuesday, April 23rd at 16:00-17:30 local (Central EU) time, which is 14:00-15:30 UTC. I will set up a Zoom meeting and add the details in the meeting calendar. We will be using the same static Zoom link (https://iso.zoom.us/my/fontformat) with the WG3 meeting Zoom password. Thank you,Vladimir _______________________________________________ mpeg-otspec mailing list mpeg-otspec at lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec _______________________________________________ mpeg-otspec mailing list mpeg-otspec at lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec -------------- next part -------------- An HTML attachment was scrubbed... URL: From tfuji at morisawa.co.jp Tue Apr 23 18:22:41 2024 From: tfuji at morisawa.co.jp (=?utf-8?B?VGFrYWFraSBGdWppIOiXpCDosrTkuq4=?=) Date: Wed, 24 Apr 2024 01:22:41 +0900 Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> Message-ID: So is ?DMAP? in the resulted draft going to be additive only and not to allow removing mappings defined in ?cmap?? Just for clarification as it looked it?d been discussed for some time. Takaaki Fuji > On Apr 2, 2024, at 14:06, Liam R. E. Quin via mpeg-otspec wrote: > > Should dmap be able to delete glyphs from cmap for a particular > subfont? Several people have said they would like that feature. > > If so, should it do so with a -1 glyphID? (i.g. 65535 for a 16-bit font > and 2^24 - 1 = 16777215 for a 24-bit glyph ID, and, should it ever be > supported, 4294967295 for a 32-bit glyphID? The value would depend on > table and version/format. > > Are we OK with format 14 and dmap at this point? > > Thanks, > > liam > > > -- > Liam Quin, https://www.delightfulcomputing.com/ > Available for XML/Document/Information Architecture/XSLT/ > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec From liam at fromoldbooks.org Tue Apr 23 18:37:18 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Tue, 23 Apr 2024 12:37:18 -0400 Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> Message-ID: <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> On Wed, 2024-04-24 at 01:22 +0900, Takaaki Fuji ? ?? wrote: > So is ?DMAP? in the resulted draft going to be additive only and not > to allow removing mappings defined in ?cmap?? Just for clarification > as it looked it?d been discussed for some time. Yes. I posted to the list some time ago to ask about deleting, and got no replies. It?s conceivable that deleting could be added through the commenting process, but i am not certain. liam -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org From tfuji at morisawa.co.jp Tue Apr 23 18:46:11 2024 From: tfuji at morisawa.co.jp (=?utf-8?B?VGFrYWFraSBGdWppIOiXpCDosrTkuq4=?=) Date: Wed, 24 Apr 2024 01:46:11 +0900 Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> Message-ID: <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> Thank you for confirmation! I?m okay with this and I was just curious about the conclusion so far. Takaaki Fuji > On Apr 24, 2024, at 1:37, Liam R. E. Quin wrote: > > On Wed, 2024-04-24 at 01:22 +0900, Takaaki Fuji ? ?? wrote: >> So is ?DMAP? in the resulted draft going to be additive only and not >> to allow removing mappings defined in ?cmap?? Just for clarification >> as it looked it?d been discussed for some time. > > Yes. I posted to the list some time ago to ask about deleting, and got > no replies. It?s conceivable that deleting could be added through the > commenting process, but i am not certain. > > liam > > -- > Liam Quin, https://www.delightfulcomputing.com/ > Available for XML/Document/Information Architecture/XSLT/ > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org From ned at apple.com Tue Apr 23 20:03:53 2024 From: ned at apple.com (Ned Holbrook) Date: Tue, 23 Apr 2024 11:03:53 -0700 Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> Message-ID: <7352A284-5446-4659-9405-6C916FE2BFEC@apple.com> I think some people were weakly opposed to discussing technical details over email, and based on github comments there seemed to be general consensus in favor of allowing deletion. > On Apr 23, 2024, at 9:46?AM, Takaaki Fuji ? ?? via mpeg-otspec wrote: > > Thank you for confirmation! I?m okay with this and I was just curious about the conclusion so far. > > Takaaki Fuji > >> On Apr 24, 2024, at 1:37, Liam R. E. Quin wrote: >> >> On Wed, 2024-04-24 at 01:22 +0900, Takaaki Fuji ? ?? wrote: >>> So is ?DMAP? in the resulted draft going to be additive only and not >>> to allow removing mappings defined in ?cmap?? Just for clarification >>> as it looked it?d been discussed for some time. >> >> Yes. I posted to the list some time ago to ask about deleting, and got >> no replies. It?s conceivable that deleting could be added through the >> commenting process, but i am not certain. >> >> liam >> >> -- >> Liam Quin, https://www.delightfulcomputing.com/ >> Available for XML/Document/Information Architecture/XSLT/ >> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. >> Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec From htl10 at users.sourceforge.net Tue Apr 23 20:24:56 2024 From: htl10 at users.sourceforge.net (Hin-Tak Leung) Date: Tue, 23 Apr 2024 18:24:56 +0000 (UTC) Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> Message-ID: <793285166.4697215.1713896696722@mail.yahoo.com> I can think of one possible use of dmap deletion - the complete GB18030 (the current official Chinese character set) contains both traditional and simplified variants and historical forms relocated from the current unicode code points. It may be the designers' decision to have a master cmap, but delete all the traditional Chinese variants, to indicate an official preference of discouraging people from using those. (This is of course achievable by an additive process too, as can as fully/different ttc's) And possibly quite useful for even with traditional variants (HK/TW forms) and SG/CN simplified variants to have the capability of deleting - I.e. explicitly skipping some glyphs to discourage their use. E.g. you can discourage the use of HK slang words in TW-based writings, if you are some sort of purist in language use. Addition is core plus variants, but you can do the opposite, as in complete minus optional/deprecated ? On Tuesday, 23 April 2024 at 17:46:34 BST, Takaaki Fuji ? ?? via mpeg-otspec wrote: Thank you for confirmation! I?m okay with this and I was just curious about the conclusion so far. Takaaki Fuji > On Apr 24, 2024, at 1:37, Liam R. E. Quin wrote: > > On Wed, 2024-04-24 at 01:22 +0900, Takaaki Fuji ? ?? wrote: >> So is ?DMAP? in the resulted draft going to be additive only and not >> to allow removing mappings defined in ?cmap?? Just for clarification >> as it looked it?d been discussed for some time. > > Yes. I posted to the list some time ago to ask about deleting, and got > no replies. It?s conceivable that deleting could be added through the > commenting process, but i am not certain. > > liam > > -- > Liam Quin, https://www.delightfulcomputing.com/ > Available for XML/Document/Information Architecture/XSLT/ > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > Barefoot Web-slave, antique illustrations:? http://www.fromoldbooks.org _______________________________________________ mpeg-otspec mailing list mpeg-otspec at lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec -------------- next part -------------- An HTML attachment was scrubbed... URL: From htl10 at users.sourceforge.net Tue Apr 23 20:33:08 2024 From: htl10 at users.sourceforge.net (Hin-Tak Leung) Date: Tue, 23 Apr 2024 18:33:08 +0000 (UTC) Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: <7352A284-5446-4659-9405-6C916FE2BFEC@apple.com> References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> <7352A284-5446-4659-9405-6C916FE2BFEC@apple.com> Message-ID: <370167982.4693775.1713897188384@mail.yahoo.com> FWIW, I am weakly opposed to web-site based discussions. I don't monitor any/most web pages/forums, even if I visit them from time to time. Also, e-mails are distributed in nature (everybody has a copy; you delete yours, I still have mine), web-site discussions, you are relying on the hosting company staying in business/online. Although the chance of github going bankrupt is very small, and its being unavailable and offline for extended period is also quite low. On Tuesday, 23 April 2024 at 19:04:20 BST, Ned Holbrook via mpeg-otspec wrote: I think some people were weakly opposed to discussing technical details over email, and based on github comments there seemed to be general consensus in favor of allowing deletion. > On Apr 23, 2024, at 9:46?AM, Takaaki Fuji ? ?? via mpeg-otspec wrote: > > Thank you for confirmation! I?m okay with this and I was just curious about the conclusion so far. > > Takaaki Fuji > >> On Apr 24, 2024, at 1:37, Liam R. E. Quin wrote: >> >> On Wed, 2024-04-24 at 01:22 +0900, Takaaki Fuji ? ?? wrote: >>> So is ?DMAP? in the resulted draft going to be additive only and not >>> to allow removing mappings defined in ?cmap?? Just for clarification >>> as it looked it?d been discussed for some time. >> >> Yes. I posted to the list some time ago to ask about deleting, and got >> no replies. It?s conceivable that deleting could be added through the >> commenting process, but i am not certain. >> >> liam >> >> -- >> Liam Quin, https://www.delightfulcomputing.com/ >> Available for XML/Document/Information Architecture/XSLT/ >> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. >> Barefoot Web-slave, antique illustrations:? http://www.fromoldbooks.org > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec _______________________________________________ mpeg-otspec mailing list mpeg-otspec at lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec -------------- next part -------------- An HTML attachment was scrubbed... URL: From ned at apple.com Tue Apr 23 20:34:27 2024 From: ned at apple.com (Ned Holbrook) Date: Tue, 23 Apr 2024 11:34:27 -0700 Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: <370167982.4693775.1713897188384@mail.yahoo.com> References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> <7352A284-5446-4659-9405-6C916FE2BFEC@apple.com> <370167982.4693775.1713897188384@mail.yahoo.com> Message-ID: I don?t speak authoritatively here. Frankly I don?t understand most of the process here anyway. > On Apr 23, 2024, at 11:33?AM, Hin-Tak Leung wrote: > > FWIW, I am weakly opposed to web-site based discussions. I don't monitor any/most web pages/forums, even if I visit them from time to time. > > Also, e-mails are distributed in nature (everybody has a copy; you delete yours, I still have mine), web-site discussions, you are relying on the hosting company staying in business/online. Although the chance of github going bankrupt is very small, and its being unavailable and offline for extended period is also quite low. > > On Tuesday, 23 April 2024 at 19:04:20 BST, Ned Holbrook via mpeg-otspec wrote: > > > I think some people were weakly opposed to discussing technical details over email, and based on github comments there seemed to be general consensus in favor of allowing deletion. > > > On Apr 23, 2024, at 9:46?AM, Takaaki Fuji ? ?? via mpeg-otspec > wrote: > > > > Thank you for confirmation! I?m okay with this and I was just curious about the conclusion so far. > > > > Takaaki Fuji > > > >> On Apr 24, 2024, at 1:37, Liam R. E. Quin > wrote: > >> > >> On Wed, 2024-04-24 at 01:22 +0900, Takaaki Fuji ? ?? wrote: > >>> So is ?DMAP? in the resulted draft going to be additive only and not > >>> to allow removing mappings defined in ?cmap?? Just for clarification > >>> as it looked it?d been discussed for some time. > >> > >> Yes. I posted to the list some time ago to ask about deleting, and got > >> no replies. It?s conceivable that deleting could be added through the > >> commenting process, but i am not certain. > >> > >> liam > >> > >> -- > >> Liam Quin, https://www.delightfulcomputing.com/ > >> Available for XML/Document/Information Architecture/XSLT/ > >> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > >> Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org > > > > _______________________________________________ > > mpeg-otspec mailing list > > mpeg-otspec at lists.aau.at > > https://lists.aau.at/mailman/listinfo/mpeg-otspec > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Tue Apr 23 20:34:51 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 23 Apr 2024 12:34:51 -0600 Subject: [MPEG-OTSPEC] mapping out dmap In-Reply-To: <370167982.4693775.1713897188384@mail.yahoo.com> References: <9cbe2a59d1a9d42bf17cbade6cfa46d0f0bbf8a4.camel@fromoldbooks.org> <5aa5b9de5636429d25f8c3ab454a386ee4b6fb95.camel@fromoldbooks.org> <7624162E-948A-49B4-B636-322604072A88@morisawa.co.jp> <7352A284-5446-4659-9405-6C916FE2BFEC@apple.com> <370167982.4693775.1713897188384@mail.yahoo.com> Message-ID: You can easily configure github to email you of any discussion. So that issue is moot IMO. On the other hand, GitHub discussions are more accessible and more likely to survive than the archives of this list. On Tue, Apr 23, 2024 at 12:33?PM Hin-Tak Leung via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > FWIW, I am weakly opposed to web-site based discussions. I don't monitor > any/most web pages/forums, even if I visit them from time to time. > > Also, e-mails are distributed in nature (everybody has a copy; you delete > yours, I still have mine), web-site discussions, you are relying on the > hosting company staying in business/online. Although the chance of github > going bankrupt is very small, and its being unavailable and offline for > extended period is also quite low. > > On Tuesday, 23 April 2024 at 19:04:20 BST, Ned Holbrook via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > > > I think some people were weakly opposed to discussing technical details > over email, and based on github comments there seemed to be general > consensus in favor of allowing deletion. > > > On Apr 23, 2024, at 9:46?AM, Takaaki Fuji ? ?? via mpeg-otspec < > mpeg-otspec at lists.aau.at> wrote: > > > > Thank you for confirmation! I?m okay with this and I was just curious > about the conclusion so far. > > > > Takaaki Fuji > > > >> On Apr 24, 2024, at 1:37, Liam R. E. Quin > wrote: > >> > >> On Wed, 2024-04-24 at 01:22 +0900, Takaaki Fuji ? ?? wrote: > >>> So is ?DMAP? in the resulted draft going to be additive only and not > >>> to allow removing mappings defined in ?cmap?? Just for clarification > >>> as it looked it?d been discussed for some time. > >> > >> Yes. I posted to the list some time ago to ask about deleting, and got > >> no replies. It?s conceivable that deleting could be added through the > >> commenting process, but i am not certain. > >> > >> liam > >> > >> -- > >> Liam Quin, https://www.delightfulcomputing.com/ > >> Available for XML/Document/Information Architecture/XSLT/ > >> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > >> Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org > > > > _______________________________________________ > > mpeg-otspec mailing list > > mpeg-otspec at lists.aau.at > > https://lists.aau.at/mailman/listinfo/mpeg-otspec > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Tue Apr 23 20:43:50 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 23 Apr 2024 12:43:50 -0600 Subject: [MPEG-OTSPEC] On condvalue_spec.pdf Message-ID: Hi Skef, I'm implementing the ConditionValue proposal, and have some feedback. This is based on the following document: https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/condvalue_spec.md """ In "FeatureVariations Table", note that if minorVersion is 0 then only Condition Table version 1 can be used. If minorVersion is 1 then Condition Table version 2 can also be used. """ I highly suggest removing this. The minorVersion is for when new fields are added to FeatureVariations table itself. It should not be relied on for anything else. """ Add new subpart between "Condition Table Format 1: Font Variation Axis Range" and "FeatureTableSubstitution Table" with this content: """ Can we name Format1 simply ConditionAxisRange? That would go better with ConditionValue, ConditionAnd, ConditionOr, and ConditionNegate. """ On page 166: "Within the GPOS, JSTF, GDEF and BASE tables, delta-set indices are stored in VariationIndex tables." """ I don't understand this. What is a VariationIndex table? Thanks, behdad http://behdad.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Tue Apr 23 20:51:55 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 23 Apr 2024 12:51:55 -0600 Subject: [MPEG-OTSPEC] On condvalue_spec.pdf In-Reply-To: References: Message-ID: Also. Just confirming: are we spec'ing that all ConditionValue's in any table should use the GDEF ItemVarStore? This becomes important for VARC, which has a MultiItemVarStore, but no regular ItemVarStore itself. behdad http://behdad.org/ On Tue, Apr 23, 2024 at 12:43?PM Behdad Esfahbod wrote: > Hi Skef, > > I'm implementing the ConditionValue proposal, and have some feedback. This > is based on the following document: > > > https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/condvalue_spec.md > > """ > In "FeatureVariations Table", note that if minorVersion is 0 then only > Condition Table version 1 can be used. If minorVersion is 1 then Condition > Table version 2 can also be used. > """ > I highly suggest removing this. The minorVersion is for when new fields > are added to FeatureVariations table itself. It should not be relied on for > anything else. > > """ > Add new subpart between "Condition Table Format 1: Font Variation Axis > Range" and "FeatureTableSubstitution Table" with this content: > """ > Can we name Format1 simply ConditionAxisRange? That would go better with > ConditionValue, ConditionAnd, ConditionOr, and ConditionNegate. > > """ > On page 166: "Within the GPOS, JSTF, GDEF and BASE tables, delta-set > indices are stored in VariationIndex tables." > """ > I don't understand this. What is a VariationIndex table? > > Thanks, > > behdad > http://behdad.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Tue Apr 23 21:26:58 2024 From: skef at skef.org (Skef Iterum) Date: Tue, 23 Apr 2024 12:26:58 -0700 Subject: [MPEG-OTSPEC] On condvalue_spec.pdf In-Reply-To: References: Message-ID: On 4/23/24 11:43, Behdad Esfahbod wrote: > Hi Skef, > > I'm implementing the ConditionValue proposal, and have some feedback. > This is based on the following document: > units > https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/condvalue_spec.md > > """ > In "FeatureVariations Table", note that if minorVersion is 0 then only > Condition Table version 1 can be used. If minorVersion is 1 then > Condition Table version 2 can also be used. > """ > I highly suggest removing this. The minorVersion is for when new > fields are added to FeatureVariations table itself. It should not be > relied on for anything else. > That can be a solid suggestion for a future change. The proposals are in now. The thought was to try to discourage fonts that would look like they were compatible with the previous spec but contained new condition format types, but I suppose it doesn't really accomplish that anyway. Note that the existing (pre-working draft) Open Font Format specification screwed up the advice of what to do when a new condition format is added, referring to the version of a condition set, which doesn't exist. Therefore we don't really know what implementations will do when they encounter new condition types. The two obvious choices are "ignore" and "treat the condition set containing the condition as not applying, but unfortunately those are quite different. > """ > Add new subpart between "Condition Table Format 1: Font Variation Axis > Range" and "FeatureTableSubstitution Table" with this content: > """ > Can we name Format1 simply ConditionAxisRange? That would go better > with ConditionValue, ConditionAnd, ConditionOr, and ConditionNegate. > I recall seeing this in a recent draft of your proposal, so presumably that will happen. Seems fine to me. > """ > On page 166: "Within the GPOS, JSTF, GDEF and BASE tables, delta-set > indices are stored in VariationIndex tables." > """ > I don't understand this. What is a VariationIndex table? > That's, I believe, section 6.2.8 or alternatively https://learn.microsoft.com/en-us/typography/opentype/spec/chapter2#device-and-variationindex-tables (scroll down a bit from this anchor). But I'm not sure how that would be relevant to what you're currently implementing. Skef > Thanks, > > behdad > http://behdad.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Tue Apr 23 21:31:20 2024 From: skef at skef.org (Skef Iterum) Date: Tue, 23 Apr 2024 12:31:20 -0700 Subject: [MPEG-OTSPEC] On condvalue_spec.pdf In-Reply-To: References: Message-ID: I hope not. We discussed that https://github.com/harfbuzz/boring-expansion-spec/issues/104#issuecomment-1920031792 and decided on a convention for putting them in the MultiVarStore. That would still be my preference barring some reason not to. On 4/23/24 11:51, Behdad Esfahbod wrote: > Also.?Just confirming: are we spec'ing that all ConditionValue's in > any table should use the GDEF ItemVarStore? This becomes important for > VARC, which has a MultiItemVarStore, but no regular ItemVarStore itself. > > behdad > http://behdad.org/ > > > On Tue, Apr 23, 2024 at 12:43?PM Behdad Esfahbod > wrote: > > Hi Skef, > > I'm implementing the ConditionValue proposal, and have some > feedback. This is based on the following document: > > https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/condvalue_spec.md > > """ > In "FeatureVariations Table", note that if minorVersion is 0 then > only Condition Table version 1 can be used. If minorVersion is 1 > then Condition Table version 2 can also be used. > """ > I highly suggest removing this. The minorVersion is for when new > fields are added to FeatureVariations table itself. It should not > be relied on for anything else. > > """ > Add new subpart between "Condition Table Format 1: Font Variation > Axis Range" and "FeatureTableSubstitution Table" with this content: > """ > Can we name Format1 simply ConditionAxisRange? That would go > better with ConditionValue, ConditionAnd, ConditionOr, and > ConditionNegate. > > """ > On page 166: "Within the GPOS, JSTF, GDEF and BASE tables, > delta-set indices are stored in VariationIndex tables." > """ > I don't understand this. What is a VariationIndex table? > > Thanks, > > behdad > http://behdad.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Tue Apr 23 21:33:25 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 23 Apr 2024 13:33:25 -0600 Subject: [MPEG-OTSPEC] On condvalue_spec.pdf In-Reply-To: References: Message-ID: Sounds good. I'll adapt my implementation. behdad http://behdad.org/ On Tue, Apr 23, 2024 at 1:31?PM Skef Iterum wrote: > I hope not. We discussed that > https://github.com/harfbuzz/boring-expansion-spec/issues/104#issuecomment-1920031792 > and decided on a convention for putting them in the > MultiVarStore. That would still be my preference barring some reason not > to. > > > On 4/23/24 11:51, Behdad Esfahbod wrote: > > Also. Just confirming: are we spec'ing that all ConditionValue's in any > table should use the GDEF ItemVarStore? This becomes important for VARC, > which has a MultiItemVarStore, but no regular ItemVarStore itself. > > behdad > http://behdad.org/ > > > On Tue, Apr 23, 2024 at 12:43?PM Behdad Esfahbod > wrote: > >> Hi Skef, >> >> I'm implementing the ConditionValue proposal, and have some feedback. >> This is based on the following document: >> >> >> https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/condvalue_spec.md >> >> """ >> In "FeatureVariations Table", note that if minorVersion is 0 then only >> Condition Table version 1 can be used. If minorVersion is 1 then Condition >> Table version 2 can also be used. >> """ >> I highly suggest removing this. The minorVersion is for when new fields >> are added to FeatureVariations table itself. It should not be relied on for >> anything else. >> >> """ >> Add new subpart between "Condition Table Format 1: Font Variation Axis >> Range" and "FeatureTableSubstitution Table" with this content: >> """ >> Can we name Format1 simply ConditionAxisRange? That would go better with >> ConditionValue, ConditionAnd, ConditionOr, and ConditionNegate. >> >> """ >> On page 166: "Within the GPOS, JSTF, GDEF and BASE tables, delta-set >> indices are stored in VariationIndex tables." >> """ >> I don't understand this. What is a VariationIndex table? >> >> Thanks, >> >> behdad >> http://behdad.org/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Tue Apr 23 21:35:10 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 23 Apr 2024 13:35:10 -0600 Subject: [MPEG-OTSPEC] On condvalue_spec.pdf In-Reply-To: References: Message-ID: I think the use of MultiVarStore needs clarification in VARC doc. Liam, can we work on that? behdad http://behdad.org/ On Tue, Apr 23, 2024 at 1:33?PM Behdad Esfahbod wrote: > Sounds good. I'll adapt my implementation. > > behdad > http://behdad.org/ > > > On Tue, Apr 23, 2024 at 1:31?PM Skef Iterum wrote: > >> I hope not. We discussed that >> https://github.com/harfbuzz/boring-expansion-spec/issues/104#issuecomment-1920031792 >> and decided on a convention for putting them in the >> MultiVarStore. That would still be my preference barring some reason not >> to. >> >> >> On 4/23/24 11:51, Behdad Esfahbod wrote: >> >> Also. Just confirming: are we spec'ing that all ConditionValue's in any >> table should use the GDEF ItemVarStore? This becomes important for VARC, >> which has a MultiItemVarStore, but no regular ItemVarStore itself. >> >> behdad >> http://behdad.org/ >> >> >> On Tue, Apr 23, 2024 at 12:43?PM Behdad Esfahbod >> wrote: >> >>> Hi Skef, >>> >>> I'm implementing the ConditionValue proposal, and have some feedback. >>> This is based on the following document: >>> >>> >>> https://github.com/adobe-type-tools/opentype-spec-drafts/blob/main/condvalue_spec.md >>> >>> """ >>> In "FeatureVariations Table", note that if minorVersion is 0 then only >>> Condition Table version 1 can be used. If minorVersion is 1 then Condition >>> Table version 2 can also be used. >>> """ >>> I highly suggest removing this. The minorVersion is for when new fields >>> are added to FeatureVariations table itself. It should not be relied on for >>> anything else. >>> >>> """ >>> Add new subpart between "Condition Table Format 1: Font Variation Axis >>> Range" and "FeatureTableSubstitution Table" with this content: >>> """ >>> Can we name Format1 simply ConditionAxisRange? That would go better with >>> ConditionValue, ConditionAnd, ConditionOr, and ConditionNegate. >>> >>> """ >>> On page 166: "Within the GPOS, JSTF, GDEF and BASE tables, delta-set >>> indices are stored in VariationIndex tables." >>> """ >>> I don't understand this. What is a VariationIndex table? >>> >>> Thanks, >>> >>> behdad >>> http://behdad.org/ >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From liam at fromoldbooks.org Wed Apr 24 00:52:46 2024 From: liam at fromoldbooks.org (Liam R. E. Quin) Date: Tue, 23 Apr 2024 18:52:46 -0400 Subject: [MPEG-OTSPEC] On condvalue_spec.pdf In-Reply-To: References: Message-ID: On Tue, 2024-04-23 at 13:35 -0600, Behdad Esfahbod via mpeg-otspec wrote: > I think the use of MultiVarStore needs clarification in VARC doc. > Liam, can we work on that? Yes! -- Liam Quin,?https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: ?http://www.fromoldbooks.org