docx to pdf - cleaning up temp images

[Timothy]

Dear,

I'm currently working on a project implementing DOCX4J. Until now everything is working fine.
Altough I have a little question. While converting a docx file with embedded images to a pdf file (using the pdf conversion example) serveral temporary files are created. Some of the files are the images that need to be displayed in the new pdf.
When the conversion has ended, the tmp image files still exists in my Temp directory.

Is this normal? Is it possible to clean them up? (for our project we work with tmp files and we do a clean up afterwards)

Timothy

[jason]

Hi Timothy

See http://www.docx4java.org/trac/docx4j/changeset/1631 and http://www.docx4java.org/trac/docx4j/changeset/1637 which overhauled how images are handled in the conversion process.

You can implement your own ConversionImageHandler

cheers .. Jason

[Timothy]

Jason,

Thx for the quick reply. The answer you have provided is based on the nightly build that is available via svn. For our development we try to work with a stable release (in this case 2.7.0). Do you have any idea when there will be a next release containing these changes?

Timothy

[jason]

Hi Timothy

I'm actually planning to post a 2.7.1 release candidate this week, with a view to publishing the release next week or the week after.

A goal for the 2.7.1 release is to publish it to maven central (new for docx4j). Steps are under way to get the last of the dependencies into maven central first; hopefully that will be completed this week. The time line above assumes this won't hold us up.

cheers .. Jason

[Timothy]

Jason,

I just viewed the source code and there is only a 2.7.0 release candidate in the tag folder. Can you give an indication when the following RC (2.7.1) will be ready, including the above patches?

Timothy

[jason]

rc2 of todays date in http://www.docx4java.org/docx4j/ is what will become 2.7.1, in the absence of any show stoppers. The release is planned for Friday.

It'd be great if you could try it in the next 36 hours and confirm it meets your requirements.

cheers .. Jason

[Timothy]

Jason,

I just tested the new rc and was suprised by the new way of working. First of all, if a docx file that contains images, needs to be converted, the images will be written to a temp file with a possibility to use a random UUID in the filename (thread save -> 2.7.0 wasn't...).

After I ran my test I saw the temp images were still in the temp directory, in other words, the docx4j code doesn't clean up the images after the conversion. Can I implement this feature myself? Where can I possibly catch the filenames of the temp images that were created during the process?

Thx in advance!

Timothy

[jason]

When you invoke Conversion.ouput, pass it a PdfSettings object in which you've setImageHandler to an object implementing FileConversionImageHandler which contains your cleanup code.

I guess it would be convenient if the FileConversionImageHandler interface had a cleanup method which you could call at the end of the process to delete images (or was called automatically?), but it doesn't right now.

(AbstractConversionImageHandler does keep a map of images, which could possibly form the basis of your cleanup, though it contains external images as well; alternatively, you could delete everything starting with the UUID)

By the way, you can setImageIncludeUUID(false) if you wish (suitable only in a non multithreaded environment).

cheers .. Jason

[Timothy]

Jason,

Everything is working. I clean up my temp images myself, based on the imagesHandled Map, in a self written LocalPdfConversionImageHandler.
Will you keep me informed if the release would be postponed?

Thx again!

Timothy