[XeTeX] Res: overriding \addfontfeatures

[Flavio Costa]

> This isn't really a bug, it's a manifestation of how OpenType  
> features work and how the fonts are designed.

Since this is an expected OpenType behaviour, we cannot really call it a bug.

However, with a high-level interface like fontspec a different behaviour is expected. Grouping the mutually exclusive features may provide a solution for this, but maybe it's possible and easier to create a \setfontfeatures command: instead of just adding new features to the previously defined ones, it would ignore existing features and apply only the ones provided in the command parameter, so it would drop an existing +lnum and use only +onum for the current block. So this \setfontfeatures would be a kind of \newfontfamily, but changing only the features while keeping the current font, whatever it is.

Flavio Costa

----- Mensagem original ----
De: Jonathan Kew <jonathan_kew at sil.org>
Para: Unicode-based TeX for Mac OS X and other platforms <xetex at tug.org>
Enviadas: Quarta-feira, 4 de Junho de 2008 12:10:20
Assunto: Re: [XeTeX] overriding \addfontfeatures

On 4 Jun 2008, at 5:57 am, Will Robertson wrote:

> Okay, this is NOT a bug in fontspec.
> It might be a bug in the font, or it might be a bug in XeTeX.
>
> Take a look at the following example: (use Minion Pro if you don't  
> have Warnock Pro)
>
> \documentclass{article}
> \begin{document}
> \font\1="Warnock Pro:+onum" at 14pt \1 [123]
> \font\1="Warnock Pro:+lnum,+onum" at 14pt \1 [123?]
> \font\1="Warnock Pro:+lnum" at 14pt \1 [123]
> \font\1="Warnock Pro:+onum,+lnum" at 14pt \1 [123]
> \end{document}
>
> In the second case, I'd expect the +onum to override the +lnum, but  
> it doesn't; for some reason the +lnum has precedence. This seems to  
> happen for a number of Adobe fonts, at the very least.


When you list several features such as "+onum,+lnum", you're not  
specifying an ordered sequence of effects to be applied, but an  
unordered collection of features to be activated "together". Within  
the font, each feature is associated with one or more "lookups" wh
tutions or other effects. These  
lookups are applied in sequence according to their order in the font.

(Imagine a user interface where there's a check-box for each feature;  
you're just checking a collection of boxes, and the end result will  
be the same no matter which order you click them.)

So what's important is not the order in which you list the features,  
but the order in which the font designer arranged the lookups. And if  
you activate several features that potentially affect the same  
glyphs, the final result depends on how the designer built the font  
and arranged the lookups.

It seems that Adobe has chosen to arrange their lookups such that if  
'lnum' is used, the digit glyphs get replaced with alternate versions  
that are unaffected by the 'onum' lookup, and the 'lnum' lookup comes  
first.

Is this a bug in the font? I don't think so, it's a design choice  
(which you may or may not agree with). There is no single "right"  
answer for how features should interact.

Unfortunately, OpenType does not provide any mechanism for  
applications to know, in general, whether certain features interact  
or should disable each other; e.g., it really doesn't make sense to  
apply both 'sups' and 'subs' at the same time. In AAT, there are  
"exclusive" feature settings (presented as groups of radio buttons in  
the user interface), but OpenType doesn't have this, they're just  
individual on/off switches with no relation to each other.

JK

_______________________________________________
XeTeX mailing list
postmaster at tug.org
http://tug.org/mailman/listinfo/xetex



      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/