Side effects between two fonts

[u-fischer]

I got informed about a rather curious side-effect when two specific fonts are used together (one of them is (sadly) not free. \setmainfont{calibri} instead of John Sans Pro shows the problem too, but not so obvious:

\documentclass{scrartcl}
\usepackage{fontspec}
\usepackage[ngerman]{babel}
\setmainfont{John Sans Text Pro}
\setsansfont{Consolas}
%\setsansfont[Renderer=Basic]{Consolas}

\begin{document}
Das \textsf{d} Authentifizierungsfenster  

\textsf{d} Das Authentifizierungsfenster  

Das \textsf{d} Authentifizierungsfenster  
\end{document}

This gives the following output when compiled on TeXLive 2014 on windows:

The language is important (probably because with ngerman there is a hyphenation point after the fi). The problem disappears if I change Consolas e.g. to Arial. It also disappears if I use the basic renderer with Consolas. And even more confusing : It disappears if one puts the "Das" in an box: \mbox{Das} \textsf{d} Authentifizierungsfenster.

Perhaps connected: http://tex.stackexchange.com/questions/47031/in-lualatex-hyphenation-doesnt-seem-to-work-for-words-that-contain-certain-lig

Ulrike Fischer

[phi-gamma]

Thanks for the report! I tried with Calibri, as you suggest, but the output looks like this:

[u-fischer]

I retested on my rather new laptop with windows 8.1. with an up-to-date TeXlive 2014 and can reproduce it there too.

I removed the depedency from fontspec:

\documentclass{article}

\usepackage{luaotfload}
\usepackage[ngerman]{babel}
\font\testa={Calibri:mode=node;script=latn;}
\font\testb={Consolas:mode=node;script=latn;}
\pagestyle{empty}
\begin{document}
\testa Das {\testb d} Authentifizierungsfenster
\end{document}

The fonts used are the default fonts of windows: <c:/windows/fonts/consola.ttf><c:/windows/fonts/calibri.ttf>. And the lua/luc-files are "new".

The script=latn is relevant. If it is removed from one of the fonts the effect disappears. It doesn't matter which mode is used with calibri, but consolas must use mode=node to see the problem. (Curiously the problem disappeared also when I made a typo and used "mode=mode" in Calibri).

I don't see here a way to attach files here but if you want I could sent you the lua/luc-files of the fonts, the pdf and/or the font files. (Or you can sent me yours and I do the comparisions).

[phi-gamma]

···<date: 2015-02-28, Saturday>······

I retested on my rather new laptop with windows 8.1. with an up-to-date TeXlive 2014 and can reproduce it there too.

Thanks for the reply and the testing! However, I have trouble reproducing your results: In your example I get the same output with base mode and node mode (your mode=mode appears to have been triggered a fallback to base mode).

The fonts used are the default fonts of windows: <c:/windows/fonts/consola.ttf><c:/windows/fonts/calibri.ttf>. And the lua/luc-files are "new".

Could you state which versions of the fonts we are dealing with in your case? E. g. paste the output of:

luaotfload-tool --list='format' | egrep -i '(calibri|consolas)'

but I have no idea how that’d translate to a windows environment ;)

Best Philipp

···<date: 2015-02-28, Saturday>······

I retested on my rather new laptop with windows 8.1. with an up-to-date TeXlive 2014 and can reproduce it there too.

I removed the depedency from fontspec:

\documentclass{article}

\usepackage{luaotfload}
\usepackage[ngerman]{babel}
\font\testa={Calibri:mode=node;script=latn;}
\font\testb={Consolas:mode=node;script=latn;}
\pagestyle{empty}
\begin{document}
\testa Das {\testb d} Authentifizierungsfenster
\end{document}

The fonts used are the default fonts of windows: <c:/windows/fonts/consola.ttf><c:/windows/fonts/calibri.ttf>. And the lua/luc-files are "new".

