[pdftex] BUG pdftex-1.40.11 TeXLive 2010 (win32)

Alexander Grahn A.Grahn at hzdr.de
Mon Apr 11 10:33:58 CEST 2011

On Fri, Apr 08, 2011 at 06:44:32PM +0200, Heiko Oberdiek wrote:
>On Fri, Apr 08, 2011 at 11:03:51PM +0900, Akira Kakuto wrote:
>> > > I encountered a bug in current pdftex-1.40.11 of TeXLive 2010
>> > > on the Win32 platform.
>> > 
>> > Confirmed. I don't yet understand why.
>> I've found that a pdf file cannot be read after
>> \pdfximage in getmd5sum(). Probably the file is locked for
>> some reason. In the case of \immediate\pdfximage, the file
>> can be read.
>> \pdfximage {foo.pdf}
>> \pdfrefximage\pdflastximage
>> \vfill\eject
>> \pdfmdfivesum file {foo.pdf}
>Test file for use with "pdfTeX -ini":
>  \edef\x{\pdfmdfivesum file{#1}}%
>  \msg{[\x] #1}%
>\pdfximage {ctanlion.png}
>\pdfximage {tiger.pdf}
>\csname @@end\endcsname\end
>That shows that the .png file is not affected.
>The latest md5sum is the checksum of an empty file:
>  D41D8CD98F00B204E9800998ECF8427E
>The file size (\pdffilesize) is correct in both cases.
>If I add
>  \immediate\write18{copy tiger.pdf t.pdf}
>  \test{t.pdf}
>Then I get the message from command "copy" (translated to English):
>| The process cannot access the file, because another process has locked
>| a part of the file.
>This does not happen for .png files.
>Yours sincerely
>  Heiko Oberdiek

Thanks, Heiko for testing and finding a possible source of the problem.

I ran MiKTeX pdftex-1.40.11 on my original test file; it produced
/correct/ md5 checksums.


More information about the pdftex mailing list