View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000984 | luatex | luatex bug | public | 2016-09-08 10:42 | 2016-09-12 13:30 |
Reporter | juliangilbey | Assigned To | Hans Hagen | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | Mac | OS | OSX | OS Version | 10.11.6 |
Product Version | 0.87.0 | ||||
Fixed in Version | 0.99.0 | ||||
Summary | 0000984: Returning to integral limits placement | ||||
Description | Hi 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 | ||||
Tags | No tags attached. | ||||
|
|
|
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. |
|
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 |
|
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. |
|
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 |
|
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 |
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 |