<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Maybe this is the most useful thing I can say at this point:</p>
<p>Almost all aspects of the various proposed extensions are tied <i>very
closely</i> to existing parts of the specification. Something
was 16 bit, now it's 24 bit. Cubic Beziers are added to the glyf
table, but using an encoding very close to quadratic Beziers. New
tables are added on the model of existing tables but can be
longer. And so forth.<br>
</p>
<p>From what I remember, when the existing TTF composite
specification was extended to support variable fonts the variable
parameters were limited to the positions of the components and the
side bearing points. That's both a more limited use of variable
parameters than in the variable composite specification, and also
a design somewhat determined by the way that ordinary glyphs work
in the glyf table (e.g. GVAR is already the mechanism for making
ordinary glyphs variable so why do something different?)</p>
<p>When it comes to the use of the TVS or some alternative,
therefore, one can't just look at the current spec and go "OK,
that's more or less the same thing". Or at least I can't. <br>
</p>
<p>It sounds like you have already done a bunch of engineering to
arrive at the current balance, but none of that information is
part of the proposal, which leaves that part of it difficult to
evaluate. What is the typical per-glyph overhead of the TVS
headers, if any? How much benefit will the shared point numbers
provide, if any? What is the overhead of a non-variable parameter
compared with just specifying its value?</p>
<p>The other typical way answering these questions -- going off and
looking at a bunch of examples -- is hampered by the lack of
shared prototype data. From what I recall there <i>is</i> test
data that has been used to develop these proposals, but it's not
public or shared with the group. <br>
</p>
<p>Perhaps one way out of this would be a brief "show the work"
document on this specific subject, explaining why the proposed
representation provides the best balance of file size and
simplicity.</p>
<p>Skef<br>
</p>
<div class="moz-cite-prefix">On 12/6/23 15:36, Behdad Esfahbod
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF63+7UshXjBxC_K_VOvOVXhun89UXZ7xV6+sTAif4atX12Y-g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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">
<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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">http://www.fromoldbooks.org</a><br>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">mpeg-otspec@lists.aau.at</a><br>
<a
href="https://lists.aau.at/mailman/listinfo/mpeg-otspec"
rel="noreferrer" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>