[Xy-pic] Re: Misaligned arrow tips

Alexander Perlis alexanderperlis@yahoo.com
Fri, 16 Aug 2002 01:59:10 -0700 (PDT)

Hello Ross,
  Thanks for the quick response. I've investigated a little...

> > [...] To use XY-pic, I need to solve the following problem.
> > The problem concerns arrow tips, which are almost always
> > misaligned. For example, on our unmodified RedHat Linux
> > installation, if I open ../texmf/doc/generic/xypic/xyguide.ps
> > in GhostView [... magnifying each image shows misaligned tips].
> One version of the Xy-pic PostScript fonts had all the glyphs wrong
> by one position. This error was fixed for the Type-1 fonts
> available for free at Y&Y-TeX's website:  www.yandy.com.

At this moment, the file www.yandy.com/download/xy_fonts.zip appears
to be corrupted. Unfortunately it does not appear to be mirrored
anywhere, although the individual PFB files (which, perhaps, is all
that is in the ZIP) do exist on CTAN. I have reported the problem to

The xyguide.ps file on my system has the Type-1 fonts embedded, and
they contain comments indicating they are version 001.1004 of Sep97.
Yet the PFB files in my teTeX distribution (version 1.0.2, Dec01) do
*not* contain the fancier comments, there is no version number, and I
am guessing they are an older version. The current pretest beta
snapshot (May2002) of teTeX contains the same (presumably old)
versions. I will report this to the teTeX folks.

On CTAN there are *two* versions of xyguide.ps and they are
*different*. The two locations are:
Both are *distinct* from the version included in teTeX 1.0.2. A quick
comparison of differences indicates each was processed by a different
version of dvipsk, and major size differences are explained by the
presence/absence of embedded Type-1 fonts. Two of the three have
visibly misaligned arrow tips when viewed in ghostview.

As an experiment, consider the following code:

\hbox to 3cm{\hfil\NoPSspecials\UseRules\exercise\hfil}
\hbox to 3cm{\hfil\UsePSspecials{}\UseRules\exercise\hfil}
\hbox to 3cm{\hfil\NoPSspecials\NoRules\exercise\hfil}
\hbox to 3cm{\hfil\UsePSspecials{}\NoRules\exercise\hfil}

To process: "latex filename", then "dvips filename -o filename.ps".
I compared preview between xdvi 22.40f and ghostview 3.58
(ghostscript 6.53) at maximum magnification, and a 300dpi printout of
the dvips output. If any readers are at all interested in alignment
or in humoring me (grin!), please try this yourself and let me know
if your experience differs from my description below.

There are four copies of the same diagram. The top row uses rules,
the bottom row does not. The first column uses fonts, the second
column uses PostScript. In the chart below, ALLCAPS INDICATES

xdvi fullsize:
   rules/fonts     rules/ps
 NORULES/FONTS   norules/ps

ghostview 4x,8x,10x magn.:
   RULES/FONTS     rules/ps
 NORULES/FONTS   norules/ps

   RULES/FONTS     rules/ps
 NORULES/FONTS   norules/ps

In xdvi, it appears that the */fonts versions are dependent on their
location within the page. If you nudge the images (put "\," or
"\enskip" in the appropriate places in the source), then the nature
of the misalignment seen in xdvi changes (and both */fonts versions
are misaligned, contrary to the above report). This would almost
definitely be an xdvi bug, and I will report it to the xdvi folks.

Other than xdvi and dvips/gv, what preview software are Unix folks
out there using? Are lots of people getting misaligned output until
they know to switch to the PostScript driver?

> Is it the tips that are misaligned, or horizontal arrow stems?

Hard to tell, but I guess the tips, because also diagonal arrows and
curved arrows have visibly misaligned tips. On the other hand, as
indicated above, even with \NoRules and \NoPSspecials there is
remarkable misalignment. So either the PK fonts are messed up, or
xdvi has bugs, or xy-pic is miscalculating. (I don't know the
internals of xy-pic. If \UsePSspecials uses essentially the same
calculation code, then the blame is not with xy-pic.)

> This could be largely the dvips problem of not doing rules
> correctly. That is the question of whether the rectangular
> shape of a rule should sit wholly above the baseline, or be
> bisected by it.

Has this bug been reported to the dvips folks?

> If the \UseRules option has been used in the document, then
> although this saves on memory and processing, the dvips "bug"
> may come into play.

With \UsePSspecials, does xy-pic still respect \UseRules or \NoRules,
or does it always use PostScript? I ask because I can't tell any
differences in the second column in the above experiment, so either
xy-pic is always using PostScript, or the supposed dvips bug is
already fixed, or my example does not make the dvips bug visible.
Does someone have some sample code to illustrate the bug?

> The default driver uses font pieces which are required to be fitted
> together. So yes, there could well be rounding errors this way, and
> any (possibly platform-dependent) errors in the dvi to PS
> may have an effect on the result.
> There is another effect that may come into play if you have the
> Xy-pic PostScript fonts. This is the "hinting", which is to
> ensure that individual font characters
> are drawn as best as possible to match the raster grid.
> When several font pieces are placed next to each other, it is
> possible that the optimisation for each character individually
> need not be best for the group as a whole. Thus 1-pixel
> mis-matches could indeed result.
> In short, it is extremely difficult -- indeed impossible --
> to program Xy-pic to get it perfect in all situations.

Understood. And it appears that Xy-pic is doing everything correctly.
Yet, unless my setup is unique, most novice users just reading the
documentation, or trying the examples in the documentation (such as
the top-left version in my code above), will get misaligned output,
and they might blame Xy-pic and switch to a different package. My
evidence is anecdotal: I myself was turned away a couple years ago,
and came back only at the urging of a colleague. Even if xdvi and/or
dvips have bugs, I have been using them quite happily for many years,
so naturally my first response was to blame Xy-pic and go use
something else!

Now that I know the blame doesn't lie with Xy-pic, and/or can use
norules/ps to work around the misalignment, I am completely sold that
Xy-pic is the most versatile of all diagram packages. It leads the
competition by many orders of magnitude, and the notation is
consistent and remarkably easy after the initial hurdle. From now on,
I will certainly be an evangelist for this package to my colleagues.
My story now is: "For the truly complicated stuff, use MetaPost. For
everything else, use Xy-pic!" Do any readers of this list supplement
Xy-pic with anything other than MetaPost? (I haven't yet tried
producing PDF output in combination with Xy-pic. Perhaps I will have
to amend my story...)

But the Xy-pic documentation itself could go do a better job as far
as evangelism is concerned. What our discussion has shown is that
there are many points-of-failure affecting alignment. The
documentation could warn the user, as well as *assure* the user that
perfect output can be achieved. For example, at the start of both
xyguide and xyrefer there could be:

  Note: Xy-pic combines many elements (TeX rules, font characters,
and  PostScript \specials (with the ps driver)) to produce its
output, which is processed further by previewers and converters.
Subtle bugs  outside Xy-pic, or misconfigurations, can lead to
misaligned output. (For example, if the diagrams in this
documentation are misaligned, then you are definitely experiencing
such a problem.) Properly used/installed, XY-PIC PRODUCES PERFECTLY
ALIGNED OUTPUT. Be sure to experiment with using the \NuRules option
(see page xx) and/or the PostScript backend driver (see page xx).

Thanks to the authors for an excellent package, and thanks to the
list readers for humoring me in this discussion.


Do You Yahoo!?
HotJobs - Search Thousands of New Jobs