Hi Ulrike! ···<Datum: Wednesday, 12. March 2014>···<Von: Ulrike Fischer>···
> 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().
> (with mode=node +sups wins always).
No idea why. Xetex appears to prefer onum …
Best regards,
Philipp
pgpodKkA4jXru.pgp
Description: PGP signature