The script=latn is relevant. If it is removed from one of the fonts the effect disappears. It doesn't matter which mode is used with calibri, but consolas must use mode=node to see the problem. (Curiously the problem disappeared also when I made a typo and used "mode=mode" in Calibri).

I don't see here a way to attach files here but if you want I could sent you the lua/luc-files of the fonts, the pdf and/or the font files. (Or you can sent me yours and I do the comparisions).

---

Reply to this email directly or view it on GitHub: https://github.com/lualatex/luaotfload/issues/265#issuecomment-76525191

[u-fischer]

This are the fonts versions (first number windows 7, second win 8.1):

Calibri 5.73 5.87 Calibri Bold 5.73 5.87 Calibri Italic 5.73 5.87 Calibri Light 2.10 2.12 Calibri Light Italic 2.10 2.12 Calibri Bold Italic 5.73 5.87 Consolas 5.22 5.34 Consolas Bold 5.22 5.34 Consolas Italic 5.22 5.34 Consolas Bold Italic 5.22 5.34 I could remove babel, `\hyphenation{Authenti-fizierungsfenster}` is enough to trigger the problem. I couldn't reproduce the problem in a current context standalone (not sure if it matters: but context couldn't find the consolas font, I had to use the name "consola" without s).

[phi-gamma]

···<date: 2015-03-01, Sunday>······

This are the fonts versions (first number windows 7, second win 8.1):

Calibri 5.73 5.87 Calibri Bold 5.73 5.87 Calibri Italic 5.73 5.87 Calibri Light 2.10 2.12 Calibri Light Italic 2.10 2.12 Calibri Bold Italic 5.73 5.87 Consolas 5.22 5.34 Consolas Bold 5.22 5.34 Consolas Italic 5.22 5.34 Consolas Bold Italic 5.22 5.34

That might explain the difference. On my system it’s

$ luaotfload-tool --list='format' | egrep -i '(calibri|consolas)'
ttf Consolas Italic 1.00
ttf Calibri Italic  1.02
ttf Calibri 1.02
ttf Consolas Bold   1.00
ttf Calibri Bold    1.02
ttf Calibri Bold Italic 1.02
ttf Consolas Bold Italic    1.00
ttf Consolas    1.00

Probably the buggy behavior is triggered by some feature that my oldish versions don’t implement. We’ll see.

I could remove babel, \hyphenation{Authenti-fizierungsfenster} is enough to trigger the problem.

Very good, this should simplify debugging a lot. I was already worried I’d have to dig into Babel code …

I couldn't reproduce the problem in a current context standalone

The default feature sets diverge a little so one always needs an extra step to “translate” an example.

       (not sure if it matters: but context couldn't find the

consolas font, I had to use the name "consola" without s).

That’s the file name, I think, to which Context then tries to append various extensions. Successfully, in your case. If the file can’t be found via name lookup then perhaps it never made it into the database? You can check like this:

$ mtxrun --script font --list --pattern=consolas
consolas   consolas   /home/phg/.fonts/TTF/Microsoft/consola.ttf

If it’s not there, then probably the $OSFONTDIR environment variable was missing or unset during database rebuild.

[phi-gamma]

···<date: 2015-03-01, Sunday>······

This are the fonts versions (first number windows 7, second win 8.1):

Calibri 5.73 5.87 Calibri Bold 5.73 5.87 Calibri Italic 5.73 5.87 Calibri Light 2.10 2.12 Calibri Light Italic 2.10 2.12 Calibri Bold Italic 5.73 5.87 Consolas 5.22 5.34 Consolas Bold 5.22 5.34 Consolas Italic 5.22 5.34 Consolas Bold Italic 5.22 5.34

Okay, I managed to reproduce the bug with the files you sent me, but it only occurs in the tl-2014 version of Luaotfload. The current git master doesn’t have the bug, which would also explain why you didn’t succeed in reproducing it with a current Context. I’ve uploaded a pre-release zipball to

