Bug: Printing creates too many .tmp files

[Defenestration]

I've just noticed that when I printed a 780 page PDF from the Viewer to the PDF-XChange 4 Pro printer driver, in booklet form, it created thousand's of small (ie. 98KB-100KB) .tmp files in the Windows temp folder. It got to Page 393 and then "hung". The cause of this problem is that there are 65553 files in the Windows Temp folder, and NTFS only allows just over 65,000 files in each folder.

Because of this I am unable to print this large PDF.

Any chance of a fix for this soon ?

[Defenestration]

I actually think this is a PDF-XChange printer driver bug, as you don't get thousands of .tmp files when printing to a different device.

[Bhikkhu Pesala]

See this earlier thread.

[Ivan - Tracker Software]

This is not a bug in the PDF-XChange Driver.

The PDF-XChange driver stores printed images within .tmp files during the optimisation process. It is necessary to generate as small PDF's as is possible -- PDF-XChange checks images for duplicates and inserts only one instance of an image even if it was used more times. And to do this it is needed to have all images.

They are stored on the disk to prevent huge memory usage.

You may find that using Acrobat Reader to print to the PDF-XChange driver may in this instance suit your needs better - but - printing a PDF to generate anothor PDF is 'NEVER' ideal, you need to think of this as taking a photocopy of a photocopy and content could be compromised!

[Defenestration]

Surely it's a bug though when it can't print a large PDF due to overloading the underlying file system with too many temporary files.

Instead of storing each image (or whatever else) as individual files, why not store them all in one large file, keeping the file offset and length for each image, instead of having thousands of files ?

This would still allow the optimisation to take place, but would not overload the file system by creating too many files in a folder.

The reason I'm printing a PDF to generate a PDF is so I can print a PDF in booklet format. This is why I requested the ability for the Viewer to print in nUP and booklet format.

[Defenestration]

The other downside of using lots of small .tmp files instead of a single large one, is that cancelling a print job can take a long time due to it having to delete all the temp files before removing the progress dialog.

With a single large file this would be instantaneous.

[John - Tracker Supp]

It only happens when you use the PDF-XChange Print driver as already explained.

This is required and is one of the major components of the optimisation method used and why we achieve aruguabley the smallest PDF files of any general pupose PDF conversion driver in most situations.

There is therefore no intention or reason to change it.

[Defenestration]

I understand the need to use temporary storage on disk as part of the optimisation process, but you could achieve exactly the same optimisation by using one single large file, which contains the contents of each of the smaller files. Instead of accessing the individual small files to read/optimise the contents of images (or any other data), you would simply access the single large file at a specific file offset.

For example, instead of having 10 temp files of size 100KB, you would have 1 file of size 1MB (ie. 10 x 100KB). When you want to access the fourth files data, you would simply seek 300KB into the large file and read 100KB of data.

Instead of keeping a list of temporary files, you would just keep the offset into the large file coupled with data length for each image. Obviously I don't have access to the source code, but the change I have suggested would surely not take that much work.

By using thousands of small files, you have removed the problem of excessive RAM usage, only to introduce the problem of limiting the size of PDF's that can be printed to the driver. The solution I have suggested will mean that theoretically any size PDF could be printed without problem.

Please re-consider.

[John - Tracker Supp]

With respect and not to be pedantic - but as stated the solution for now at least - lies not in the PDF-XChange Driver, at all - as stated previously this is one extreme example of when the print output method employed by the Viewer combined with printing to the driver has caused a problem.

I assume you are doing thsi to make a smaller PDF.

We are currently altering the way the viewer works which may pay dividends in this area (creating for the Viewer its file system inside one file) - this is necessary for supporting Undo/Redo functionality - when we have fine tuned this - will will look using a similar implementation for the driver.

But - the one major issue here may be speed - so it is not a foregone conclusion that this will be suitable for use with the driver and the excessive number of events that must be processed.

In the meatime - I would suggest you look at outputting from Acrobat Reader to the driver - if you must print a PDF to PDF-XChange, as this should reduce the number of tmp files generated due to the different output method employed by Acrobat Reader when printing.

[Defenestration]

I am doing this for a couple of reasons:

1) To convert the PDF into a booklet style PDF
2) To take advatage of the page scaling feature

I would not call this an extreme example.

I'm curious as to why you don't think my suggested solution to the problem would not work or are reluctant to implement this change, when you state that your possible solution may not be fast enough ?

My suggested solution would be just as fast as the current solution, since seeking within a file and then writing data is just as fast as opening a file and writing to it. It would also require minimal changes the code, since instead of doing the following:

1) Create new temp file
2) Write data
3) Close file

you would simply do

1) Seek to EOF (ie. next free location)
2) Write data

The only real difference is that you would replace the creation of a new temp file with a file seek to EOF. When you wish to access the data, you just replace the file open with a file seek.

If you need to modify the data later, with the possibility of it getting larger, you can use two files - One for un-manipulated data, the other for manipulated data.

As I cannot wait, I will use Adobe Reader as you suggest, but I purchased PDF-XChange 4 Pro to be the complete solution for all things PDF, so it's a bit annoying to find out that I then have to install another product for certain tasks (particularly when the suggested fix for PDF-XChange is simple)

[John - Tracker Supp]

I appreciate the fix looks simple to you - but it is not as simple as you suggest.

We will implement the outlined change as soon as we have developed for the viewer - tested and satisfied ourselves that it is viable for the drver and then include and implement.

This issue was raised less than 48 hours ago - we have responded and outlined a possible solution and committed to resolving as soon as possible.

Where else do you think you would get the level of support and timley response (let alone better) than you have received on this issue from us and the numerous others you have raised ?

[Defenestration]

OK, Thanks.

[John - Tracker Supp]

Pleasure.