CFDOCUMENT. It works if you know how.
September 10, 2007
Many people have tried and few have succeeded using CFDOCUMENT to print their HTML.
For those that don’t know, here is how I’ve tamed the beast numerous times. Using these techniques you should be able to get CFDOCUMENT to print your HTML perfectly.
1) Your page must be valid XHTML 1.0 Transitional. Once you have created your HTML, run it against W3C’s validator and make sure it validates. So make sure to start your HTML with the following:
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml”>
2) Use @import to include your CSS. Don’t use the link tag, inline styles or a style block. It must be included with @import.
<style type=”text/css” media=”screen”>@import “style.css”;</style>
That’s it!!! How easy is that. I can bet you that just by doing these two things you can eleviate many of the headaches that you have getting CFDOCUMENT to print properly.
* Remember that border-collapse doesn’t work and there is currently no fix for it.
September 11, 2007 at 3:35 am
I believe the main requirement is that is is a valid XHTML page and that the print media stylesheet is valid. I did not find the xml declaration or using import for stylsheets was necessary.
I have had problems with page breaks - images, lines of text (pdfs mainly) split over two pages. I believe the issue is with the print stylesheet more than anything else.
See below - same content dynamically generated in different formats
http://www.assetnow.com/index.cfm/1,82,252,0,html
http://www.assetnow.com/index.cfm/1,82,252,0,pdf
http://www.assetnow.com/index.cfm/1,82,252,0,mfp
October 19, 2007 at 12:49 pm
Your pagebreak problems could be a result of your margins declared within the tag, and the amount of space needed vs the allocated there for your section items. The ‘margintop’ number allocates space for your header, same goes for ‘marginbottom’ for the footer. Everything in between will break up into however many pages is necessary to display it.
What I can’t figure out is, if I create more than one multiple-page document, (via cfoutput query or cfloop within the cfdocument tag) how do I get the page number to restart at one? (I can number a single multiple-page document with no problem, of course.)
October 19, 2007 at 1:01 pm
@kathleen,
Thanks for the tips!
don’t know about the page numbering problem though.
October 25, 2007 at 10:01 am
What about this? I am trying to include a bar code graphic on the page. If I create the pdf, you may or may not see the graphic and it won’t print at all. The only time you see it on the screen is when you zoom in.
November 6, 2007 at 10:21 am
The thing with barcodes is that you have to embed the font. You can do this in the cfdocument tag (fontembed=”Yes”). Remember that you then have to use inline styles: <span style=”font-family: IDAutomationHC39M;font-weight: normal;font-size:28px;”>*12345*</span>
Remember that some barcode fonts only work at specific font sizes (read the manual of the barcode font)
I did not find it necessary to use @import to include CSS, a simple style tag with the styles inside work just as well.
Also, there is no need to declare the XML, just be sure that the contents is strict XHTML.
Another thing: The top margin tends to behave a bit different than expected. If you set the margintop at a specific height, but the contents of the header is bigger, it will overlap the contents of the pdf.
December 2, 2007 at 4:27 pm
Finally found this article after hours of frustration. Simply adding the proper page headers allows the PDF to generate. Thanks for your help and placing this article out into the world.
February 18, 2008 at 7:54 pm
I upgraded our test server to CF8 and our generated PDFs became a mess. We have random spaces between words, bad text alignment and random invisible text (white on white). Worse still, the PDF file size has tripled!
Even when using valid XHTML (as verified by validator.w3.org) complete with declarations the problems persist.
Regarding the bloated PDF file size, we use fontembed=”yes” because without it all of the text looks too bizarre to read. We’re just using Arial as well which is odd. In CF7 we used fontembed=”yes” and the file size was still 1/3 of what it is in CF8.
All of these significant changes to CF8 should have been documented by Adobe including a section on “how to do it so that it works”. Argh!
Does anyone have some more pointers that could help please? Thanks.
Gary.
February 28, 2008 at 4:13 pm
I have tried these steps. The outcome was still the same for me. CFDOCUMENT still renders the pages about 30 percent smaller than what CFDOCUMENT did in CFMX7.
March 11, 2008 at 6:47 am
Same problem here!
Thanks for the tip with the document type.But it dont really solved the size problem. Also installed the newest hot fix and tried with various doctypes.
By the way, the file sizes are also different: CF7 PDFs are ca. 70 - 100kb, while CF8 generates 550-600kb files! Is there probably a problem with dpi resolution?
I would go back to CF7, when theres no sexy cfthread tag in CF8…
Any ideas?Thanks
March 11, 2008 at 12:01 pm
@rampage
i would suggest filing a bug with Adobe. make sure that went you do, you include the code and the result for both cf7 and cf8.
March 22, 2008 at 12:31 pm
I am trying to use the cfdocument tag to create a dynamically generated pdf. For some reason, anything inside of the tag will not show on the pdf, its like it just skips the output variable…any thoughts?
Thanks!
March 31, 2008 at 3:35 am
@Sean
I am seeing the same thing. If I do a very basic cfdocument with just a single line which outputs the date then it works. As soon as I try and include anything more complicated (not really complicated just a bunch of paragraphs of text with a few variables) I get a blank pdf! My more complex page is valid xhtml and the css is also valid, whereas my demo page is literally:
#Now()#</cfoutput
and this works! Any ideas?