metapost files in xetex and dvipdfm def files

[davidcarlisle]

xetex/dvipdfmf drivers should detect metapost files and use (version of) @mps processing to avoid need for the mvorigin driver option.

See thread starting at http://tug.org/pipermail/tex-live/2017-February/039726.html

I plan to do this later, just adding issue to track progress.

[josephwright]

I've just checked the linked problematic EPS using current epstopdf and it seems to 'just work'. Do we still have an issue here or should we simply say that epstopdf sorts it out properly nowadays?

[u-fischer]

@josephwright well if I use that with xelatex or latex+dvipdfmx it is currently still displaced, so we would have to force epstopdf here first wouldn't we?

[josephwright]

@u-fischer Ah, right: what it does do, therefore, is give me a test file for the .mps versus .eps business :)

[josephwright]

OK, so what we need to do is look for %%Creator: MetaPost, yes, rather than have an .eps/.mps split? I'll code something up for the l3backend to test this out and see how it looks, and we can then think about adding the same here.

[u-fischer]

Hm. I renamed the file, and also changed the creator to "Blub" in some cases and this are the results (with xelatex). I let you figure out what that means ;-)

\documentclass[a4paper,12pt]{article}
\usepackage{graphicx}

\begin{document}

\begin{tabular}{|c|}\hline
\includegraphics[scale=0.5]{pix-1.mps} \\ \hline %OK
\end{tabular}
\begin{tabular}{|c|}\hline
\includegraphics[scale=0.5]{pix-1-blub.mps} \\ \hline %blub creator: displaced right + up
\end{tabular}

\begin{tabular}{|c|}\hline
\includegraphics[scale=0.5]{pix-1.eps} \\ \hline %displaced left + down
\end{tabular}
\begin{tabular}{|c|}\hline
\includegraphics[scale=0.5]{pix-1-blub.eps} \\ \hline  %blub creator: OK
\end{tabular}

\end{document}

[josephwright]

@u-fischer From dvipdfm-x/pdfximage.c:

static int check_for_mp (FILE *image_file) 
{
  int try_count = 10;

  rewind (image_file);
  mfgets(work_buffer, WORK_BUFFER_SIZE, image_file);
  if (strncmp(work_buffer, "%!PS", 4))
    return 0;

  while (try_count > 0) {
    mfgets(work_buffer, WORK_BUFFER_SIZE, image_file);
    if (!strncmp(work_buffer, "%%Creator:", 10)) {
      if (strlen(work_buffer+10) >= 8 &&
          strstr(work_buffer+10, "MetaPost"))
        break;
    }
    try_count--;
  }

  return ((try_count > 0) ? 1 : 0);
}

[josephwright]

Then:

  case IMAGE_TYPE_MPS:
    if (dpx_conf.verbose_level > 0)
      MESG("[MPS]");
    id = mps_include_page(filename, fp);
    if (id < 0) {
      WARN("Try again with the distiller.");
      format = IMAGE_TYPE_EPS;
      rewind(fp);
    } else {
      /* Workaround for the problem reported.
       * mps_include_page() above doesn't set I->filename...
       */
      I = &ic->ximages[id];
      if (!I->filename) {
        I->filename = NEW(strlen(filename)+1, char);
        strcpy(I->filename, filename);
      }
      break;
    }

[josephwright]

So it looks like dvipdfmx is special-casing files created by MetaPost, and that is not actually desirable: if you drop at the binary end (by replacing MetaPost in the source here), we can handle as a standard .eps. One for the dvipdfmx maintainers?

[josephwright]

@u-fischer If I set up dvips for .mps inclusion (just treating as .eps), all is well - definitely a dvipdfmx issue.