9

Consider the rendering of \middle| in the code below:

\documentclass[12pt,a4paper]{article}
\usepackage{unicode-math}
\setmathfont{xits-math.otf}
\begin{document}
\[ \left\lbrace p_{i,j} \, \middle| \, 1 \le i \le k_j, 0 \le j \le N \right\rbrace \]
\[ N \left[ f \right] = \left\lbrace x \in N \, \middle| \, f \cdot x = 0 \right\rbrace \]
\end{document}

XeTeX produces the following output:

XeTeX

On the other hand, LuaTeX produces this:

LuaTeX

It's not hard to see that XeTeX renders only the first line correctly while LuaTeX renders only the second line correctly. A similar problem happens if I swap Asana Math for XITS, so it seems to be an engine problem rather than a font problem. The problem disappears if I change from unicode-math to mathspec, so it appears to be specific to unicode-math.

Clearly, there is an execution path which makes \middle work correctly (in the sense of being consistent with \left and \right: how do I force \middle to be rendered that way when using unicode-math?

3
  • Another issue: The f in N[f] touches the right bracket when LuaTeX is used.
    – Marco
    Apr 19, 2012 at 0:57
  • For me, Asana-Math and Latin Modern Math produce consistent results on both lines with lualatex (although I am not too keen on the font itself). the *brace | and [ ] are all tall enough to fit the line. I suspect it might be a version problem and an unresolved bug in XITS
    – ArTourter
    Apr 19, 2012 at 2:05
  • @Marco: See github.com/khaledhosny/luaotfload/issues/36
    – Caramdir
    Apr 19, 2012 at 3:15

1 Answer 1

9

I think this is a mix of minor engine differences and font issues. It is not really a difference between \left/\right and \middle but rather difference between brace and bar glyphs.

The braces in most fonts have several ascending sizes that the engine can choose from, and if no big enough brace is available it composites it from smaller building blocks, on the other hand bar in most fonts is available only in one size and if the engine wants a bigger glyph it composites it from smaller blocks, and because compositing is bit more flexible it results in more intermediate sizes than the braces, resulting in effects like this.

If you try \middle\lbrace you will see that the sizes are consistent, and if you test with a font like Lucida Bright OT Math that has glyphs for bar in the same sizes as the braces, you will see the results are consistent.

lucida test

(At some point I'll do this for XITS, hopefully before TL 2012)

The differences between the two engines might be due to minor differences in calculating the required glyph sizes.

5
  • Ah, interesting. Is there a way to force unicode-math to always use composited delimiters? That should solve the problem, I think...
    – Zhen Lin
    Apr 19, 2012 at 7:14
  • Now, it is out of unicode-math's control, and even if possible the result would be ugly and even much larger than it should. Apr 19, 2012 at 7:41
  • @Khaled: Another point might be to reconsider the parameter settings of \delimiterfactor. A long time ago, I wrote an unpublished paper about it. [tug.org/twg/mfg/papers/ulrik/mfg-size.pdf] May 1, 2012 at 19:31
  • @Ulrik: Thanks for the link, I have read the paper already (and all your other papers, while researching for STIX LaTeX support), but there is no way to set it from the fonts and setting it in unicode-math might not be a good idea as it might be font dependant, but I've to think about it a bit more. May 1, 2012 at 20:06
  • I'm pleased to say that this problem seems to be gone in TeX Live 2012 for both XeTeX and LuaTeX. Thanks!
    – Zhen Lin
    Jul 10, 2012 at 8:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .