John, Using QPDF is much like using PRINT FORM. The plugin commands allow you to precisely control where on the page something (text, line, image) will appear. Unlike PRINT FORM you can add to existing pages. This greatly simplifies, for instance, adding page numbers in the form of "Page x of y". You can traverse back and forth through your pages if necessary.
QPDF allows me to use templates. These can be pre-formatted PDFs or I can build one on the fly. My usual workflow in a method is to create the document and set the meta data (author, date, subject, etc. - stuff I don't think you can do at all when creating PDFs via print engines). Then I'll make the page template with things like the report header and footer info. Then I basically run down the page adding material just like I would with PRINT FORM. I like to make my methods that add material to the page functions that return the last y value. Coupled with a method to check for available space and handle page breaks it works well. I may get around to locating these methods in a component for ease of reuse as I think about. A few other things I can do with the plugin are include existing PDFs. This didn't seem like an incredibly useful feature at first but it is. In the case of sales quotes some salesmen like to include cut sheets, drawings or brochures from the vendor with their bid. Another use is creating or reading PDF forms. If you have a PDF form you must populate but the form is really just a scan of something you can still place text in the appropriate locations on the page. It's a pain but you only have to do it once. Another benefit I don't believe is available any other way is adding bookmarks and internal references. Bookmarks are what you see in the sidebar and allow you to navigate large documents. Internal references are like anchors on a web page and work the same way. Don't get me wrong, I have not abandoned traditional print forms by any means. It takes some effort to build a PDF form in code for anything beyond very simple needs. It's not the right solution for everything. But for certain types of documents I'm finding working with it a very deep breath of fresh air. On Thu, Jun 14, 2018 at 11:07 AM JOHN BAUGHMAN via 4D_Tech < [email protected]> wrote: > 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 > [email protected] > > > On Jun 14, 2018, at 7:14 AM, Kirk Brooks via 4D_Tech < > [email protected]> wrote: > > > > John, > > Yes. No 4D form printing at all. > > > > On Thu, Jun 14, 2018 at 10:14 AM JOHN BAUGHMAN via 4D_Tech < > > [email protected]> 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 > >> [email protected] > >> > >>> On Jun 14, 2018, at 5:37 AM, Pat Bensky via 4D_Tech < > >> [email protected]> 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 < > >> [email protected]> > >>> 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:[email protected] > >>>> ********************************************************************** > >>> > >>> > >>> > >>> -- > >>> ************************************************* > >>> 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:[email protected] > >>> ********************************************************************** > >> > >> ********************************************************************** > >> 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] > >> ********************************************************************** > > > > > > > > -- > > 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] > > ********************************************************************** > > ********************************************************************** > 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] > ********************************************************************** -- 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] **********************************************************************
