Re: OpenType and font-variant support

[Behdad Esfahbod <behdad behdad org>]

Pango already has infrastructure in place to apply arbitrary OpenType
features.  The only missing piece is a PangoAttribute for them.  See:

  http://bugzilla.gnome.org/show_bug.cgi?id=460831

Also:

  http://bugzilla.gnome.org/show_bug.cgi?id=439298

behdad


On Mon, 2008-06-30 at 00:30 +0000, Steven Robertson wrote:
> 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
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759