Are these known issues? With such greatly differing output between TeX engines, how is one expected to write portable TeX documents?
On 04.03.2015 15:26, Simon May wrote: > (Apologies for breaking the thread – I hadn't subscribed to the list > before.) > > I agree that it's not trivial to decide where the limits should actually > be, but I guess many things in typesetting are a matter of taste. > However, I think anyone would agree that > – Using the same TeX input, the output of Lua(La)TeX and Xe(La)TeX > should be (at least qualitatively) the same. If I decide that I want > or need to use a different engine for a document, I want to change > as little as possible (preferably nothing) in my document as a result. > If a change of engine produces significantly different output, that's > always a hint that there must be a bug somewhere. > – "\limits" should mean that the limits of the operator are placed above > and below instead of to the sides. Whether one thinks that the > placement with unicode-math looks good or not, the limits are so far > to the side that it cannot really be said that they are placed above > and below. > > Moreover, I really do think that the current placement with unicode-math > looks just bad. The limits are floating somewhere to the upper > right/upper left with barely any attachment to the operator they belong > to. Originally, I thought that the placement and spacing demonstrated at > https://tex.stackexchange.com/a/103925 > could universally agreed upon to be good-looking (and definitely better > than the same document typeset with LuaLaTeX). > > Now that I'm looking more closely at some tests, it seems that there is > way too much space inserted after an integral sign with LuaLaTeX. > Looking at the following TeX source: > > \documentclass{scrartcl} > \usepackage{unicode-math} > \begin{document} > \[ > A = \int f(x) \,\mathrm{d}x > \] > \end{document} > > It seems like the amount of space between the integral sign and f(x) is > almost doubled compared to the version without unicode-math. It actually > looks really ugly. Perhaps this issue is related? > > > Ulrike Fischer wrote: >> Am Tue, 3 Mar 2015 20:03:33 +0100 schrieb Simon May: >> >>> Hello, >>> >>> with unicode-math and LuaLaTeX, the placement of the limits using >>> \int\limits is incorrect. The limits are placed too far to the >>> right. As >>> discussed in the comments at >>> https://tex.stackexchange.com/a/103925/51235 >>> this issue does not occur with XeTeX. There is also a bug at >>> http://tracker.luatex.org/view.php?id=729 >>> that might refer to this same issue. Is this indeed a bug in LuaTeX >>> and >>> are there perhaps any workarounds? >>> I'm using LuaTeX beta-0.79.1 (TeX Live 2014/Debian) (rev 4971). >>> >>> Below is a demonstration of this issue. Producing the document will >>> show >>> the incorrect placement of the limits. Removing the line >>> "\usepackage{unicode-math}" will show the expected output. >>> >>> >>> \documentclass{scrartcl} >>> \usepackage{unicode-math} >>> \begin{document} >>> \[ >>> \int_a^b >>> \int\limits_a^b >>> \] >>> \end{document} >> >> The placement is certainly different than with xelatex or without >> unicode-math. But I do find it difficult to describe exactly where >> the symbol should placed and I often don't like the placement in >> pdflatex. It also depends a bit on the actual font. You can always >> move the subscripts a bit if you want: >> >> \documentclass{scrartcl} >> \usepackage{unicode-math} >> %\setmathfont{Cambria Math} >> \begin{document} >> \[ >> \int_a^b >> \int\limits_{\!\!\!\!a}^{b} >> \int\limits_{a}^{b} >> \int\limits_{a}^{b=5} >> \int\limits_{a=1}^{b} >> \int\limits_{a=1}^{b=5} >> \] >> \end{document} >> >> >>> Out of interest: Using unicode-math (even without limits) does not >>> produce the same output in the example as the same document without >>> unicode-math. The the size of the integral sign and the spacing of >>> the limits changes slightly. Is this intended/expected? >> >> You are using different fonts. So differences are always possible. >> >> >> -- >> Ulrike Fischer >> http://www.troubleshooting-tex.de/
0x6C294338.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
