View Issue Details

IDProjectCategoryView StatusLast Update
0000984luatexluatex bugpublic2016-09-12 13:30
Reporterjuliangilbey Assigned ToHans Hagen  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformMacOSOSXOS Version10.11.6
Product Version0.87.0 
Fixed in Version0.99.0 
Summary0000984: Returning to integral limits placement
DescriptionHi Hans,

Following up on the report http://tracker.luatex.org/view.php?id=982 I've now tried the integral limit placement with both the standard CM fonts and XITS fonts, using both ConTeXt and LuaLaTeX; they seem poor in both, especially when compared with Xe(La)TeX's handling. So it seems that the algorithm in LuaTeX may be at fault rather than the font metrics. I also filed a bug against the XITS fonts, but got the response you can see here: https://github.com/khaledhosny/xits-math/issues/47

XeLaTeX code; uncomment the commented lines to get XITS font for the math, otherwise it's Computer Modern, and see how the limits are placed:

\documentclass[12pt,a4paper]{article}
\usepackage{unicode-math}
% \setmathfont
% [ Extension = .otf,
% BoldFont = *bold,
% ]{xits-math}

\begin{document}

\begin{equation}
  \int_0^1 x\,dx
\end{equation}

\end{document}

ConTeXt version:

% \setupbodyfont[xits]
\setupmathematics[integral=nolimits]
\starttext
\startformula
\int_0^1 x\,dx
\stopformula
\stoptext


Here is the ConTeXt run console output in case it is of use:

Julians-MacBook-Pro:~/CMEP/testprintables $ context contextintegral.tex

resolvers | trees | analyzing '/Users/jdg18/Library/texmf'
mtx-context | run 1: luatex --fmt="/Users/jdg18/Library/texlive/2016/texmf-var/luatex-cache/context/a86c089b384a3076dc514ba966a1fac9/formats/luatex/cont-en" --jobname="contextintegral" --lua="/Users/jdg18/Library/texlive/2016/texmf-var/luatex-cache/context/a86c089b384a3076dc514ba966a1fac9/formats/luatex/cont-en.lui" --no-parse-first-line --c:currentrun=1 --c:fulljobname="./contextintegral.tex" --c:input="./contextintegral.tex" --c:kindofrun=1 --c:maxnofruns=9 "cont-yes.mkiv"
This is LuaTeX, Version 0.95.0 (TeX Live 2016)
 system commands enabled.

resolvers > trees > analyzing '/Users/jdg18/Library/texmf'
open source > 1 > 1 > /usr/local/texlive/2016/texmf-dist/tex/context/base/mkiv/cont-yes.mkiv

ConTeXt ver: 2016.05.17 19:20 MKIV current fmt: 2016.9.8 int: english/english

system > 'cont-new.mkiv' loaded
open source > 2 > 2 > /usr/local/texlive/2016/texmf-dist/tex/context/base/mkiv/cont-new.mkiv
close source > 2 > 2 > /usr/local/texlive/2016/texmf-dist/tex/context/base/mkiv/cont-new.mkiv
system > files > jobname 'contextintegral', input './contextintegral', result 'contextintegral'
fonts > latin modern fonts are not preloaded
languages > language 'en' is active
open source > 2 > 3 > /Users/jdg18/CMEP/testprintables/contextintegral.tex
fonts > preloading latin modern fonts (second stage)
fonts > 'fallback modern-designsize rm 12pt' is loaded
backend > xmp > using file '/usr/local/texlive/2016/texmf-dist/tex/context/base/mkiv/lpdf-pdx.xml'
pages > flushing realpage 1, userpage 1
close source > 2 > 3 > /Users/jdg18/CMEP/testprintables/contextintegral.tex
close source > 1 > 3 > /usr/local/texlive/2016/texmf-dist/tex/context/base/mkiv/cont-yes.mkiv

mkiv lua stats > used config file: selfautoparent:/texmfcnf.lua;selfautoparent:/texmf-dist/web2c/texmfcnf.lua
mkiv lua stats > used cache path: readable: '/usr/local/texlive/2016/texmf-var/luatex-cache/context/a86c089b384a3076dc514ba966a1fac9' | readable+writable: '/Users/jdg18/Library/texlive/2016/texmf-var/luatex-cache/context/a86c089b384a3076dc514ba966a1fac9'
mkiv lua stats > resource resolver: loadtime 0.118 seconds, 1 scans with scantime 0.000 seconds, 0 shared scans, 9 found files, scanned paths: /Users/jdg18/Library/texmf
mkiv lua stats > stored bytecode data: 387 modules (0.330 sec), 82 tables (0.012 sec), 469 chunks (0.342 sec)
mkiv lua stats > traced context: maxstack: 1175, freed: 0, unreachable: 1175
mkiv lua stats > cleaned up reserved nodes: 47 nodes, 9 lists of 444
mkiv lua stats > node memory usage: 12 glue, 2 penalty, 34 attribute, 38 glue_spec, 10 attribute_list, 2 temp
mkiv lua stats > node list callback tasks: 6 unique task lists, 6 instances (re)created, 34 calls
mkiv lua stats > used backend: pdf (backend for directly generating pdf output)
mkiv lua stats > jobdata time: 0.001 seconds saving, 0.002 seconds loading
mkiv lua stats > callbacks: 152 direct, 248 indirect, 400 total
mkiv lua stats > randomizer: resumed with value 0.32362689418887
mkiv lua stats > loaded patterns: en::2, load time: 0.000
mkiv lua stats > result saved in file: contextintegral.pdf, compresslevel 3, objectcompresslevel 3
mkiv lua stats > loaded fonts: 2 files: latinmodern-math.otf, lmroman12-regular.otf
mkiv lua stats > font engine: otf 3.020, afm 1.512, tfm 1.000, 4 instances, load time 0.130 seconds
mkiv lua stats > used platform: osx-64, type: unix, binary subtree: bin
mkiv lua stats > luatex banner: this is luatex, version 0.95.0 (tex live 2016)
mkiv lua stats > control sequences: 43813 of 65536 + 100000
mkiv lua stats > lua properties: engine: lua, used memory: 73 MB (ctx: 72 MB), hash type: lua, hash chars: min(64,40), symbol mask: utf (τεχ)
mkiv lua stats > runtime: 0.581 seconds, 1 processed pages, 1 shipped pages, 1.721 pages/second

