Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I am having this problem when using Asana Math with XeLaTeX + unicode-math, if you see the pdf found in the download link AsanaProb.zip you can see that \bigcap produces much bigger character than it should: alt text

Is it a syntax problem or maybe something else? The document compiled on a linux machine with texlive 2010 if that helps...

share|improve this question

3 Answers 3

I expect this is just the way the operators are designed to look. (Can someone verify this?)

If you don't like it, you could define an alternative smaller bigcap like so:

\newcommand{\altbigcap}{\scalebox{0.8}{\bigcap}}

(0.8 might not be appropriate, I can't check since I don't think I have the relevant font, I don't think...)

An alternative solution would be to recycle the answers to this question to suit your purpose: replace the bigcap symbol with one from a different font.

share|improve this answer
2  
Asana has two large operator sizes (plus the texstyle size), but looks like the engine will always pick the largest. –  Khaled Hosny Nov 19 '10 at 22:08
1  
\scalebox takes its contents out of math mode. You'd get closer with something like: \newcommand{\altbigcap}{\mathop{\scalebox{0.8}{\ensuremath{\bigcap}}}} but the problem is that it won't be centered horizontally if the super/subscript are longer than it. –  frabjous Nov 20 '10 at 3:10

(Repeated from my answer at the PhilTeX forums.)

I'm actually getting a reverse problem when trying \bigcap with unicode-math and Asana Math: the result looks too small. I can't quite figure it out at the moment. We seem to be using the same version of the package. Out of curiousity, are you using a 32 or 64 bit version of Linux? I know there seems to be some bad mojo between 64 bit linux and unicode-math (which may explain why I'm having trouble).

I think this largely a matter of taste. I don't think that cap looks so big that it couldn't be intended to be that big. What I find jarring, however, is that it is bigger than the bounded product sign, which looks bad just because it is inconsistent.

Along kind of similar lines to Seamus's suggestion, my own suggestion would be to try loading the relsize package

\usepackage{relsize}

and redefine \bigcap like this in the preamble:

   \let\oldbigcap\bigcap
   \renewcommand{\bigcap}{\mathop{\mathsmaller{\oldbigcap}}}

But the problem I'm having with the package right now prevents me from testing that code.

You can iterate \mathsmaller commands to make it smaller and smaller.

share|improve this answer
    
Side remark: One can install 32bit TeX Live on 64bit Linux without problems (indeed that is what I am using until XeTeX is fixed). Just select 32bit (i386) at the install prompt and set the PATH to .../texlive/2010/bin/i386-linux/ –  Caramdir Nov 20 '10 at 4:01
    
This workaround doesn't work, it produces a much too small symbol. (Also the redefinition must be done after \begin{document} as otherwise unicode-math will just overwrite it again.) –  Caramdir Nov 20 '10 at 4:11
    
Are you sure you're not having the same problem as me? Do you get a huge one like Miltos if you leave you the \mathsmaller part? (Thanks for the tip about 32 bit TL, though I doubt I'll bother. I don't use XeTeX much.) –  frabjous Nov 20 '10 at 6:01
    
This is what I get with Asana, XeTeX and unicode-math: imgur.com/vXGHp –  Caramdir Nov 20 '10 at 21:14
    
Thanks for the answers, does anyone have a problem with asana or stix xits fonts when using the \substack command? –  user2017 Nov 22 '10 at 10:44

Update: the new version is already on CTAN.


It's a bug with Asana Math. I've contacted Apostolos Syropoulos, the author, and he'll probably release a new version soon.

The issue (which I uncovered thanks to Khaled Hosny) is twofold. First, unlike other TeX Fonts, but like Cambria Math, Asana has multiple versions of its big math operators. Usually there's only one, which is the \displaystyle version of the operator. This can be seen by opening the font in fontforge and looking at its MATH table, in the section vertical variants.

The second part is that the font constant DisplayOperatorMinHeight was set too high, to 1850. As the name indicates, this constant indicates the minimum height a glyph needs to be considered the display version of a math operator. But the "correct" display version of the \bigcap operator has a height of only 1559, thus not qualifying for display. The engine then looked for the next version, which has heigh 2588, and selected it. This is the huge glyph you're seeing.

The first part is important because if there weren't other variations, the engine would just settle for the "small" display operator.

If you can't wait for the bugfix release of Asana and are using luatex, the font can be patched on-the-fly with this code (copied from here):

\usepackage{unicode-math}
\usepackage{luacode}
\begin{luacode*}
  local function patch_asana(fontdata)
    local mc = fontdata.MathConstants
    if mc then
      mc.DisplayOperatorMinHeight = 1337
    end
  end
  luatexbase.add_to_callback("luaotfload.patch_font", patch_asana, "patch_asana")
\end{luacode*}
\setmathfont{Asana Math}

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.