ACF 2016 is timing out generating larger PDF files using cfhtmltopdf with message "PDF conversion is failed due to timeout. Increase the timeout value in PDFgService manager settings." Does anyone know where this is in ACF 2016? I am looking in cfinstance/jetty/webapps but this directory is empty. Trying to find configuration settings for PDFgService.

@jcarp Where do you have the add-on service for the PDF manager installed to?

@bdw429s - THANK YOU! This was exactly the fix which I verified following your exact steps. PDF installation, configuration and directories exactly as you noted. The default time was 120 seconds. I have made a note of it in our documentation.

I used to have to generate many thousand page pdfs. Was only successful with performance on this by creating the pages individually into a directory, then merging all of the files in the directory with cfpdf ordered by name. was also able to thread the individuals, then run the merge after thread join. It's been a few years, but it worked rather well.

I've used wkhtmltopdf instead of Lucee's renderer, and it was awesome for both the better performance and the full modern HTML support, for what it is worth. (I haven't had a chance to compare it against Adobe's contemporary solutions yet.)

@Patrick S not sure if you're aware, but Adobes

<cfhtmltopdf>

is just a wrapper around the wkthmltopdf library

Oh, that is nice to know! 😄

@Patrick S Hey Patrick, I'm looking to change from Lucee's PDF renderer to wkhtmltopdf as well for better consistency (I'm kinda lost as to which version people recommend "Classic" or "Flying Saucer". I've had a few searches and people seem to use the ForgeBox version (not sure if that can run safely beside a non-ColdBox site (I'm running the site itself on CommandBox/Lucee)) and others seem to send it off to a separate Docker/AWS instance... and there seems to be a rather ancient CFML Custom Tag option - I'm just really looking for the simplest and correct way of doing it that is considered "the right modern way" 🙂 any helps or links greatly appreciated!

When I switched to wkhtmltopdf using Lucee I ended up writing my own wrapper for it, since there wasn't any at the time and had Lucee render out the html and output it to a file for it to render. (Figuring out headers and footers was a pain...) If I was starting now I'd definitely consider using a docker image to isolate it, but haven't had the chance to see how well it works.

@Jonas Eriksson

(I'm kinda lost as to which version people recommend "Classic" or "Flying Saucer".

I'm not sure anyone really 'recommends' either. The Flying Saucer is what the newer version of the PDF extension is using. It's more up to date, has more features, and that's the version of the extension receiving fixes. So unless you have old code dependent on some specific behavior of the classic engine, I don't think there's a reason not to be using the new stuff.

the ForgeBox version

Can you be more specific? There's at least 10 packages on Forgebox that appear to be related to "pdf" so I'm not sure which one you're referring to there. https://www.forgebox.io/?search=pdf

I'm just really looking for the simplest and correct way of doing it that is considered "the right modern way"

When it comes to generating PDFs, usually whichever way works for you is right 🙂 I'd start with the CFDocument tag and see how well it works for you. It's easy to use and can usually handle average load and average size PDFs pretty good.

@bdw429s I think he's referring to this one: https://www.forgebox.io/view/wkhtmltopdf

If that's the case, it needs to be explained that all the wkhtmktopdf wrappers out there are a totally different concept from how the CFDocument tag. The

<CFDocument>

tag • on Adobe CF is powered by a native Java PDF building library that is proprietary to Adobe • on Lucee in "Classic" mode is powered by a very old version of a native Java PDF building library called iText • on Lucee in "Flying Saucer" mode is powered by a recent version of a native Java PDF building library called Flying Saucer, which I think is actually powered by a newer version of iText internally Now, wkhtmltopdf is a native binary (not java) written in C++ which is compiled for different operating systems. There is a popular Node.js wrapper and when you run the CFHTMLToPDF tag in Adobe ColdFusion, CF is making an HTTP web service call to a Jetty powered java-based API which wraps the actual native Node library to generate the PDF and then send it back. Most of the Lucee wrappers you see including the lib above is a similar setup, but instead of being a built in CF tag, you just send the API call to a docker container or wherever you've spun up a wrapper for the wkhtmltopdf process. So it's pretty close to what Adobe does, just more manual of a setup.

Yes, the one Patrick mentioned was the one I was curious about. Thanks Brad for a thorough explanation of the differences, much clearer. And I've been using CFDocument and it basically does what I need, but there has been some hick-ups with page margins and font sizes seemingly being affected by various Lucee versions. I know this sounds "muddy" 🙂 I just want to make sure I'm on the right track and the client can avoid having surprises with Lucee PDF engine updates and perhaps wkhtmltopdf might offer that. Again, NOT blaming Lucee for changing/improving things, just looking for consistency and a client wanting the created PDFs to match his other business documents created in Word exported to PDF manually, which are then merged with dynamically created PDFs from our app and product brochures into a longer PDF (around 50-60 pages in total).

there has been some hick-ups with page margins and font sizes seemingly being affected by various Lucee versions. I know this sounds "muddy" 🙂

@Jonas Eriksson No, that's typical experience when it comes to PDFs. Unfortunately, I can't promise that changing to another method of PDf generation will be any different, or even less likely to have little changes between versions. Do put in tickets for any issues you have with cfdocument-- Pothys has done a lot of work to try and get bugs fixed there in Lucee.

There's a bit at the bottom of the README about how to get it to run outside of Coldbox

This is the type of thing I'd love to see written up sometime, that is quite a lot of pdf rendering, and knowing that it can scale well is great to know - as well as what sorts of stumbling blocks there might have been.