I am writing a PDF dynamically, and am creating a QR code on the document for eTicketing purposes
i set my cfdocument localurl=yes to include a different image, which works fine, but since I am using an API call to get the binary for the qrCode, the using cfimage to display the image, it is only showing a red X
<cfdocument format="PDF" overwrite="Yes" localUrl="yes" pageType = "letter">
<body>
<cfoutput>
<section id="header">
<img src="file:///#ExpandPath('images/header.png')#"/>
<cfimage action="writeToBrowser" source="#rc.qrCode#" />
</cfoutput>
</body>
</html>
</cfdocument>
the source variable rc.qrCode is a binary response that works perfectly until i place inside cfdocument, it generates a url like this http://mysite/CFFileServlet/_cf_image/_cfimg-7945382145198648283.PNG as image source
i am sure this has todo with localurl and file:///, i just an not knowledgable enough to know why
Do not need to use physical path rather use relative path to your page.
e.g.
If you code in index.cfm of root folder and image inside images folder
try <img src="images/header.png"> , Note that it should not start with root path rather relative to your file.
UPDATE
writetoBrowser internally write file to hard drive to it's temporary location (topically, C:\ColdFusion10\cfusion\tmpCache\CFFileServlet) and while rendering it to browser it use relative path like "/CFFileServlet/_cf_image/_cfimg1592404668342998556.PNG", you can say that ColdFusion internally map CFFileServlet directory with all coldfusion site but notice leading forward slash and this makes issue with localurl=true. Since localurl=true either need physical path or relative path to your document.
Good idea is instead of writetobrowser you can write same image to harddrive at your location and give physical path in img tag. I do not this there will any performance issue since ColdFusion internally doing same thing when you are using writetobrowser attribute :)
Related
This will show me the image in a browser:
<cfset myImage=ImageNew("d:\UploadedDocuments\thumbnails\1487862_page_1.jpg")>
<cfimage source="#myImage#" action="writeToBrowser">
But if I use the same code inside of a .pdf file, it generates a small red x. Is this not possible to do?
If the image is already on the drive you don't need CFIMAGE here. You can embed it like so:
<img src="file:///d:\mysite\images\myimage.jpg" width="50" height="60">
You could also use an HTTP Path to it as well - store it at a location accessible by your web server through real or virtual directories use the <img> tag like you normally would.
This post on cfdocument and SSL and this suplimental post on using the file system with cfdocument should help you sort it out.
I'm using a <cfhtmltopdf> tag to pull in a .cfm file as a template and create a PDF. All works well when I use jpg for the image format. But if the image is a BMP - for some reason it won't work.
In the template file , I'm using a <cfdirectory> tag with no filter to pull in the images.
<cfdirectory directory="E:\xxx\images\#image_ID#\" name="myDir" type="file" sort="datelastmodified">
then I'm using a <cfloop> to display images from the directory...
<cfloop query="myDir">
<cfif right(myDirMain.name,4) is ".bmp" >
<img src="#request.root#images/#images_ID#/#myDir.name#" border="0" width="230px" style="margin-bottom:15px;" />
</cfif>
This works great for jpg, but when trying to use bmp images - it's no good.
Does anyone know if a reason why bmp images are an issue or does only work with jpg images?
There seems to be a bug in the system that stops PDF's using BMP images. A solution is to convert them using <cfimage> tag before creating the PDF - its workaround that works, even thou it uses a little bit more server resources.
It seems that when I use the <cfsavecontent> tag, the output of that is being served by the server (without the variable being outputted), which, to me, kind of defeats the purpose of <cfsavecontent>.
If this is important: my application uses ColdSpring, ModelGlue and Transfer ORM.
Here's my example code in a function:
<cfsavecontent variable="testvar">
<cfinclude template="test.cfm" />
</cfsavecontent>
<cfreturn testvar>
And the template:
<cfdocument format="PDF" pagetype="A4" orientation="portrait" unit="cm">
<cfoutput>
<!--- PDF content here --->
</cfoutput>
</cfdocument>
The PDF content is being parsed by my browser (Google Chrome), while the view hasn't even been loaded in. How can I best prevent this from happening?
Just to clarify: I am not outputting the #testvar# variable yet in this code, though it seems it loads the template in the browser anyways.
To achieve what you're trying to do, should you not simply be using the name attribute of <cfdocument> to put the PDF data into a variable, instead of trying to <cfsavecontent> it?
Disclosure: I've never used <cfdocument> for anything other than proof-of-concept code and testing, but that's what I'm inferring from the docs.
As I also needed to make multiple PDF documents merge, I ended up doing the following. Many thanks to Adam Cameron for providing the solution to my initial issue.
In the template file, I use the <cfdocument> tag with the name attribute to save the PDF in a variable (thanks to Adam Cameron for this)
Then, I store all the PDF documents in an array in their binary format
In my view, I merge the PDF documents together by using <cfpdf>'s merge action, and using a cfloop, to loop over the array, inside it.
Finally, I display the content by using <cfcontent> and using the variable attribute with toBinary(myPdf)
This got me to where I am.
cfinclude will process the test.cfm page, and the way you configured cfdocument will cause "opening" of pdf document in your browser.
You can prevent openning of this file by saving file on the disc:
<cfdocument format="PDF" pagetype="A4" orientation="portrait" unit="cm" filename ="test.pdf" overwrite ="yes">
But this will not prevent execution of cfinclude in the cfcontent tag, it will just prevent opening in the browser.
You can observe cfinclude as request to the server, it will always be executed.
The solution would be to invoke request on test.cfm file which contains cfdocument in the moment that you actually want to generate pdf.
Example: Use javascript on client to invoke report service which will generate and pop out the screen with pdf report.
Hope this helps.
Here's an odd one, for me at least. I'm reading an image into a cf image variable and saving it as a session variable:
<cfimage action="read" source="myPath/image.jpg" name="myImage" />
<cfset session.image = #myImage# />
I plan to be manipulating that image at some point, which is why I'm saving it to a variable. Anyway, then I stream it with cfcontent:
<img id="photoPlaceholder" src="/#application.root_name#/administration/PhotoManagement/displayPhoto.cfm" width="500px" />
from template displayPhoto.cfm:
<cfcontent variable="#imageGetBlob(session.image)#" />
Here's the problem. After the first call, the first retrieved image is displayed no matter which new image is passed to it. I've tried destroying the session variable before the cfimage tag, and I've verified that I'm passing the correct image variable each time. The only way a new image is shown is if I refresh the page.
It seems to me that cfimage is somehow caching the image, and each new call to it doesn't refresh the variable myImage. CF documentation says nothing about this, and google brought up nothing.
Thoughts?
Your problem is probably client-side. Since the URL in your img tag doesn't change (...displayPhoto.cfm), your browser doesn't see that you are in fact pointing to a new image, so it keeps serving up the image already in cache.
You might try adding a randomized fake parameter to the end of your src attribute, something like this pseudo code:
<img id="photoPlaceholder" src="/#application.root_name#/administration/PhotoManagement/displayPhoto.cfm?somevar=#aUniqueValue#" width="500px" />
You could create the aUniqueValue variable from a random number generator or timestamp generator.
You could also set the HTTP headers up in displayPhoto.cfm to tell the browser not to cache the content form that URL. In theory, this may be better, as otherwise the browser will keep in cache the image from each time it is given a slightly different URL. that's probably not a real-world concern on a desktop where the cache is large and not segmented by site, but a mobile client with limited cache may purge other content which you'd like cached.
If the image is large or the same version is likely to get loaded a lot, look at the HTTP headers, otherwise the approach above is fine (we use both in the app I work on)
How can images be loaded into a dynamically generated pdf (cfdocument)? In that the pdf is not stored the hdd. The pdf needs to be emailed, and the ram cleared. The images are stored outside of the wwwroot folder.
If it is need be, the pdf can get stored in the hdd, get attached, emailed, then deleted, but would opt for it not to get stored in the hdd.
c:\coldFusion9\imgs\ is the dir
Sample:
<cfdocument format="PDF" localurl="true">
<cfoutput> #vars#</cfoutput>
</cfdocument>
I have used
<img src="">
inside cfdocument, and it works if the image is in the wwwroot (http...) folder, but not when the image is outsite the wwwroot ("c:\coldFusion9\imgs#image#.png" or "../imgs/#image#.png").
I suppose that cfcontent is ideal
So, inside cfdocument, I do this:
<cffile action="readbinary" file="c:\coldFusion9\imgs\#image#.png" variable="img">
<cfcontent type="image/jpg" variable="#img#" >
The result is that the image loads, on the screen, not the pdf.
Would like to email the pdf as an email attachement. The pdf does not need to render on screen, but for testing purposes, we could let it render on the screen to know if the image was loaded or not, by either naming or not naming the cfdocument. The pdf renders when the name is removed, it does not render when the name is present.
Appreciate your help.
If i understand your question correctly. You want to
1. Grab an image from a folder outside of your webroot
2. Place image in a cfdocument
3. Attach cfdocument to a cfmail
if that's is the case you need cfimage instead of img and the rest you can find on Ben Nadel's site http://www.bennadel.com/blog/1700-Ask-Ben-Creating-A-PDF-And-Attaching-It-To-An-Email-Using-ColdFusion.htm
or expand on the snippet below.
<cfdocument format="pdf" name="mydoc">
<cfimage action="writeTobrowser" source="c:\temp\test.png" >
</cfdocument>
<cfmail
from="x#y.com"
to="y#x.com"
subject="this is it">
<cfmailparam
file="mydoc.pdf"
type="application/pdf"
content="#mydoc#"/>
</cfmail>
A couple notes to clarify:
cfdocument uses an HTTP connection to grab images, which is why you can't grab any outside the webroot. In my experience, relative paths are problematic, so it's best to use absolute paths. If you want to use images from outside the webroot, you'll need to provide them directly, as in your example or as #KobbyPemson did.
The reason that you don't see the PDF when you add a name is that the name attribute does not name the PDF. It is the name of the variable in which the PDF is stored. So, when you provide it, you are telling CF to stuff the PDF in a variable using the name you supply.