<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Vladimir reminded me that there were some outstanding issues
relating to flags, conditions, and condition sets. I'm just going
to give my views on this subject briefly.</p>
<h4>Do condition tables need flags? </h4>
<p>The main use case for a flag we discussed was to negate the
condition, and in my view using a different format number is both
more compatible (in that the existing type doesn't change) and
more compact. One could split the existing uint16 format field
into a format and flags, but given that the existing format is 1
the flags would come in the first byte rather than the second. <br>
</p>
<h4>Do condition sets need to be negate-able?</h4>
<p>The only use of condition sets in the working draft is part of
the Feature Variations mechanism, and Adobe's proposal for
updating that system supports something equivalent to a negated
condition set (the set of lookups to add when at least one
condition is false). So until condition sets are used elsewhere
(perhaps in VARC) the need for explicit negated condition sets is
speculative.</p>
<h4>How would we make condition sets negate-able?</h4>
<p>Condition sets don't have flags for a format field, so there's no
entirely clean way of altering their behavior. The least ugly way
that I've thought of is to add a special offset value with that
meaning to the list, e.g. 1 or 2. </p>
<p>(One could imagine not implementing explicitly negated conditions
at all, and instead making an offset of 1 mean "negate the whole
set", 2 mean "negate the condition at the following offset" and
perhaps even an offset of 3 mean "or". However, there are already
other means of achieving what amounts to an "or" and this kind of
a approach seems hacky. Still, just adding the 1 with that meaning
might be the best solution for negating the set if we need that.)</p>
<p>Skef<br>
</p>
</body>
</html>