Cfpdf action = thumbnail not working on Lucee 5

Hi,

This was working fine on 4.5 but since I upgraded to 5.0.1.33-SNAPSHOT it
does not save the thumbnail. No error is generated, it is as if the code
is just not run. Please help, this creates our invoices and course
certificates.

<cfpdf 
        source="#cfdocument_report#" 
        pages="1" 
        action="thumbnail" 
        destination="#GetTempDirectory()#"
        imagePrefix="report_#URL.idobject#_#URL.idreport#" 
        format="png" 
        overwrite="true"
        transparent = "true"
        resolution="high"        
        scale="100">

Regards,
Chris

I have tested this and cfpdf action thumbnail does not create thumbnails.

<cfpdf action="thumbnail" source="test.pdf" pages="1" imagePrefix="Cover" 
format="png" scale="50" resolution="low">

Have you checked anything In the logs? In catalina.out?

Mark Drew

  • Sent by typing with my thumbs.

Hi,

I have the same problem. Failing in Lucee 5.1.0.34 but working in Lucee 4.5.

I didn’t find any error or log.

Thanks.

similarly, the upgrade from 4.5 to 5.1 has caused cfdocument with format of
“PDF” to fail to render png logos in our reports with the error
“Insufficient data for an image.” On PDFs where this happens, font
styles/faces then tend to get messed up as well.

I had a similar issue a few days back, came out to be that PDF thumbnails
were created from a directory listing, which meant that CF would try to get
a thumbnail out of every file in that directory. Since you mentioned
no error, not sure if thats your case, but try making sure there is no
other file in the directory the PDF files for which the thumbnails will be
created are. Sometimes MAC os, creates hidden property files for each
folder, try listing the directory and dumping the result just to make sure.

Good Luck.

What’s the status here?
I have the same problem on Lucee 5.1.1.65
nothing spotted in catalina.{dd}.log

1 Like

Bump!

Upgraded to 5.1.4.19 today to see if the blocking issue of pdf action=“protect” had been fixed (LDEV-1038). It has. Unfortunately, pdf action=“thumbnail” still does not work.

You can try this alternative. It does not have all of the features, but does work for generating a JPG thumbnail.

1 Like

Wow. This is great. I started going down this path the other day. Thanks!

@Michael_Sprague1 Your excellent function above doesn’t work on the latest PDFBox version. Here is a new version I threw together which

  • works on PDF coming in as binary as well as a file path
  • matches the CFPDF thumbnail behavior of calling the files _page_1.jpg
  • Supports the imagePrefix attribute as well

	/** Creates a jpg thumbnail from a PDF file
    *
    * @pdfFile  This is the physical file path to the PDF or a byte array (binary) representing a loaded PDF 
    * @destination Location to save the thumbbail, defaults to same location as original.
    * @width width of the resulting image, defaults to 200px
    * @page page number to use for the thumbnail, defaults to page 1.
    * @imagePrefix A string to prefix to the image name
    *
    * @returns The file name of the JPG that it creates.
    */
	function thumbnailFromPDF( required pdfFile, string destination='', string width='200', string page=1, string imagePrefix='') {
		
        // get the base paths file names needed
        if( isBinary( pdffile ) ) {
            var basefile = 'thumbnail';
            var loadSource = pdffile;
        } else {

            if (right(arguments.pdfFile,4) Neq ".pdf") {
                cfthrow(message="File does not appear to be a PDF file.");
            }
            if (arguments.destination IS '') {
                arguments.destination = getDirectoryFromPath( arguments.pdfFile );
            }
            var basefile = listlast(arguments.pdffile,server.separator.file);
            var loadSource = createObject( 'java', 'java.io.File' ).init( pdffile );
        }

		// load the pdf into PDFBox
        var document = createObject("java","org.apache.pdfbox.Loader").loadPDF( loadSource );	
        try {
            var ImageWriter = createObject("java","org.apache.pdfbox.rendering.PDFRenderer").init( document );
            var basefilename = replacenocase(basefile,".pdf","","ALL");
            if (right(arguments.destination,1) Neq server.separator.file) {
                arguments.destination = arguments.destination & server.separator.file;
            }
            var returnfileprefix = "#arguments.destination##imagePrefix##basefilename#_page_"; //includes dest path
            var returnfilename = "#imagePrefix##basefilename#_page_#arguments.page#.jpg";

            //write the image of page 1. This writes a file called 1.jpg. There is prefix argument and in this case we use the file name as the prefix.
            // arguments... writeImage(document,image type,start page, end page, prefix to <page number>.jpg, java color profile, resolution)
            var BufferedImage = imageWriter.renderImage(arguments.page-1);
        } finally {
            // close document object, no longer needed
            document.close();
        }

		// resize the image
		cfimage(action="resize",source=BufferedImage,destination="#arguments.destination##returnfilename#",overwrite="true",width=arguments.width);

		return returnfilename;
	}
1 Like

@bdw429s This is great, thank you for updating it.

Brad can you help us reproduce the problem you cited here?

https://luceeserver.atlassian.net/browse/LDEV-967

Hi @bdw429s

Isn’t it better to use scope arguments?

from:

if( isBinary( pdffile ) ) {

to:

if( isBinary( arguments.pdffile ) ) {

I see that in many Ortus software the scope is not used.

Thanks :smile:

Not really :slight_smile: The arg is required so I don’t have to worry about it being null. There is no local scope arg of the same name, and the arguments scope is next in line for the scope lookup order so it will be both fast and always find the right variable. I often times go for readability if I know there can’t be any issues.

3 Likes