cfpdf watermark issue

[Guest]

All,

I'm having a problem when adding a watermark to a pdf document.  Here is the sample code below:

<!--- Merge 2 documents together --->

<cfpdf

  action="merge"

  source="test.pdf, test2.pdf"

  destination="merged.pdf"

  overwrite="yes">

<!--- Add text watermark to the newly merged pdf --->

<cfpdf

  action="addwatermark"

  text="Hello"

  source="merged.pdf"

  overwrite="yes"

  foreground="yes"

  destination="watermark.pdf">

<!--- Output file to user and then delete --->

<cfcontent

  file="http://WEB-ADDRESS/watermark.pdf"

  type="application/pdf"

  deletefile="yes">

The files merge together properly and the text watermark is added successfully.  However, when I change the watermark to something like, "Hello1", save, then hit the back button in the browser and try to merge again, it still shows, "Hello", and not "Hello1".  If I close the browser down, and reopen, then "Hello1" properly shows. 

Seems like it's storing this in cache somehow.  As shown in the code above, I tried adding the 'deletefile="yes"' to the <cfcontent> tag, but it is not deleting the file after displaying to the user (I checked the folder location).  Also, I've tried adding, "<cfcache action="flush">" to the top of my page, but no success either. 

Can you guys think of any other way to delete this file, or some other solution?

Thanks for the help.

[Owainnorth]

Sounds like it's just your browser caching the PDF as the URL hasn't changed so it thinks it's the same document and tries to be clever. I'm not sure if there's any kind of meta tag you can pass in an octet stream, is creating a dynamic PDF name on the fly an option, or does it have to have the name it has? That's the easiest sure-fire way of getting a fresh download each time.

[Guest]

Hmm... Can you provide an example?  It doesn't have to have the same name, but would that continuously create a new document every time?  Meaning, in the current situation, if I check the folder, I will see watermark.pdf.  By using a dynamic PDF name, would this create an endless amount of new PDFs?  IE:  watermark1.pdf, watermark2.pdf, watermark3.pdf, etc...

[Owainnorth]

Yup, you'd need to have some way of monitoring or deleting old files, unless the onRequestEnd method is usable here.

[Guest]

That may be a problem.  In my real world situation, my users can choose between many pdfs to merge/watermark (via checkbox) in many different sections, so the files can get pretty large.  I'd hate to have to monitor that madness. 

It seems like it does not allow files to be deleted (either using cfcontent, or cffile to delete) in the same code - I suppose due to the file still being open by the user in their browser.   Perhaps onRequestEnd can be used to delete the file after displaying to the user. 

Any other suggestions?

[Leonard_B]

If you go with the dynamic naming scheme, you could use the code below as a scheduled task to simply delete all the files on a given interval, like daily, weekly, monthly, etc.

<cfdirectory directory="path/to/folder/containing/files/to/be/deleted/" action="list" name="docList">

<cfif #docList.recordcount# gt 0>

    <cfloop query="docList">

        <cffile action="delete" file="path/to/folder/containing/files/to/be/deleted/#name#">

    </cfloop>

<cfmail>- - - optional - - -</cfmail>

</cfif>

I use this for a client that desires to retain pdf copies of submissions for a 30 day period. Once the scheduled task is set, it triggers on the set interval and if there are files to be deleted does so and sends me an email letting me know it was done. If there are no files, nothing happens.

Just another thought to consider.

Leonard B

[Guest · Accepted solution]

Ok, I found out what was going wrong.  Apparently, there was a setting on the server that was not enabled, so that's why deletefile="yes" wasn't working.  Made a call to my server admin and he made the change and it worked. 

However, that only sort of solved the problem.  When I now tried to merge/apply watermark to my selected pdfs, it would immediately goto to a blank screen after choose to merge.  If I clicked back, and tried to merge again, it would display the pdfs.  Weird?  The merged file was definitely getting saved in a folder on the server, but it wasn't displaying it properly to the user. 

After some research, I ended up saving the merged docs to a variable, and then outputting the variable to the users screen; therefore, a document is not physically being saved on the server.  Here is my code:

<!---  MERGE THE SELECTED DOCUMENTS AND ASSIGN THESE DOCUMENTS TO VARIABLE 'MERGEDDOC'  --->

  <cfpdf

    action="merge"

    source="#listOfFilesWithPath#"

    name="mergedDoc"

    overwrite="yes">

  <!---  TAKE DOCUMENTS ASSIGNED TO VARIABLE 'MERGEDDOC' AND APPLY TAIL NUMBER WATERMARK TO EACH PAGE.  ASSIGN THESE DOCUMENTS TO VARIABLE 'MYPDF'  --->

  <cfpdf

    action="addwatermark"

    text="Hello World"

    source="mergedDoc"

    overwrite="yes"

    foreground="yes"

    showonprint="yes"

    opacity="1"

    rotation="40"

    name="myPDF">

<!---

IN ORDER TO DISPLAY NEWLY ALTERED CONTENT, 'CFCONTENT' IS USED.  THE FUNCTION 'TOBINARY' IS

REQUIRED (CONVERTS VARIABLE TO BINARY) BY THE 'CFCONTENT' TAG

--->

<cfcontent type="application/pdf" reset="yes" variable="#toBinary(myPDF)#">

This works perfectly.  I didn't try this method at first, because Adobe's documentation states the following:

"ColdFusion gives you the option to write a PDF file to a variable by using the

name attribute, which is useful if you want to perform multiple operations on a document before writing it to a file. However, this is practical for small files only because of memory requirements. If you are working with large PDF documents, write the PDF documents to files."

However, I found this to be the opposite.  I have successfully merged over 500 pages (numerous pdf documents) in under a min.  This is lightyears faster than my previous method using iText and saving the docs to a folder on the server. 

Hope this helps someone else out there who is trying to do the same thing.