Interesting. I have never had a situation where I did not have a relatively
good idea of what a document will look like such that I couldn't create 1 or
more variable populated forms to cover all the possibilities.
John Baughman
1331 Auwaiku Street
Kailua, Hawaii 96734
(808) 262-0328
john...@hawaii.rr.com
> On Jun 14, 2018, at 7:14 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> John,
> Yes. No 4D form printing at all.
>
> On Thu, Jun 14, 2018 at 10:14 AM JOHN BAUGHMAN via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
>> Kirk, are you talking about creating the pdf strictly in code?
>>
>> Otherwise, as Pat pointed out 4D Write Pro can be used, as can 4D forms…
>>
>> SET PRINT OPTION(Destination option;3;$FolderPath+"MyTest.pdf")
>> OPEN PRINTING JOB
>> Print form("MyTest4DForm";Form header)
>> CLOSE PRINTING JOB
>>
>> PDFs from 4D forms using this methodology works both on the client and on
>> the server.
>>
>>
>> John Baughman
>> 1331 Auwaiku Street
>> Kailua, Hawaii 96734
>> (808) 262-0328
>> john...@hawaii.rr.com
>>
>>> On Jun 14, 2018, at 5:37 AM, Pat Bensky via 4D_Tech <
>> 4d_tech@lists.4d.com> wrote:
>>>
>>> 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 USE PAGE SETUP*(oWPdoc)
>>>
>>> *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 :)
>>>
>>> Pat
>>>
>>> On Thu, 14 Jun 2018 at 16:22, Kirk Brooks via 4D_Tech <
>> 4d_tech@lists.4d.com>
>>> wrote:
>>>
>>>> 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:4d_tech-unsubscr...@lists.4d.com
>>>> **********************************************************************
>>>
>>>
>>>
>>> --
>>> *************************************************
>>> CatBase - Top Dog in Data Publishing
>>> tel: +44 (0) 207 118 7889
>>> w: http://www.catbase.com
>>> skype: pat.bensky
>>> *************************************************
>>> **********************************************************************
>>> 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:4d_tech-unsubscr...@lists.4d.com
>>> **********************************************************************
>>
>> **********************************************************************
>> 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:4d_tech-unsubscr...@lists.4d.com
>> **********************************************************************
>
>
>
> --
> 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:4d_tech-unsubscr...@lists.4d.com
> **********************************************************************
**********************************************************************
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:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
