<div dir="ltr"><div dir="ltr">Thanks Skef,<div><br></div><div>Comments below:</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 6, 2023 at 4:09 PM Skef Iterum <<a href="mailto:skef@skef.org">skef@skef.org</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>OK, the nitty-gritty:<br></p>
<p>The primary problem I see with the TVS is that -- different from
the coordinates in a glyph -- one would expect that in a typical
composite glyph some parameters will be variable and some won't
be. Positions, for example, will often be variable. Rotations and
skews, probably not. Axis specifications -- it probably depends. </p>
<p><i>Given the current spec</i> there are two means of dealing with
non-variable parameters:</p>
<ol>
<li>You can treat them as pseudo-variable, essentially adding 0
deltas for the index into the appropriate contexts in the TVS</li></ol></div></blockquote><div><br></div><div>Note that zeroes are not encoded explicitly in the TVS. A flag and count is encoded of the number of zeroes.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><ol>
<li>You can have each TVH sub-region "skip over" the index.</li>
</ol>
<p>However, both of these solutions add overhead.</p>
<p>In thinking about this more recently (i.e. after the discussion
stopped) I've been wondering if it would just be best to add a
mask to the VC entry, with one bit per parameter padded out to
bytes, indicating whether the entry is variable or not. Then the
TVS indexes can be reduced to only actually variable parameters,
so that the bytes you pay for the mask are the only overhead.</p></div></blockquote><div>That was indeed part of the original VARC proposal from Black Foundry. I changed that to only include a bit for "axis coordinates are variable", because I think the TVS does a good job of encoding zeroes.<br> </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>That
would deal with the <i>primary</i> problem. Whether that would
leave the TVS as optimal, though, still seems like an open
question.<br></p></div></blockquote><div><br></div><div>The IVS is inherently subpar for this purpose IMO.</div><div><br></div><div>b</div><div><br></div><div><br></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>
</p>
<div>On 12/6/23 14:16, Behdad Esfahbod
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi everyone,
<div><br>
</div>
<div>I support an external VARC table as well. Where we got
stuck is in the discussions of:</div>
<div><br>
</div>
<div> <a href="https://github.com/harfbuzz/boring-expansion-spec/issues/103" target="_blank">https://github.com/harfbuzz/boring-expansion-spec/issues/103</a></div>
<div><br>
</div>
<div>where I was happy to go ahead and prototype a table with
TupleVariationStore. But Skef wants both TupleVariationStore
and ItemVariationStore paths to be explored, and that was
outside of my time budget.</div>
<div><br>
</div>
<div>It's good that we now have it on the agenda who is supposed
to work on it.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br clear="all">
<div>
<div dir="ltr" class="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 Wed, Dec 6, 2023 at 3:13 PM
Liam R. E. Quin <<a href="mailto:liam@fromoldbooks.org" target="_blank">liam@fromoldbooks.org</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">On
Tue, 2023-12-05 at 04:14 -0800, Skef Iterum wrote:<br>
<br>
> Of course, in practice this means that we're asking that
variable<br>
> composites be taken out of the upcoming proposal (and
that if it<br>
> isn't Adobe will vote not to approve it, and encourage
others to do<br>
> the same). However, we want to stress that this does not
necessarily<br>
> mean we will not vote in favor later if further research
indicates<br>
> that glyf is the better way to go.<br>
<br>
Can we adopt a slightly different approach? We’re looking at
coming up<br>
with a proposal for an external table, outside GLYF, as
you/Adobe<br>
proposed, but in the meantime, since the ad hoc meeting is on
Monday, i<br>
can't really change the proposal we've submitted.<br>
<br>
However, we do see the motivation, and the document is a
working draft,<br>
so it can be changed, and that's fine.<br>
<br>
> Accordingly, we also suggest that how to go about that
research and<br>
> development, including who needs to be involved, should
be one topic<br>
> for the meeting next week. <br>
<br>
That's fine, i see Vlad added it to the agenda.<br>
<br>
And it'd be OK to vote for the existing Google proposal to go
ahead but<br>
with variable composites removed, of course. Or, with the
proviso that<br>
a proposal for an external table be developed at least far
enough for<br>
concrete discussion.<br>
<br>
I don't know that we can a new external-table proposal ready
by Monday,<br>
and in any case people won't have seen it. But we can put it
in the<br>
Boring Expansions repository and send email about it.<br>
<br>
I'm sorry if we dropped the ball on the external table
proposal;<br>
silence in this case was not a sign of disagreement or
disapproval or<br>
anything; i should have pushed for discussion about it
internally<br>
here).<br>
<br>
Anyway, either way is fine, but i want to avoid the situation
where we<br>
end up with no variable composites at all by April, so having
at least<br>
one approach, albeit a flawed one, in the working draft, might
be<br>
better than none? What do you think? Again, it's a working
draft, so we<br>
can take things out if a better approach is chosen, and that's
true for<br>
any part of the proposals.<br>
<br>
Thanks,<br>
<br>
liam<br>
<br>
-- <br>
Liam Quin, <a href="https://www.delightfulcomputing.com/" rel="noreferrer" target="_blank">https://www.delightfulcomputing.com/</a><br>
Available for XML/Document/Information Architecture/XSLT/<br>
XSL/XQuery/Web/Text Processing/A11Y training, work &
consulting.<br>
Barefoot Web-slave, antique illustrations: <a href="http://www.fromoldbooks.org" rel="noreferrer" target="_blank">http://www.fromoldbooks.org</a><br>
_______________________________________________<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>
</blockquote>
</div>
</blockquote></div></div>