<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I can't imagine that an external table proposal could be ready by
the meeting time -- there are still a number of questions still to
be explored. We certainly aren't asking for that.<br>
</p>
<p>The concern we have about just adding the current variable
composite specification to the working draft is the "autopilot"
nature of ISO processes. Admittedly there will still be a later
vote (votes?) on whether to promote the working draft to the next
version of the standard, but that's all-or-nothing. And yes, we
can of course update the working draft incrementally, but if we
run out of time that could get tricky. </p>
<p>I suppose we're reasoning along the same lines as the principle
of "keep the main branch clean" -- that the working draft should
be kept, as much as possible, something that could be the next
standard if it needs to be. And therefore that generally speaking
new content should be added only when, as far as the Ad Hoc group
is aware at the time, it is what we expect to standardize. </p>
<p>However, opinions differ on this sort of thing and that's another
thing we can discuss in the meeting.</p>
<p>About April - Our preference is that if it's a choice between
having the <i>right</i> version of the variable composites
standard and having <i>some</i> variable composites standard
ready by April, we prefer the former. Of course, it would be
better not to have to make that choice.<br>
</p>
<p>Skef <br>
</p>
<div class="moz-cite-prefix">On 12/6/23 14:12, Liam R. E. Quin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ff1b06716c77bf8668524be618ff688db541526b.camel@fromoldbooks.org">
<pre class="moz-quote-pre" wrap="">On Tue, 2023-12-05 at 04:14 -0800, Skef Iterum wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Of course, in practice this means that we're asking that variable
composites be taken out of the upcoming proposal (and that if it
isn't Adobe will vote not to approve it, and encourage others to do
the same). However, we want to stress that this does not necessarily
mean we will not vote in favor later if further research indicates
that glyf is the better way to go.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Can we adopt a slightly different approach? We’re looking at coming up
with a proposal for an external table, outside GLYF, as you/Adobe
proposed, but in the meantime, since the ad hoc meeting is on Monday, i
can't really change the proposal we've submitted.
However, we do see the motivation, and the document is a working draft,
so it can be changed, and that's fine.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Accordingly, we also suggest that how to go about that research and
development, including who needs to be involved, should be one topic
for the meeting next week.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That's fine, i see Vlad added it to the agenda.
And it'd be OK to vote for the existing Google proposal to go ahead but
with variable composites removed, of course. Or, with the proviso that
a proposal for an external table be developed at least far enough for
concrete discussion.
I don't know that we can a new external-table proposal ready by Monday,
and in any case people won't have seen it. But we can put it in the
Boring Expansions repository and send email about it.
I'm sorry if we dropped the ball on the external table proposal;
silence in this case was not a sign of disagreement or disapproval or
anything; i should have pushed for discussion about it internally
here).
Anyway, either way is fine, but i want to avoid the situation where we
end up with no variable composites at all by April, so having at least
one approach, albeit a flawed one, in the working draft, might be
better than none? What do you think? Again, it's a working draft, so we
can take things out if a better approach is chosen, and that's true for
any part of the proposals.
Thanks,
liam
</pre>
</blockquote>
</body>
</html>