[DVIPDFMx] regression with dvipdfmx-20090506 and later

[Jukka Salmi]

Hello,

I [1]reported this problem to the TeX Live mailing list some days ago,
but a more appropriate place to discuss it is probably here.

First of all, this seems to be a regression.  With dvipdfmx-20090502 and
earlier everything works fine, but with dvipdfmx-20090506 and later the
resulting .pdf looks wrong if I include more than 26 .eps files: files
1 up to 26 are show correctly, but then file 1 is shown instead of file
27, file 2 instead of file 28, etc.

I've put an example [2]online (the .eps files used are in eps.tgz).  To
reproduce the problem I run latex(1) on the .tex file (this gives me the
expected results), and then dvipdfmx(1) on the resulting .dvi file.  The
contents of the resulting .pdf file vary depending on the dvipdfmx
version used:

  dvipdfmx-20090502 and earlier: [3].pdf is fine
  dvipdfmx-20090506 and later:   [4].pdf is bad (as described above)

The source of the problem seems to be the following commit (taken from
the ChangeLog file):

  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.

At least the problem starts showing up when I add these changes to
dvipdfmx-20090502, and it goes away after I revert them.  (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...)

I'm seeing the [5]same problem with the latest release (20090708) as well.
While running dvipdfmx with -vv I noticed that temporary file names are
recycled as soon as all 26 lowercase latin letters have been used:

$ dvipdfmx.20090708 -vv dvipdfm-test 2>&1 | grep Converting
pdf_image>> Converting file "./eps/g01.eps" --> "/tmp/dvipdfmx.13178a" via:
pdf_image>> Converting file "./eps/g02.eps" --> "/tmp/dvipdfmx.13178b" via:
pdf_image>> Converting file "./eps/g03.eps" --> "/tmp/dvipdfmx.13178c" via:
[...]
pdf_image>> Converting file "./eps/g24.eps" --> "/tmp/dvipdfmx.13178x" via:
pdf_image>> Converting file "./eps/g25.eps" --> "/tmp/dvipdfmx.13178y" via:
pdf_image>> Converting file "./eps/g26.eps" --> "/tmp/dvipdfmx.13178z" via:
pdf_image>> Converting file "./eps/g27.eps" --> "/tmp/dvipdfmx.13178a" via:
pdf_image>> Converting file "./eps/g28.eps" --> "/tmp/dvipdfmx.13178b" via:
pdf_image>> Converting file "./eps/g29.eps" --> "/tmp/dvipdfmx.13178c" via:
pdf_image>> Converting file "./eps/g30.eps" --> "/tmp/dvipdfmx.13178d" via:
pdf_image>> Converting file "./eps/g31.eps" --> "/tmp/dvipdfmx.13178e" via:
pdf_image>> Converting file "./eps/g32.eps" --> "/tmp/dvipdfmx.13178f" via:

And indeed, appending another 'X' to the template string for mkstemp(3) in
src/dpxfile.c:dpx_create_temp_file() does [6]fix the problem I'm seeing
(resulting in temporary file names like /tmp/dvipdfmx.13178ab to be
generated).  But probably only until I include more than 26^2 .eps
files...

BTW, this is on a NetBSD/i386 5.0 system with a TeX Live 2009 pretesting
release.


Any hints?  Help is much appreciated.

Regards, Jukka

[1] http://tug.org/pipermail/tex-live/2009-August/021890.html
[2] http://salmi.ch/~jukka/TL/dvipdfmx/
[3] http://salmi.ch/~jukka/TL/dvipdfmx/dvipdfm-test_20090502.pdf
[4] http://salmi.ch/~jukka/TL/dvipdfmx/dvipdfm-test_20090506.pdf
[5] http://salmi.ch/~jukka/TL/dvipdfmx/dvipdfm-test_20090708.pdf
[6] http://salmi.ch/~jukka/TL/dvipdfmx/dvipdfm-test_20090708X.pdf

-- 
This email fills a much-needed gap in your mailbox.