[MPEG-OTSPEC] Variable Composites and CFF2 (or other formats)

[Skef Iterum]

My thoughts on the two storage options:

The primary goal of the variable composites specification is to save 
disk space. I believe I've seen representations that the 
TupleVariationStore will be more compact /for typical variable composite 
use/ than an ItemVariationStore. This does seem true if an IVS is used 
with major/minor number mapping for every entry, but that isn't the only 
possible way of doing things. And frankly, /neither/ of the two seem 
well optimized for the VC use case "out of the box".

So, /if we primarily care about minimizing disk space/, we should do 
more research on storage and mapping will do that. If, on the other 
hand, we're OK with only /drastically reducing/ disk usage, and 
squeezing extra bytes out of the VC blocks isn't necessary, then I don't 
think Adobe would object to just going ahead with a TVS.

Skef

OK, the nitty-gritty:

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.

/Given the current spec/ there are two means of dealing with 
non-variable parameters:

 1. You can treat them as pseudo-variable, essentially adding 0 deltas
    for the index into the appropriate contexts in the TVS
 2. You can have each TVH sub-region "skip over" the index.

However, both of these solutions add overhead.

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. That would deal with the /primary/ 
problem. Whether that would leave the TVS as optimal, though, still 
seems like an open question.

On 12/6/23 14:16, Behdad Esfahbod wrote:
> Hi everyone,
>
> I support an external VARC table as well. Where we got stuck is in the 
> discussions of:
>
> https://github.com/harfbuzz/boring-expansion-spec/issues/103
>
> 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.
>
> It's good that we now have it on the agenda who is supposed to work on it.
>
> Thanks,
>
> behdad
> http://behdad.org/
>
>
> On Wed, Dec 6, 2023 at 3:13 PM Liam R. E. Quin <liam at fromoldbooks.org> 
> wrote:
>
>     On Tue, 2023-12-05 at 04:14 -0800, Skef Iterum wrote:
>
>     > 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.
>
>     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.
>
>     > 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.
>
>     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
>
>     -- 
>     Liam Quin, https://www.delightfulcomputing.com/
>     Available for XML/Document/Information Architecture/XSLT/
>     XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
>     Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
>     _______________________________________________
>     mpeg-otspec mailing list
>     mpeg-otspec at lists.aau.at
>     https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20231206/5b29edc9/attachment-0001.html>