Another option, which may or may not be suitable depending on the project,
is to build the document with 4DWrite Pro and then simply set the print
option and print it:

*SET PRINT OPTION*(Orientation option;iPrintOption) // landscape or portrait

*SET PRINT OPTION*(Destination option;3;$pathname)  // PDF


*WP PRINT*(oWPdoc)

*SHOW ON DISK*($pathname)

This will require you to learn how to program Write Pro, but I think that
will be a bit simpler than learning how to create PDFs, it won't cost you
any extra, and those skills might come in handy for other 4D projects :)


On Thu, 14 Jun 2018 at 16:22, Kirk Brooks via 4D_Tech <>

> I just chimed in on a conversation on the forums about using PDF Creator
> <>. 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 <>. 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:
> Archive:
> Options:
> Unsub:
> **********************************************************************

CatBase - Top Dog in Data Publishing
tel: +44 (0) 207 118 7889
skype: pat.bensky
4D Internet Users Group (4D iNUG)

Reply via email to