4

The following code gives correct results with PDFLaTex but if I run XeLaTeX (which I need to do for the full document), part of the gluon line is cut off.

\documentclass{article}
\usepackage{feynmp-auto}

\begin{document}
  \begin{fmffile}{fgraph_qxq_z_gz_s}
    \setlength{\unitlength}{0.5cm}
    \begin{fmfgraph*}(8,5)
    \fmfleft{i0,i1}
    \fmfright{o0,o1}
      \fmf{fermion   , label=$\overline{q}$}{w0,i0}
      \fmf{fermion   , label=$q         $}{i1,w0}
      \fmf{boson     , label=$Z^0       $}{w0,w1}
      \fmf{gluon     , label=$g         $}{w1,o0}
      \fmf{boson     , label=$Z^0       $}{w1,o1}
    \end{fmfgraph*}
  \end{fmffile}
\end{document}

How do I avoid this?

Edit: Changed \documentclass{minimal} to \documentclass{article} and added images below of the difference in output (from user Dr. Manuel Kuehner):

pdflatex

enter image description here

xelatex

enter image description here

4

This is probably only the beginning of an answer, because I'm not quite sure which is the best way to fix this problem.

The problem is that the bottom of the gluon falls outside the bounding box of the graphic generated by Metapost and xetex is ultra zealous about this and crops the figure to the bounding box; pdftex is more relaxed and includes everything, even the bit of the gluon that should be cropped. So it's hard to say that xetex is at fault -- if anything I'd say pdftex should be "corrected".

But how does the gluon get drawn outside the bounding box?

Normally Metapost will calculate and set the bounding box automatically to include all the elements of a drawing. But the language also provides a setbounds command that lets you arbitrarily set the bounding box at any point during a drawing. One use of this is to create a margin of white space around your drawing, for example.

The \end{fmfgraph*} line in your source code, causes the drawing to be finalized and all the relevant commands written to the Metapost file, followed finally by the Metapost macro endchar;. In fact the completed MP file looks like this:

% fgraph_qxq_z_gz_s.mp -- do not edit, generated automatically by glue.tex
input feynmp
require_RCS_revision "1.30";
beginchar(1, 8*14.22636pt#, 5*14.22636pt#, 0);
"feynmf: 1";
LaTeX_unitlength:=14.22636pt;
subgraph (0, 0, w, h);
vinit;
pickup pencircle scaled thin;
vleft (__i0, __i1);
vright (__o0, __o1);
vconnect ("fermion , label=$\overline {q}$", __w0, __i0);
vconnect ("fermion , label=$q $", __i1, __w0);
vconnect ("boson , label=$Z^0 $", __w0, __w1);
vconnect ("gluon , label=$g $", __w1, __o0);
vconnect ("boson , label=$Z^0 $", __w1, __o1);
vfreeze;
vdraw;
endsubgraph;
endchar;
% the end.
end.
endinput;

Notice that at the top you are including feynmp.mp and that the last macro called, before the primitive command end, is endchar;. If you look in feynmp.mp on your system, you will see that endchar is defined as follows:

vardef endchar =
  setbounds currentpicture to (0,0)--(w,0)--(w,h)--(0,h)--cycle;
  if LaTeX_file <> "":
    write EOF to LaTeX_file;
    LaTeX_file := "";
  fi
  endfig
enddef;

In a fit of tidiness the author of the package decided to crop the picture so that it fits in a box defined by the w and h parameters (which are of course set to the width and height that you defined with \begin{fmfgraph*}(8,5)). This setbounds command does not actually change any of the drawing commands, it just causes MP to write the specified bounding box into the PostScript that it produces. So when xetex "correctly" obeys the bounding box dimensions, the gluon gets chopped, but when pdftex "usefully" ignores the bounding box, the gluon's foot is still drawn.

The obvious solution (in my humble opinion) is to remove the whole line:

setbounds currentpicture to (0,0)--(w,0)--(w,h)--(0,h)--cycle;

If you edit your local copy, then you will find that xetex processes your file correctly, like so:

enter image description here

except that as you will immediately see, for some reason the labels are now all offset to the right!

Looking a bit more closely at what's going on, it appears that the label drawing macros make assumptions about the size of the figure, and this is why the setbounds command is needed.

My hack solution is to fix beginchar as well, so that it draws an invisible box before we start. My copy of feynmp.mp now looks like this:

...
vardef beginchar (expr c, wd, ht, dp) =
  LaTeX_file := "";
  beginfig(c);
    w:=wd;
    h:=ht;
    % new line added here to draw an "invisible" box
    undraw (0,0)--(w,0)--(w,h)--(0,h)--cycle;
enddef;
string LaTeX_file;
vardef endchar =
  % next line removed
  % setbounds currentpicture to (0,0)--(w,0)--(w,h)--(0,h)--cycle;
  if LaTeX_file <> "":
    write EOF to LaTeX_file;
    LaTeX_file := "";
  fi
  endfig
enddef;
...

and your picture comes out of xetex like this:

enter image description here

(The grey line visible at the bottom of this picture shows you where the bottom of the "invisible" box is. This is an artefact produced by ImageMagick when I convert the pdf to a png. I don't see that artefact in the PDF version).

The reason I'm hesitant about this solution is that it feels all wrong to tell you to patch your copy of feynmp.mp, as you will have to re-do any changes when you upgrade. But it might be the simplest way to fix things in the short term.

On my macos system with MacTeX 2016 the file is at

/usr/local/texlive/2016/texmf-dist/metapost/feynmf/feynmp.mp

but it may be somewhere else on your system. There are various mechanisms to patch LaTeX packages, but I don't know how to apply them to Metapost source files. You might also consider making a local texmf tree with a "fixed" copy of feynmp.mp. You might also consider raising a bug with the package author.

  • Thanks for this solution. It is not perfect (the labels a still a bit displaced) but (unfortunately) the only working solution still. – fuenfundachtzig Jun 21 '18 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.