The issue has been fixed in babel-french
. If you still entounter it, please update your TeX distribution. The following answer should no longer be applied, because the fix will do more harm than good if combined with the fixed babel-french
code.
Old answer
As Ulrike Fischer wrote, the problem is the french punctuation code. It is inserted in the "kerning" callback which replaces traditional TeX kerning code, but doesn't apply any kerning.
So even in your first example containing only french, the is a small difference between the LuaLaTeX and the pdfLaTeX version: In the LuaLaTeX version, the kerning in "marche" is missing.
Normally this isn't important in LuaTeX because in LuaLaTeX you normally use OpenType fonts which use another mechanism for kerning, but it becomes significant when you use legacy fonts.
This can be fixed by changing the callback to add a kerning pass:
\documentclass[12pt]{article}
\usepackage[utf8]{luainputenc}
\usepackage[LGR,T1]{fontenc}\input{lgrenc.dfu}
\usepackage{lmodern}
\usepackage[greek.ancient,main=french]{babel}
\directlua{
luatexbase.add_to_callback("kerning", node.kerning, "TeX legacy kerning")
}
\title{Ça marche?} %\date{} \author{me}
\begin{document}
\showoutput
\maketitle
un, deux, trois
\end{document}
This not only fixes kerning for legacy fonts but also fixes your problems with DVI files and greek text:
\documentclass[12pt]{article}
\usepackage[utf8]{luainputenc}
\usepackage[LGR,T1]{fontenc}\input{lgrenc.dfu}
\usepackage{lmodern}
\usepackage[greek.ancient,main=french]{babel}
\directlua{
luatexbase.add_to_callback("kerning", node.kerning, "TeX legacy kerning")
}
\title{Ça marche?} %\date{} \author{me}
\begin{document}
\showoutput
\maketitle
un, deux, trois
\foreignlanguage{greek}{ἀγαγεῖν}
\end{document}
works fine.
You might wonder why?
The problem with greek text is related to a special character in greek text: The small sigma. It looks differently when it comes as the final character of a word. This is implemented in TeX as a special kind of ligature: The greek font asks TeX to insert a right_boundary
"pseudo-character" at the end of every word. Then the font can use kerning and ligature rules for this special right_boundary
character to behave differently at the end of the word. After kerning is done, these pseudo-characters are deleted again.
But deleting these characters is also disabled when the kerning callback is overwritten. So in your example containing french and greek text, at the end of every greek word a right_boundary
character survives and gets written into the output file. This leads to weird effects because LuaTeX models this character as a glyph node with index -2
and the output formats don't like negative glyph indices. In PDF, this gets written as a 8 Bit unsigned character and therefore translated to index 2^8-2=254
. You don't see this in your example, beause the font subset does not contain character index 254
, but if you insert a gree \char 254
anywhere in your document, you will see this character appended to every word in PDF output:
\documentclass[12pt]{article}
\usepackage[utf8]{luainputenc}
\usepackage[LGR,T1]{fontenc}\input{lgrenc.dfu}
\usepackage{lmodern}
\usepackage[greek.ancient,main=french]{babel}
% \directlua{
% luatexbase.add_to_callback("kerning", node.kerning, "TeX legacy kerning")
% }
\title{Ça marche?} %\date{} \author{me}
\begin{document}
\showoutput
\maketitle
un, deux, trois
\foreignlanguage{greek}{\char 254 ἀγαγεῖν ἀγαγεῖν ἀγαγεῖν ἀγαγεῖν ἀγαγεῖν}
\end{document}

The DVI file format is insanely flexible and does actually specify how to insert glyphs with negative index. So let's look again at the dvips
message:
dvips: ! DVI file contains unexpected command (131)
Command 131 is only needed for glyphs of negative index or indices higher than 16777215. Given that dvips only supports 8 bit fonts with glyph indices between 0 and 255, this command is indeed unexpected. For dvipdfmx the problem is similar, it does only support glyph indices up to 16777215, but the message is bit misleading because it tries to just ignore the command byte 131 and tries to read the font index as (invalid) command.
xdvipdfmx
). As for why I use the 8-bit encodings and luainputenc, this is necessary for DVI drivers (using legacy font formats). You cannot use OpenType+usual unicode encoding with DVI output.dvips: Font [lmroman12-regular]:+tlig; not found; using cmr10
and dvipdfmx saysdvipdfmx:fatal: Unable to find TFM file "[lmroman12-regular]:+tlig;".
.