Twitter: raymondcamden


Address: Lafayette, LA, USA

ColdFusion 8: Working with PDFs (Part 1)

07-09-2007 17,042 views ColdFusion 7 Comments

Ok, time for a little revelation. This may prevent me from ever working for Adobe, but I have to be honest.

PDFs are boring.

Ok, ok, I get it. They look nice. They are powerful. But... outside of that, when I hear folks talk about PDF as a technology, I have to stifle a yawn. Not because I don't like PDFs. I like them just fine. But to me they are about as exciting as, well, other file formats. As long as they work, I'm not too bothered to really care about the internals.

That's one reason why when I discovered all the new PDF stuff in ColdFusion 8 I didn't really pay much attention. But as I started to play around with the new tags, something odd occurred. I actually got excited about PDFs again! The amount of customization/modification/etc that you can do with PDFs in ColdFusion 8 is incredible. (See my article on URL Thumbnails for an example.)

So with that in mind, this week I'm going to take a look at some of the new PDF-related features in ColdFusion 8. Today I'm going to start with the simplest of features - checking to see if a file is a valid PDF.

For that feature ColdFusion 8 adds two simple functions: isPDFFile and isPDFObject. Let's start with the first one. As you can probably guess, isPDFFile tells you if a file is a PDF. Consider this example:

view plain print about
1<cfif isPDFFile("menu.cfm")>
2    menu.cfm is a PDF!<br/>
3</cfif>
4
5<cfif isPDFFile("book.pdf")>
6    book.pdf is a PDF!<br/>
7</cfif>

I have two checks here. The first checks a CFM file and the second checks a PDF. When run, you will only see: book.pdf is a PDF!. Like some of the other new ColdFusion 8 functions, you finally are allowed to use relative file paths. No more expandPath to convert a file in the same folder to a full path. (Thank you Adobe!) You can use a full path if you want, but you do not need to.

If you already have a variable and want to see if it contains a PDF, then you use isPDFObject. I'm not sure why they didn't use isPDF, but the function to use is isPDFObject. An example:

view plain print about
1<cfif isPDFObject(mypdf)>
2    mypdf is a PDF<br />
3</cfif>
4
5<cfif isPDFObject(request)>
6    the request scope is a pdf.<br />
7</cfif>

Tomorrow I'll be talking about the CFPDF tag, but for now, assume mypdf is a native PDF variable. Running this code you will only see "mypdf is a PDF".

Pretty simple stuff. As I said, my next entry will expand on this and start talking about the powerful CFPDF tag.

Related Blog Entries

7 Comments

  • Dav R #
    Commented on 07-10-2007 at 2:43 AM
    Hi Ray,

    What happens if we input a corrupted PDF file as an input to this isPDFFile() function?
  • Commented on 07-10-2007 at 8:10 AM
    Define "corrupted". I can say isPDFFile goes beyond just an extension check. I renamed book.pdf to book.doc and it still reported true for isPDFFile.
  • Dav R #
    Commented on 07-11-2007 at 1:47 AM
    Thanks Ray...

    In my case the pdf that I downloaded was terminated due to some technical faults.. Lets assume it's size now is 650 KB (which is supposed to be 1.3 MB)..


    Thanks Again for replying Ray!...

    Dav R
  • Commented on 07-11-2007 at 6:48 AM
    In that case I have no idea. :) If I had to guess, I'd say... maybe. Consider:

    Imagine file type X is defined as having a certain marker in the file at positions A, B, and C. If those positions were in the beginning of the file, then a half-downloaded file would still be valid.

    If file type Y required a marked at position A and B and B was at the end, then it would fail.

    Make sense? I'd just try it and see.
  • Dav R #
    Commented on 07-13-2007 at 1:17 AM
    Thanks Ray!
  • Commented on 07-23-2007 at 2:47 PM
    Great stuff as always, Ray. I'd like to add a couple of points of clarification for others reading this in the future, as I explored these options.

    First, the way you get a PDF into an object to test with isPDFObject is not with CFFILE (as some may suppose), but rather with CFPDF action="read". The function gives a result of false if what you point to is a variable created with CFFILE action="read" or even "readbinary").

    Along the same lines, I was intrigued by Ray's observation about not needing to use expandpath any more. I wondered if it extended beyond this CFPDF Source attribute, and I tried it in the very CFFILE read I tested. It did not work. As before, without expandpath it looks for the named file in the gettempdirectory().

    I don't make either of these comments to denigrate at all what Ray's written. It's awesome, as always, and I point people to these CF8 entries all the time. Just sharing some observations to help others avoid a couple mistakes I did as I tried things out. :-)
  • Commented on 07-23-2007 at 2:51 PM
    expand path: Yeah, I've made this observation a bit later in the series I think - that it is REAL nice that pdf/image stuff supports this - and more probably, but NOT cffile. Hopefully they will change that later on.

Post Reply

Please refrain from posting large blocks of code as a comment. Use Pastebin or Gists instead. Text wrapped in asterisks (*) will be bold and text wrapped in underscores (_) will be italicized.

Leave this field empty