[MPEG-OTSPEC] Some thoughts on the "under consideration" proposals

[Skef Iterum]

Josh Hadley just sent some feedback on behalf of Adobe about the recent 
OpenType extension proposals, which among other things alludes to future 
meetings. I believe that the best way forward for those ideas, dealing 
with other lingering VF issues, and anything else that needs discussion 
is for the relevant parties and knowledgeable experts to come together 
in a representative working-group-like structure. Unfortunately this is 
trickier than it looks, as a context for representation needs some 
degree of consensus and doesn't just arise out of form.

I hope it happens.

At the same time, however, I sense that a lack of substantive responses 
to these proposals, which have been circulating in various forms and 
contexts for many months now, has itself become an entirely 
understandable source of frustration. If there are concerns, the 
sponsors should be able to at least start considering and addressing 
those concerns sooner rather than later. As Vladimir noted, feedback on 
this list outside of meetings has its own value. (He also said "silence 
is approval", which I'm not sure really works in practice, but is 
probably a nicer way of saying "put up or shut up".)

In that spirit, I've written up some questions and opinions about the 
proposals. I want to stress that:

 1. This is my personal input, not that of Adobe.
 2. I am not personally trying to proxy for Adobe in my feedback.
    Indeed, in several instances I /am/ attempting to proxy for /other/
    companies, in that I'm predicting objections or concerns based on
    past design considerations of those companies. They may not care at
    this point! Still, I think these things are worth discussing.
 3. Accordingly, I wouldn't necessarily raise all of these issues if I
    were asked about my concerns with these proposals as an individual.
    Almost all, but not all.

With that, my notes are below, in close-to-markdown format.

Skef

# General topic 1: Compatibility Model

The proposal has little to say about compatibility explicitly, but if one
compares the specification after any or all of the additions to the current
specification it is clear that the model is backward compatibility, in which
fonts produced according to the previous specification are compatible with the
current one but not vice-versa. This is not the model used by either of the two
main technology lineages for recent changes.

The TrueType/glif lineage has primarily used, and some of its advocates have
insisted on, a forward compatibility model, where a font produced according to
a later specification will still work with an earlier one. This has extended
even to variable font technology, so that if a user with an older system
attempts to use a variable font they will get a correct application of the
font's default instance. This is why, for example, variable outline data is
stored separately in an added gvar table.

The OpenType/CFF lineage has preferred a top-to-bottom replacement model for
incompatible changes. For example, rather than updating the version of the CFF
table to support variable font technology, the specification was updated but
then specified as a new table with a distinct "CFF2" tag. In theory, at least,
this allows for a single font to include both CFF and CFF2 tables, making it
compatible with both the old and new specifications. (The CFF table might
contain the regular weight of the font, creating a user experience similar to
that of a TrueType variable font.)

A backward compatibility model is generally easier to implement than either of
these other approaches, and can work fine in contexts where software versions
are aggressively and systematically updated, or where the fonts in question are
only "delivered" along with software updates. Unfortunately, much of the world
of software does not work like this.

In cases where one *must* result to backward compatibility, however, it works
best for the introduction of major new *customer visible* features: You
announce that your fonts can now do X, as long as a user's software system is
upgraded to help do X. Then the user can check their own system for
compatibility, and there is an understandable story if things don't go well.

 From that perspective, these proposals are an awkward fit for a backward
compatibility introduction. Only the avar proposal offer something truly new
from the perspective of a typical user (assuming that higher order
interpolation without those changes is too flaky for real-world use). It is
doubtful that more than a handful of users understand there is currently a 65K
limit on glyphs in the OpenType standard, so even if some users' experiences
will improve with a larger limit, they likely won't understand what they are
"missing" now. And while the cubics-in-glyf and variable component changes will
open up options for font designers and implementers, the only real result for a
user will be decreased file size. (Cubics are, after all, available as part of
CFF and a quadratic can be precisely converted into a cubic.)

The result of adding these changes will therefore be the creation of a new
class of fonts that will be incompatible with many older systems but that
provide, at most, weak motivations for updating those systems from the
perspective of an end-user. This, in turn, could lead to weak adoption and
stymie further changes to the specification.


# General topic 2: Magnitude of cost vs magnitude of benefit

Adding either cubics or variable components to the glyf specification
constitute large changes that effectively abandon the chance of forward
compatibility (although not top-to-bottom replacement, if the implementation
were somewhat different.)

And as already pointed out, the impact of these changes on font technology is
rather modest. Cubics are already available in CFF.  The component proposal is,
in terms of end-user functionality, a data compression system. This gap in cost
vs impact doesn't necessarily argue against the change but it does raise the
question: Is there really nothing else we want to add while we're breaking
everything?

This is a hard question to answer conclusively, but one clear candidate would
be rational quadratic Beziers. This is not the place to make an extensive
argument for rational quadratics, but:

1. Current practice (e.g. in Skia) shows them to be of interest and use.
2. They are similar enough to the already-supported path elements that adding
    support to renderers is likely straightforward.
3. As mathematical objects, they are much more amenable to fitting than
    non-rational quadratics (where end-tangents determine the curve shape) and
    cubics (where fitting while preserving end-tangents involves awkwardly moving
    the two control points along their respective lines). Accordingly, workflows
    that start with curves or abstractions beyond non-rational Beziers but that
    still produce high-quality and compact output could become more common if they
    are available.