https://www.phi-gamma.net/archives/luaotfload-tl15_pre-release.zip

for testing. The bug is independent of the Luatex version but I cannot tell exactly at what point in time it was fixed in the fontloader.

Closing as fixed.

I could remove babel, \hyphenation{Authenti-fizierungsfenster} is enough to trigger the problem. I couldn't reproduce the problem in a current context standalone (not sure if it matters: but context couldn't find the consolas font, I had to use the name "consola" without s).

---

Reply to this email directly or view it on GitHub: https://github.com/lualatex/luaotfload/issues/265#issuecomment-76601332

[u-fischer]

With texlive the prerelease seems to work, with miktex (which has an older luatex) I get an error:

! LuaTeX error ...oad-tl15/tex/luatex/luaotfload/fontloader-fontloader.lua:3877:
 attempt to index local 'direct' (a nil value)

but I haven't the time now to look at it more closely..

[phi-gamma]

···<date: 2015-03-08, Sunday>······

With texlive the prerelease seems to work, with miktex (which has an older luatex) I get an error:

! LuaTeX error ...oad-tl15/tex/luatex/luaotfload/fontloader-fontloader.lua:3877:
 attempt to index local 'direct' (a nil value)

but I haven't the time now to look at it more closely..

The Luatex binary is too old and doesn’t support direct node access (a.k.a. “nuts”). Can you please post the output of luatex --version? I’m unsure as to the frequency of engine updates of Miktex, so I’d prefer to not break it with the next update.

[u-fischer]

E:\test>luatex --version
This is LuaTeX, Version beta-0.76.0-2013062820  (MiKTeX 2.9) (rev 4627)

I can put a feature request on the miktex list to update luatex. (miktex updates things currently rather slowly, but the thread that luaotfload could break could speed up things ..). When would you like to release the next luaotfload?

[phi-gamma]

···<date: 2015-03-09, Monday>······

E:\test>luatex --version
This is LuaTeX, Version beta-0.76.0-2013062820  (MiKTeX 2.9) (rev 4627)

Yep, that would be too old.

I can put a feature request on the miktex list to update luatex. (miktex updates things currently rather slowly, but the thread that luaotfload could break could speed up things ..). When would you like to release the next luaotfload?

I’ll see if I’ll get something released for TL 2015, so it’s not pressing at the moment. It’s not my intention to break things and regarding the fontloader I thought there was even some compatibility fallback in place -- perhaps I messed that up during the import ;) Also, I’m not sure whether it would make sense for Miktex to undertake an update prior to the release of version 0.80. On the other hand I don’t think that that version is going to be much different from current SVN master.

Anyways, my best estimate is that a new version might be needed some time late during this year’s TL pretest phase.

[u-fischer]

Miktex has updated today to luatex 0.79.1. There is a small problem with oberdiek.luatex.lua (unrelated to luaotfload) but beside this the prerelease now works fine there too.

[phi-gamma]

···<date: 2015-03-22, Sunday>······

Miktex has updated today to luatex 0.79.1. There is a small problem with oberdiek.luatex.lua (unrelated to luaotfload) but beside this the prerelease now works fine there too.

Good to know, the switchable fontloader will come anyways since it’s a massive boon for testing ;) In any case they could have waited for the 0.8 final. I’m not sure the TL 2015 fontloader will be compatible with 0.79 considering today’s announcement:

http://www.ntg.nl/pipermail/ntg-context/2015/081459.html

I guess we’ll find out soon.

[u-fischer]

Well the update was done fast so I think it will be the same if 0.80 is needed. And two smaller steps are often better than one large. Keep me if you think something should be tested or done on miktex.

[huftis]

I observe something very similar with Cambria and Consolas with LuaLaTeX from TeX Live 2015. See http://tex.stackexchange.com/questions/255440/strange-rendering-bug-when-using-lualatex-polyglossia-cambria-consolas-font-an Could this be related?