[luatex] luaotfload: Random font changes with mode=base

[Ulrike Fischer]

Am Wed, 12 Mar 2014 20:31:30 +0100 schrieb Philipp Gesang:

>> If I compile this document more than once (I think I have now
>> compiled it and similar documents around 200 times ;-))
>> 
>> \documentclass{scrreprt}
>> \usepackage{luaotfload}
>> \font\sup={name:Linux Libertine O:+onum;+sups;mode=base}
>> \begin{document}
>> abc\sup123467
>> \end{document}
>> 
>> then in around 50% of the pdf the numbers are (as wanted)
>> superscripts, and in the other pdf the numbers are normal old style
>> numbers. 
> 
> Confirmed for version 0.78.2 (4746) and the most recent
> fontloader as part of Context, version 2014.03.07 11:42.
> 
> Here’s the code for Plain and Context:
> 
>     https://bitbucket.org/phg/lua-la-tex-tests/src/5460c0b7718a49f4831adacd84b9791e10e305f1/pln-superscript-textfigures-1.tex
>     https://bitbucket.org/phg/lua-la-tex-tests/src/47f2f2e7dcd605a8744357aa9a7996ec9525e75c/cnt-superscript-textfigures-1.tex
> 
>> I can accept that you can't combine onum + sups, but why is the
>> result so random?
> 
> Lua makes no guarantees about the order of indexes on the hash
> part of tables. The behavior you observed is consistent with the
> feature strings being used as indices (which indeed they are) and
> then iterated over with next().

Ah. This makes sense. That's the first time that I had to make a
statistic while debugging a problem ;-). 


>>                   (with mode=node +sups wins always).
 
> No idea why. Xetex appears to prefer onum …

Perhaps because of the order. I didn't make tests with xelatex (but
I remember from an old discussion that conflicting features like
+onum,-onum can be difficult there too).

But this problems shows again that \addfontfeatures is a bit
problematic -- and that one needs a "\removefontfeatures". 

-- 
Ulrike Fischer 
http://www.troubleshooting-tex.de/