Created attachment 131555 [details] Testing the +onum substitution at the beginning of a line Testing the new font engine on 5.3 I noticed that, for example, old style numerals (+onum) does not work if at the beginning of a line or after non alphabetical characters, but show properly when there are alphabetic characters before the numbers. See attached video for a real time demonstration. The font used for the test is Erewhon: http://www.ctan.org/tex-archive/fonts/erewhon but I can see the same problem on other OpenType fonts. Other substitutions (like small caps, +smcp) seems to work.
I tried with Linux Libertine G:onum=1 and it worked at the beginning of a line. Can you reproduce the problem with Linux Libertine G:onum=1 ? Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: ed0e8f970ff552e75222dc92ed2879aa3b3e5851 CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on March 4th 2016
(In reply to Buovjaga from comment #1) > I tried with Linux Libertine G:onum=1 and it worked at the beginning of a > line. > > Can you reproduce the problem with Linux Libertine G:onum=1 ? Linux Libertine G is a Graphite font and this problem is related with OpenType tables. Anyway, I found this problem testing the feature with four different fonts, but after reporting it I also found some _other_ fonts that do not display this strange behaviour... So now I'm starting to suspect on the typeface and my bad luck. I'll try to look more closely to the problem and report back my findings. If I found that the problems is with the font, I'll close this report.
Created attachment 131683 [details] Another example. All the text is set with "fbb:onum" I contacted the font author and he also see this problem under OSX. Other fonts that show the problem http://www.ctan.org/pkg/fbb http://www.ctan.org/pkg/baskervaldx A font from the same author that does NOT display the problem http://www.ctan.org/pkg/baskervillef According to the author, there is no difference on the onum table for those fonts, but the problem is there. Also, adding text _after_ the numbers also change the behaviour. See attached picture.
The font author found the problem and he is now fixing all his fonts. So I'm closing this as "resolved - invalid". Sorry for the noise.
(In reply to RGB from comment #4) > The font author found the problem and he is now fixing all his fonts. So I'm > closing this as "resolved - invalid". Sorry for the noise. Great news :) thanks for chasing this.