14

I’m using the Linux Libertine font and have old style numbers enabled.

However, in a certain context I want to use lining figures instead. Normally I should be able to switch using \addfontfeature but this doesn’t work. MWE:

\documentclass{minimal}
\usepackage{fontspec}
\setmainfont[Numbers=OldStyle]{Linux Libertine}

\begin{document}
C++0x

C++{\addfontfeature{Numbers=Lining}0}x

{\fontspec{Linux Libertine}C++0x}
\end{document}

The output looks like this:

C++ox
C++ox
C++0x

However, the second line should look like the third, not like the first. Setting other font features (i.e. slashed zero) doesn’t work either.

Additionally, if I use another font (e.g. Hoefler Text) then the output is as expected.

Does somebody have an idea what’s going on here?

Konrad Rudolph
  • 39,394
  • 22
  • 107
  • 160

1 Answers1

13

Here's a workaround to your problem (which is a known issue with respect to how adding font features works (see commentary here and here)). The solution is to define a new fontface and use that to change the number style:

\documentclass{minimal}
\usepackage{fontspec}
\setmainfont[Numbers=OldStyle]{Linux Libertine}
\newfontface\lining[Numbers=Lining]{Linux Libertine}
\begin{document}
C++0x

C++{\lining0}x

{\fontspec{Linux Libertine}C++0x}
\end{document}

In general if you are going to be switching fonts its best to use the \newfontfamily or \newfontface commands to make the switch into a macro rather than calling fontspec directly.

Alan Munn
  • 218,180
  • @Alan: I’m not switching fonts (at all) in my document. The \fontspec example was just to illustrate that the lining figure actually works when this font is loaded directly. Anyway, thanks for the info that this is potentially a bug. I guess I’ll use your workaround then. – Konrad Rudolph Feb 13 '11 at 14:51
  • @Konrad answers are for everyone :-) which is mainly why I added the comment about switching fonts. Although I think the \newfontface (or family) solution is actually preferable to the \addfontfeature route anyway. But your example should work as advertised. – Alan Munn Feb 13 '11 at 15:18
  • 1
    I don't think that is a bug of fontspec. If you use \addfontfeature you add both open type features to the feature list and the result depends mostly on how they are implemented in the font. See also this post of Jonathan Kew: http://tug.org/mailman/htdig/xetex/2008-June/010015.html. So if you want to use "conflicting" features you shouldn't use \addfontfeature. – Ulrike Fischer Feb 13 '11 at 15:22
  • @Alan: True, true. But \addfontfeatures has the advantage of working regardless of the parent font family. In fact, this is an issue in my case – now I need to redefine the relevant variable for each font family (roman, sans and mono) which makes this whole thing needlessly complicated. – Konrad Rudolph Feb 13 '11 at 15:25
  • @Ulrike: I’m not convinced. If font features conflict, the last declaration should override previous declarations, otherwise \addfontfeature is a bit meaningless. I wouldn’t necessarily call it a “bug” but at least a missing feature. – Konrad Rudolph Feb 13 '11 at 15:28
  • 1
    @Ulrike See also this thread. It seems that Will recognizes it as at least an issue. – Alan Munn Feb 13 '11 at 15:30
  • @Konrad. Did you read Jonathans explanations in the link I mentioned? To be able to override previous declarations \addfontfeature can't simply add something to the featurelist, it would have to go through the list and actively remove some of the features. That's not easy to implement. – Ulrike Fischer Feb 13 '11 at 15:35
  • @UlrikeFischer “it would have to go through the list and actively remove some of the features” – yes, I was aware of this. In fact, the OS X typography selector dialog has the same behaviour as fontspec. But this doesn’t make the behaviour desirable (nor, arguably “right”), and I think that my particular use-case makes a very strong case for this. in fact, I’m unable to get the code to work for arbitrary font families but this may be due to my own inability to correctly redefine the font family depending on the current font. I’ll post a follow-up question about this. – Konrad Rudolph Feb 13 '11 at 15:43
  • 2
    So, yeah, fontspec should be better behaved w/r/t all of this; @Alan's links describe the situation to a tee. (In fact, they—the links—are better than I'd be able to produce at a pinch!) Sorry for the inconvenience; one day I hope we'll do better. – Will Robertson Feb 13 '11 at 16:33
  • 1
    @Will would it be possible to construct a list of (logically) mutually incompatible font features so that \fontspec_define_fontfeature_option could be modified to set and unset them automatically? – Alan Munn Feb 13 '11 at 21:24
  • @Alan yep, that would be the idea. Just a matter of time... – Will Robertson Feb 13 '11 at 23:54
  • 1
    A \removefontfeatures or improvements to \addfontfeatures will solve the actual problem. But the general problem is that the font type (rm, tt, sans ...) is not independant from the font family. There can be only one rmfamily font. This is e.g. also a problem when more than one script is involved. You can't declare rm + tt fonts for both scripts. Polyglossia has some commands to adress this problem (\rmfamilytype, familytype) but doesn't do very much with them. – Ulrike Fischer Feb 14 '11 at 09:13