[MPEG-OTSPEC] Note on VARC conditions and condition set negation

[Skef Iterum]

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: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240411/4c902077/attachment-0001.htm>