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

[Behdad Esfahbod]

Thanks Skef,

Comments below:

On Wed, Dec 6, 2023 at 4:09 PM Skef Iterum <skef at skef.org> wrote:

> 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
>
>
Note that zeroes are not encoded explicitly in the TVS. A flag and count is
encoded of the number of zeroes.



>    1. 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 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.


> That would deal with the *primary* problem. Whether that would leave the
> TVS as optimal, though, still seems like an open question.
>

The IVS is inherently subpar for this purpose IMO.

b




> 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/8fa1a40c/attachment.html>