I just chimed in on a conversation on the forums about using PDF Creator <http://forums.4d.com/Post/FR/24699370/1/24714745#24714745>. In this case the OP was asking about making it work on the server. I'm sure anyone who tried to make that work just gave a little sympathetic groan.
Making PDFs is hard. True - with a Mac or Win10 it's become pretty easy to print-to-PDF. This is really a user-interface feature though. If you need to build a PDF in code and want to work with the BLOB of that document using the OS print features starts to fall apart. If you want to do this on the server it's a complete non starter in my view. This is where things get tricky in 4D land. Actually pretty much everywhere I suspect but I don't know everywhere. It's actually possible to build perfectly valid PDFs in native 4D. Neil Denis gave a Summit presentation in 2016 demonstrating this. Working with his demo gave me a workable solution for a bit. But sometimes the PDFs wouldn't be valid and wouldn't always open. I don't think it had anything to do with Neil's work but my own additions. From here I spent way too much time building my own PDF component in all native 4D. PDF language is all text based so there's no reason you can't do it in native 4D (well, without the flate/deflate compression). But it is hard. The challenge was sort of interesting to me and I now have a fairly good understanding of how a PDF document is structured internally. In the end I had a working solution for a specific set of uses and the files were always valid <https://www.pdf-online.com/osa/validate.aspx>. The problem was it wasn't a full solution. I didn't have bookmark capability, for example. Or form fields. It was decent but very limited. BTW - making PDF is hard. Debugging PDF is even harder. Prior to that I tried most of the other options I heard folks talk about here: PHP, HTMLTOX, various schemes for managing printing on user machines and probably some others I've blocked out of my memory. All of them worked to varying degrees of success but all of them also required a slightly different way of coding, for the ones that build the PDF in code. I could never sell the idea of the pricier solutions (this is for the in-house app I wrote). A couple of months ago the need for more robust PDF features came up. Looking at my work I realized it just wasn't worthwhile for me to spend the time to build it out in my own component so I took another look around at the available options. I happened to email Rob Laveaux with some question about his plugins. He got back to me suggesting I look at QPDF instead. And here is where this turns into a big plug for QPDF. The licensing on the older set is pricey. And at 1k euro QPDF isn't cheap but it has the same no-hassel many of his products do. QPDF uses a C library (DynaPDF, which is a large chunk of the licensing fee). Working with QPDF did require me to refactor the methods that produce my key documents. And I had to spend some time prior to that learning how to work with the new command set. I think the time I spent studying the Adobe docs on PDF construction helped make this go faster. The result is what I consider a successful refactor: cleaner code, less of it, more capability, better output. Plus a core PDF module that makes building new docs pretty simple. As I mentioned in the post on the forums I am starting to look at a 'print' job as more of 'producing a document' than a piece of paper. If it's something that needs to be stored, shared, downloaded from the web or produced on the server it's going to need to be produced in a blob and that's going to be a PDF. If it's truly something a user needs as a piece of paper it's a print job. Producing PDFs in code means no form editor. This isn't always a bad thing. Sometimes it's as much work to make a complex document render correctly through a 4D print form as it is to simply write the code to assemble the data. It really depends on the data and the document. -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
