Re: OpenType and font-variant support

["Steven Robertson" <nihilismwow gmail com>]

On second thought...

After exploring the code and specifications more thoroughly, I
realized that the proposal in the previous mail is naive and not
backwards-compatible.  Kindly ignore most of it.

I'd like to get comments on the issues and ideas I've had since
gaining a deeper understanding of the interaction between Pango and
OpenType. I imagine that these points are obvious to Pango's
developers, but it is useful to state them for those less familiar
with the potential pitfalls.

--

There are, in my opinion, far too many distinct published OpenType
feature tags to explicitly support each one with its own boolean
property.  Even a comma-separated list of humanized names, as
suggested previously, is insufficient, not only for reasons of size
but also because the order is critical in some cases (ex: applying
'liga' before 'smcp' means that common ligatures, like ffi and Th,
contain regular lower-case letters instead of small capitals).  This
would be unpleasant to maintain.

On the other hand, simply providing direct access to the lists of
enabled GSUB and GPOS tags poses too much implementation work for most
of Pango's users.  This is because different shape engines have
different sets of default parameters, so writing code for a check-box
that says "Small Caps" goes from a couple lines to dozens.  With such
a design, applications can very easily make changes that will disrupt
the default settings, which isn't so bad for Latin scripts but is
unacceptable for others.  This solution is too prone to failure,
especially considering that the most intrusive bugs may only show up
in a language other than the developer's native one.

Picking and choosing which OpenType features to support also seems
like headaches in the making.  I imagine a number of "You support X,
why don't you support Y" issues popping up as a result of that, which
will either persist ad nauseum or result in piecemeal adoption of an
excessive number of tables.

One final problem is worth noting.  Consider a hierarchical document
of some sort, where font attributes can be inherited from a parent
element. (HTML, SVG, even ODT and Word do this.)  Every existing
attribute (at the Pango level) can either be inherited, or it can be
overridden, but not both; for example, you cannot set font-size to
"larger" at the Pango level, because Pango does not understand a
document's hierarchy.  This is fine for existing attributes, because
it isn't much work for a document engine to keep track of hierarchy
for properties with only one value.  However, it must be kept in mind
when implementing any property that takes the form of a list.  If I
have a text segment in a document which uses 'tnum' (tabular figures),
and I wish to set a line with 'smcp' (small capitals), the program
will have to somehow combine the 'tnum' flag with the 'smcp' flag.  It
is important that this process be as simple as possible to accomplish
programmatically, and ideally should require no knowledge of OpenType.

--

At this time, I believe that a hybrid between the two models is the
wisest choice.  This hybrid would require the addition of two
attributes to Pango's library, which for the sake of discussion I will
call 'ot_features' and 'ot_tags'. Also for the sake of discussion,
consider a font which supports the 'kern', 'liga', and 'smcp' features
(kerning, default ligatures, and small capitals, respectively), and
assume that the 'kern' and 'liga' features are on by default.

ot_tags is a string-based property which allows more-or-less raw
access to the list of OpenType Layout tags that will be enabled for a
text segment.  The argument takes the form of a comma-separated list;
each item on the list can either be a tag, such as 'smcp', to append a
feature to the list of those to be enabled, or a tag prefixed with a
hyphen, as in '-liga', to remove that feature from the list.  This
allows a developer to get as technical as he or she needs to without
requiring knowledge or code pertaining to any other tags (or scripts).
 For example, as mentioned above, the substitutions specified by
'smcp' must come before those specified by  'liga', but 'liga' is in
the set of default options, so 'smcp' will always come after 'liga'.
Setting ot_tags="-liga,smcp,liga" ensures proper operation.  Another
incentive of this method of setting individual tags is that
inheritance is as simple as concatenation, making implementing it in
applications and Pango-based toolkits a snap.

ot_features is a list of which of the most commonly-used OpenType
features to enable; by default, no features will be shown as enabled
in this list (implying that features like kerning, which are always
enabled by default, will not be in this list).  While the mapping of
ot_features to OpenType feature tags is usually one-to-one, some
instances (like for small caps) require reordering or disabling of
mutually-exclusive tags; this will be accomplished in the same way as
those for ot_tags - in fact, setting ot_features may actually update
ot_tags to ensure consistency.  ot_features should probably be a
bitfield to keep it simple, and the items it supports would be derived
from a look at which OpenType features are most commonly exposed in
applications.

--

The two properties mentioned above, while considerably more feasible
than reusing 'variant', do still suffer from a few limitations.
Foremost among these is a lack of any way to determine the OpenType
Layout tags that are available and enabled by default for a particular
font or script.  While this information isn't necessary to accomplish
most tasks programmatically, it is important for UI feedback in many
applications.  An associated problem is that the information for tags
enabled by default isn't available until the script and text direction
(vertical or horizontal) is known.  I do not yet have a solution in
mind, but I'll keep looking into it.

Thanks,
Steven