[tex-live] dvipdfm(1) regression with TL 2009
j+tex-live at 2009.salmi.ch
Thu Aug 6 02:27:41 CEST 2009
Jonathan Kew --> tex-live (2009-08-05 23:24:47 +0100):
> It looks like on Jukka's system, the function dpx_create_temp_file (in
> dpxfile.c) is not working correctly, and is recycling filenames once
> the letter in the last position reaches "z". I don't have time to
> study it tonight, though. I guess the first thing to check - besides
> carefully reading the code - would be which of the #ifdef chunks is
> actually used in that build.
the system in question (NetBSD/i386 5.0_STABLE) is !MIKTEX and !WIN32,
and has HAVE_MKSTEMP and HAVE_GETENV.
And indeed, appending another 'X' to the template string for mkstemp(3)
in src/dpxfile.c:dpx_create_temp_file() does fix the problem I'm seeing.
But probably only until I include more than 26^2 .eps files...
But I'm not convinced that dpx_create_temp_file() or mkstemp(3) is the
culprit. I built some versions of dvipdfmx released between those used
in TL 2008 and TL 2009 respectively: while dvipdfmx-20090506 and later
show the problem I described, dvipdfmx-20090502 and earlier don't. And
there the temporary file names are also recycled after 26 of them.
More precisely, it's the following change (taken from the dvipdfmx
ChangeLog) which seems to cause the regression:
2009-05-03 Matthias Franz
* dvipdfmx.c, epdf.c, epdf.h, pdfdoc.c, pdfdoc.h, pdfobj.c, pdfobj.h, pdfximage.c, pdfximage.h, xbb.c:
Improved PDF version handling. A "Version" entry in the
document catalog is now honored. Moreover, dvipdfmx accepts
to write PDF 1.7, and extractbb doesn't complain about PDF
versions any more. Encryption keys too long for PDF 1.3 now
lead to an error instead of a silent change of PDF version.
(The change to dvipdfmx.c doesn't hurt, but the other changes do; but
I'm too unfamiliar with the code to spot the source of the problem...)
Any hints? Or should this discussion be moved to the dvipdfmx mailing
This email fills a much-needed gap in the archives.
More information about the tex-live