<div dir="ltr">Hi Skef,<div><br></div><div>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.</div><div><br></div><div>A "negate the rest" condition type sounds good to me.<br></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">behdad<br><a href="http://behdad.org/" target="_blank">http://behdad.org/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2024 at 1:55 PM Skef Iterum via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  

    
  
  <div>
    <p>A note on conditions as defined in
      WG03-varc-and-other-updates-03.pdf (up for review tomorrow
      morning).</p>
    <p>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.</p>
    <p>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 <i>set</i> can
      be expensive and/or tricky. So I would recommend that one of these
      two things change:<br>
    </p>
    <ul>
      <li>The if/else if/.../else semantic is restored</li>
      <li>Some way of negating a condition set is added to the
        specification<br>
      </li>
    </ul>
    <p>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:<br>
    </p>
    <blockquote>
      <p>ConditionTableFormat5</p>
    </blockquote>
    <blockquote>
      <p><b>Type                    Name                               
          Description</b></p>
      <p>uint16                  Format                             
        Format (set to 5)</p>
    </blockquote>
    <blockquote>
      <p>When present in a condition set this condition indicates the
        set should apply when<br>
        at least one of the other conditions is false and not otherwise.
        That is, it makes the<br>
        condition set apply when it would normally not and vice-versa.
        There should be at <br>
        most one format 5 condition in a condition set and it should be
        the first.<br>
      </p>
    </blockquote>
    <p>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<br>
      with the "positive" condition set with another record with the
      negated one when needed).</p>
    <p>Skef<br>
    </p>
  </div>

_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div>