I have some blank printed forms that are rendered ...
# cfml-general
d
I have some blank printed forms that are rendered as pdfs using cfdocument. They include checkboxes, which are png images. The actual image file, when I look at it in an editor or in cfdocument html mode, is an empty checkbox, blank and white. The pdf version shows it checked with a red X, as in the attached pic. We do have a checked version, but it's black and white too. Does anyone have any idea why this renders like this?
e
That looks like the default styling of older PDFs.
c
Isn't that the "missing image" symbol (rather than a checkbox)?
2
a
yeah - that's the "broken image" placeholder
Are you getting it over https or anything like that?
d
It's a relative URL (../../etc), which I'm starting to think is the issue. I didn't build this, I'm here making other more substantive changes, just ran into this. Weird that nobody has complained.
You're right about that being the missing img placeholder. Shows the same if I mangle the img name. But so far I haven't found any form of image path that works. Tried these: • ../../ etc • same with http or https • sitename/path/to/file • same with http or https What are img references in cfdocument supposed to look like? We did a big firedrill several years ago after a cf update broke stylesheet and img references in cfdocument, converted everything to localurl=true, using relative paths, but that doesn't seem to be working here. ADDENDUM: That seems to have been about stylesheet URLs, not images.
j
Are you trying to use cfpdf or cfdocument? CF version? CF2023 has cfhtmltopdf that works really good
d
It's cfdocument, cfdocumentsection, cfdocumentitem, CF2021. I'm not inclined to rework it with different tech unless I have to. I did get it to work. Not sure if this is final, but I used the full https url of the images on the production site. Same URL on my dev site doesn't work, I think because the cert here isn't valid for this URL. For normal cf pages, roughly once a session I get "Your connection is not private", and have to say I want to continue to this "unsafe" site. Apparently cfdocument doesn't honor that.
d
I remember this being a solved problem decades ago but don't remember the solve, lol
Maybe it's using
file:///
paths for the images as long as you're not serving them as html as well? 🤔
localUrl=true
in cfdocument?
leaving the protocol off so it works in both http and https?
//path
d
Yes
localUrl=true
. Leaving off the protocol causes the page to never finish rendering. In fact it seems to bork something deeper. If I cancel that request, put the https back, and go again, it still doesn't complete, eventually throwing a 500 error after an unnaturally long time. This machine doesn't have FusionReactor on it, so I don't have any more detail on that crash. Once that request times out, the page renders normally with https img urls. Odd, but not worth chasing further.
j
@Joshua Kasap we had a lot of troubles with something similar, albeit in cfhtmltopdf, but maybe our findings could help @Dave Merrill?
j
I had to do something like this for images to work. _<img src="https://#CGI.SERVER_NAME#/pathToFile/filename.png" width="500" height="600"><br>_ http/https was the only thing that seemed to work.
d
That doesn't work for me in my dev environments, works in prod. As of now, I'm pointing the dev sites to the production images, and that works fine too. I'm pretty certain it's because dev doesn't have a real cert, just one I have to bless every so often for normal cf pages, but apparently the blessing doesn't carry over here.
j
One of these might of also worked in cfdocument but i don't remember for sure <cfimage action="writeTobrowser" source="W:/path/file.png" width="500"> or <cfset fileObject = fileReadBinary('W:/path/file.png') /> <cfset imageObject = imageNew(fileObject) /> <cfimage action="writeTobrowser" source="#imageObject#">
c
How about adding the cert to your dev cf install/jvm?
d
@cfsimplicity There is a cert, but it's a wildcard cert for the parent company, blessable manually, but not workable here. A real wildcard cert covering this set of dev domains would cost $1200/year, kind of a lot for a non-profit.
c
I meant importing the cert to your jvm store so that the java http client uses it when fetching the image within cfdocument? Or maybe I'm misunderstanding...
Think I'm getting mixed up. You want to use an https dev URL that doesn't have a valid cert, right? In one of my apps it looks like I'm doing the same as you: pulling the image from the prod site with the valid cert.
👍 1
But I would expect that using http with the dev url would work, and I think you said it didn't. The following seems to work for me on ACF2023.
Copy code
<cfdocument format="PDF" name="pdfbinary">
<cfoutput>
<!DOCTYPE html>
<html lang="en">
<head><title>testing</title></head>
<body>
<img src="<http://localhost/test.jpg>">
</body>
</cfoutput>
</cfdocument>
<cfheader name="Content-Disposition" value="attachment; filename=#Chr( 34 )#test.pdf#Chr( 34 )#">
<cfcontent type="application/pdf" variable=#pdfBinary#>
Also seems to work with a hostname bound to the local website, instead of
localhost
Setting
localurl="true"
and
<img src="test.jpg">
where the image file is in the same directory as the calling script also works for me.
🎯 1
d
Yes, I was a little unclear, and shotgunning ideas. For a local file, you use this setting and what amounts to
file://
URLs (meaning they are on the local filesystem), for images that you are fetching over the web, you do not use
localurl="true"
d
Thanks for the ideas folks.
• http doesn't work, possibly due to IIS config, which I don't want to change just for this ◦ No missing image icon, just nothing • A file URL either ties this to the drive letter, or is relative to the calling files, which are multiple, in various locations, so not great I'm ok with using the production URLs, unless some other problem shows up. So I thank you all for your ideas and research, but neither you nor I need to spend any more time on this.
d
For posterity, did you try using a file mapping?