[MPEG-OTSPEC] Variable Composites and CFF2 (or other formats)
Skef Iterum
skef at skef.org
Thu Dec 7 04:59:03 CET 2023
Maybe this is the most useful thing I can say at this point:
Almost all aspects of the various proposed extensions are tied /very
closely/ 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.
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?)
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.
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?
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 /is/ test data that has been used to
develop these proposals, but it's not public or shared with the group.
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.
Skef
On 12/6/23 15:36, Behdad Esfahbod wrote:
> 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/a36d0054/attachment-0001.html>
More information about the mpeg-otspec
mailing list