system | total runtime: 0.819 seconds


I've uploaded a PDF showing the various outputs for comparison.

Best wishes, and thanks for looking into this again.

Julian
TagsNo tags attached.

Activities

juliangilbey

2016-09-08 10:42

reporter  

integrals.pdf (24,887 bytes)

Hans Hagen

2016-09-08 20:06

manager   ~0001634

I didn't check the other engines but because fonts are different with respect to corrections (the italic correction can be 30% but as well 50% of the width) I decided to provide some control. That way one can do what one wants (as hard coding something in the engine will always fail for some fonts).

From th eupcoming manual:

There are two extra math parameters \type {\Umathnolimitsupfactor} and \type
{\Umathnolimitsubfactor} that were added to provide some control over how limits
are spaced (for example the position of super and subscripts after integral
operators). They relate to an extra parameter \type {\mathnolimitsmode}.

= 0 current behaviour (default) : ic / 2 | -ic/2
= 1 font parameter driven (0,750 seems to be acceptable in most cases)
= 2 0 | 0
= 3 0 | -ic / 2
= 4 0 | -ic

> 15 0 | - n * ic / 1000

so, a macro package has to set \mathnolimitsmode to what it likes or mess with the font parameters.

juliangilbey

2016-09-09 12:16

reporter   ~0001635

Hi Hans,

Thanks for this.

Meanwhile, I just reread Appendix G of the TeXbook, and I don't understand what you mean my ic/2 and -ic/2. From items 17 and 18 of that appendix, it seems that if an integral (or, indeed, any other nucleus) has both a superscript and subscript, then the horizontal spacing is as follows, where ic is the italic correction of the nucleus:

nucleus typeset with no italic correction
subscript typeset immediately next to it
superscript typeset shifted to the right by ic

So indeed the subscript and superscript are ic apart, but if the nucleus is typeset with its italic correction, then the super- and subscripts should be typeset at 0 | -ic, not at ic/2 | -ic/2.

But maybe I've misunderstood something here?

Best wishes, Julian

Hans Hagen

2016-09-09 16:19

manager   ~0001636

The texbook is not the reference for opentype math. Also, the 8 bit traditional tex code path is different as there the italics corrections are always added and removed if needed in the process while in the opentype code path they are explicitly added when intended (so, in opentype math italic correction is somewhat different, mostly text related, because there is this advanced kerning).

Now, cambria has no kerns there (contrary to what was intended) so it does depend somehow on italic correction too (it would be interesting to know what should happen if there were stepwise kerns as well as italic correction) but anyway we need to what msword does as the cambria / msword rendering is the reference for opentype math and (being the reference) cambria has to come out right.

Also, the ic is used for positioning on top / below integrals so it serves a dual purpose i.e. is a compromis (the top/bottom placement is probably what determines the correction, so if ic is used for positioning after the integral it might need tweaking for some fonts which is why that is (now) configurable).

I'll discuss it with some folks at the upcoming ctx meeting. It's just a mess.

juliangilbey

2016-09-09 16:29

reporter   ~0001637

Oh, gosh, it really does sound like a mess :-(

Thank you for looking into it and all your work on it. I am really curious, then, about what XeTeX does, because there things come out looking very different. But maybe it goes wrong with Cambria. (But I don't have the time to dig into it, and you probably don't either.)

Best wishes,

Julian

Hans Hagen

2016-09-12 13:30

manager   ~0001640

i'll default to max subscript correction (i adapted context to use another method so let's be easy on other usage) ... we need to keep an eye on future fonts that have advanced kerns as there might be more modes needed to deal with italic/kern interference

Issue History

Date Modified Username Field Change
2016-09-08 10:42 juliangilbey New Issue
2016-09-08 10:42 juliangilbey File Added: integrals.pdf
2016-09-08 20:06 Hans Hagen Note Added: 0001634
2016-09-09 12:16 juliangilbey Note Added: 0001635
2016-09-09 16:19 Hans Hagen Note Added: 0001636
2016-09-09 16:29 juliangilbey Note Added: 0001637
2016-09-12 13:30 Hans Hagen Note Added: 0001640
2016-09-12 13:30 Hans Hagen Status new => closed
2016-09-12 13:30 Hans Hagen Assigned To => Hans Hagen
2016-09-12 13:30 Hans Hagen Resolution open => fixed
2016-09-12 13:30 Hans Hagen Fixed in Version => 0.99.0