<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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>
  </body>
</html>