This and other options should be seriously considered as part of making a
change that breaks compatibility.


# General topic 3: Hinting

I say more about hinting in two sections below, but the lack of discussion in
the proposal raises the overall question: does Google see these changes as part
of a post-hinting future? Or perhaps a future that is still compatible with
hinting but only if one avoids some substantial new features? Either way, this
is something the specification should address.


# Topic: Cubics in glyf

## Interpolated on-curve points

The convention of interpolated on-curve points for *quadratic* Beziers can be a
source of confusion for newcomers to the TrueType specification (e.g. it was
for me), but it has clear motivations that extend all the way up into (some)
design tools: While an interpolated point between two quadratic Beziers
won't typically be C_2 continuous, it is often close relative to human
perception. Some design tools accordingly allow paths to be drawn out
picking only control points, or allow an on-curve point to be marked as
interpolated so that adjusting an adjacent control point will recenter it.

It's less clear that these motivations apply to Cubic Beziers, especially given
that the curvature at the end of a Cubic Bezier depends on the locations of
both adjacent control points. If there are no such tools or conventions, then
the motivation for adding the interpolation convention amounts to a reduced
file size, which raises the question: How common, across typical fonts, are
cubic knots centered between their adjacent control points, and are they common
enough to warrant the confusion this convention adds to the specification?
Clearly those knots occur in circle and oval shapes (the particularly confusing
case in which there may be no on-curve points at all). Maybe this is enough
reason, but there should be discussion.

## Hinting

The ISO document says nothing about hinting/TTF instructions. Some drafts
circulated elsewhere have said something along the lines of "hinting is
unaffected". This should be spelled out in more detail. Is hinting of glyphs
that include Cubics possible?  To what extent is it possible? Given that cubics
have more exotic potential behavior than quadratics (cusps, loops) what is the
risk of running into strange behavior when hinting?

If the spec itself allows for reasonable hinting, what about existing
toolchains? How much of current practice is manual hinting vs automatic? Do
TTF autohinters need to be updated, and how? Etc.


# Topic: Variable components

## General approach

There seems to be a fair amount of churn and complexity in this proposal
related to compatibility with gvar and more generally with 16 bit values. For
example, the current spec has more or less one fixed point type while this one
adds two more to get the right magnitudes for scaling, rotation, and skewing
(see below). `gvar` was itself designed as part of the forwardly-compatible
addition of variable font support. So one general question is whether it might
make more sense to just start over with some of this infrastructure.

## Mathematical detail

Some sections in the specification that describe involved fixed-point
calculations (e.g. for avar) provide guidance on how and when to convert
precisions, round values, and so forth, so that such calculations are
consistent across implementations. (Some other sections that don't have this
probably should.) Given the generality of this specification and the potential
impact of rounding (e.g. some path is reduced in size in one composite glyph
which is then magnified in a further composite glyph), such guidance seems
particularly relevant to this implementation.

Along those lines, most implementations probably use integers for point
coordinates even if they use floating point representations for other values.
It looks like scale factors in the current specification are F2DOT14, which at
least suggests only modest *increases* in scale. This new specification uses
F6DOT10, suggesting wider changes in scale as one moves through a component
hierarchy. Will using integers for these calculations provide enough precision?
Are implementations expected to trace through the component hierarchy combining
transforms, so that each "simple" glyph is only transformed once, or can they
apply individual transforms as they go?  What about the related questions of
caching the point values of "intermediate" components?

Perhaps, like other elements of the current spec, just because something is
possible (e.g. shrinking outlines in one composite and then magnifying them in
another) doesn't mean it's a good idea. However, this just makes it all the
more important to clarify what is expected to work reliably so that
implementations can calculate accordingly.

(Also, with respect to the two additional floating point types, might it be
preferable to encode these values as F2DOT14 and then specify scaling factors
to get the desired magnitudes in other representations? Implementations often
have special handling for specific fixed-point types, so often the fewer the
better.)

## Hinting

My knowledge of TT hinting is limited, but it looks like instructions are
currently only stored with non-composite glyphs. How viable is hinting in this
new system, especially given skew and especially rotation?

I understand that this question may sound somewhat unfair given that the
existing spec also allows general affine transformations using the "TWO_BY_TWO"
option. However, that possibility doesn't strongly advertise itself in the
current specs. (ISO says "This could be used for 90-degree rotations of glyph
components, for example.") Asking around, it also doesn't appear the use of
rotation by means of TWO_BY_TWO is very common in current practice.

These changes suggest a general framework analogous to that added by COLR v1
and advertise the transformation factors up-front, with a promise of
significant file size savings. How compatible is the existing hinting model
with wide use of these proposals? If it is only partially compatible, should
there be documentation on how to stay within the region of possibilities that
is compatible? Should the overall design change to increase compatibility? For
example, should it be possible to add instructions to composite glyphs that
override some or all instructions imported through the component system?


# Topic: Glyph Capacity

## Pseudo-forward compatibility

The proposal retains number of the existing table structures to reduce the
amount of change needed, even though it does not seem that any implementation
that has not been updated will be able to correctly use a font making use of
these new table formats. Is it really best to keep maxp as a short? And to keep
the partial limits on hmtx and vmtx?  Are these aspects of the proposal just to
minimize implementation costs? Etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/mailman/private/mpeg-otspec/attachments/20230630/15f415a2/attachment-0001.html>