Open davidcarlisle opened 7 years ago
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?
@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?
@u-fischer Ah, right: what it does do, therefore, is give me a test file for the .mps
versus .eps
business :)
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.
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}
@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);
}
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;
}
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?
@u-fischer If I set up dvips
for .mps
inclusion (just treating as .eps
), all is well - definitely a dvipdfmx
issue.
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.