Hi,

I have been having some difficulty with large delimiters.  I need to
typeset a symbol consisting of an array of numbers between \left| and
\right\rangle.  I need \rangle larger than is supplied by amsmath and
so tried using the yhmath package.  This produces a correctly sized
\rangle, but causes strange behavior in all other large symbols.

An example:

\documentclass{amsart}
\usepackage{yhmath}
\begin{document}

\begin{equation*}\left|\begin{gathered} a_{1n}\quad  a_{2n}
      \dots\dots a_{nn}\\a_{1 n-1} \dots a_{n-1 n-1}\\\dots\dots\\ a_
{11}
  \end{gathered}\right\rangle
\end{equation*}

\end{document}

When the dvi file is viewed using kdvi (under Ubuntu 7.10), the left
vertical line looks like a vertical red box while it is completely
absent in the ps file (viewed with kghostview).  The pdf file looks
fine in acroread, but the proportions of the vertical line and \rangle
are badly off when viewed with kpdf.

Does anyone have any suggestions for getting a large \rangle without
this kind of problem?  For example, is it possible to use \rangle (and
\langle) from yhmath while retaining the usual amsmath symbols for all
other large symbols?

Thanks,
Dan

On Thu, 19 Feb 2009 15:55:14 -0800 (PST), Dan <dsss...@gmail.com>
wrote:

It appears to be a bug, but I think it is in dvips.
One can work around it: find yhmath.map (which has
only two lines:
  yhcmex10 Yhcmex <yhcmex.pfb
  yrcmex10 Yhcmex <yhcmex.pfb
)
Remove the first line and run updmap or updmap-sys.
This seems to make things work.

The original yhcmex10 (and the mf version still) contained
copies of those characters of cmex10 that didn't need larger
versions. The type1 version (yhcmex.pfb) doesn't contain
those characters. Now yhcmex10 is a virtual font that
selects characters from cmex10 and a new font named
yrcmex10. That font is nothing more than a .tfm file
and a map line that points to yhcmex.pfb.

So dvips is supposed to
 1) see a call for yhcmex10,
 2) find the virtual font yhcmex10.vf and see that
    it calls for cmex10 and yrcmex10.

Instead, it seems to find yhcmex10 in the map file and
use it directly, bypassing the virtual font stage. Then
it trys to find characters in yhcmex.pfb that don't exist
and really should be taken from cmex10.pfb.  

Removing yhcmex10 from the map file forces dvips to seek
a way to create it and the first thing it tries is what
it should have tried first to begin with: the virtual font.

[There is another (minor) problem and it is with the yhmath
packaging: Since yhcmex10 points to cmex10 + yrcmex10,
dvi viewers that correctly follow the vf and need to make
pk files will try to make yrcmex10.pk and find there is no
.mf source file for it. It will therefore end up calling
ps2pk instead of metafont. Since yhcmex10 was originally
written for metafont, i don't think this is the highest
quality way to proceed. In my system, I have copied
yhcmex10.mf to yrcmex10.mf.]

I don't know what causes some of these problems. On my system
only the PS is wrong (and PDF's made from it).  

Dan
To reply by email, change LookInSig to luecking