<div dir="ltr"><div dir="ltr">On Thu, Apr 11, 2024 at 2:40 PM Skef Iterum <<a href="mailto:skef@skef.org">skef@skef.org</a>> wrote:<br></div><div class="gmail_quote"><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>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.</p>
    <p>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?</p></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>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.</p></div></blockquote><div>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...</div><div> </div><div>> 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).<br></div><div><br></div><div>I agree.</div><div><br></div><div>b</div><div><br></div></div></div>