I use the Einhugur PDF plugin based on the open source LibHaru. As i started my current project before Xojo PDF support was released I have have not looked to closely at it yet.
The Einhugur PDF plugin can do most of the things in that list in some form and I do use most of them…
In addition It can also do hierarchical table of contents for the PDF as well as link navigation in and outside of the document. Being able to create a TOC is important for my current project and both were used for my last big project.
For me, TOC support is a must have (link support has been a nice to have) and I don’t know if Xojo supports that.
The first one is the traditional (from paper days) TOC in the the document itself with hyperlinks (which I think you are referring to). All you need to implement that type of TOC are hyperlinks.
The seconds one is the collapsible hierarchical TOC that shows in the side panel and is not part of “printed” document.
That type is nice because one has clickable access to the whole TOC tree in the sidebar regardless of where you are in the document.
While related, supporting that is not exactly the same a just supporting hyperlinks. I did not see TOCs mentioned explicitly in that blog post. I see those as important in the for the type of documents I need to produce.
Correct me if I am wrong, but I don’t think the Xojo graphics class approach allows savings a reference to each page and then go back and do the page numbering in a simple for-next loop.
Page X of Y is something a lot of documents need in either the header or the footer.
I think one would need to “fake print” the document first to count the total pages if the number needed is not easily calculated.
I do page numbering with the Einhugur plugin by saving a reference to each page as I go along.
In fact i wait and go back to put the entire header on each page AFTER I have created all the pages and added all the other content to them. At that point I know the total # of pages and in this case the header contains the “Page X of Y”
It is a difficult call, as much as I think that it is extremely important for Xojo to offer pdf functionality out-of-the-box, especially for Web. Many use cases consist in “exchanging” data with the user, and pdf is very convenient for showing results (and invoices ).
However I’m spoiled by Einhugur and the MBS DynaPdf plugins. It is hard (and probably not wise) to expect Xojo re-inventing the wheel here, but there as some functions which are just a must have, even for beginners.
Headers, footers, tables and most importantly UTF-8. For international users having to work with local languages it will be useless without UTF-8. I won’t unfortunately even look at it, as long as this is not implemented
The rest are nice add-ons (links, page count, etc.)
Create a Document class and add a Pages() array to it, as well as a Draw method.
Create a Page class and add a Draw method to it. Also an Index property and maybe a Parent As Document object (then you could even do without the Index property and just call Parent.Pages.IndexOf(Self)).
Using the index of Document.Pages you can now output the page numbers in Page.Draw.
All you need to do is render the document before drawing it in PDFGraphics.
Yeah that’s currently not optimal and I’m sure we will get some better picture support. The problem using PDFGraphics.DrawPicture with scaling parameters is, Xojo internally creates a new low res picture.
Yup, I know, that’s why I’m using both. Closefisted customers: less features. If the want more, MBS (but then I let them “participate” on the licensing costs ;-). Do you know what Xojo is using now? I think it is fair that they released it now, though not all features are in yet, but I’m sure there will be more to come. But I did not yet dive into it, as not being able to use local languages would be a showstopper for me.
That is essentially what I do with the Einhugur Plugin… It’s PDF document does not track pages BUT it has a separate page object that one gets by calling Doc.AddPage
which one can save… I subclassed That PDFDocument class to save the pages
Are essentially proposing creating your own page object and it it recreating all the PDFGraphics methods/properties and caching the commands/property settings, then replaying them when one actually renderings them with a PDFGraphics Object?
If so, that is possible but a heck of a lot of work, which would would keep needing to be updated every time Xojo adds more capability to Its PDFGraphics class…
Yes I do have the coding experience to do that, and if Xojo PDF was the only option and they were not planning to add more functionality I would do that… But neither is true… and being able to to put Page X of Y on a document is kind of a basic requirement for many documents…
BTW not being able to to that for old fashion Xojo printing with the Graphics class without “fake Printing” because pages are not object oriented, is why I never even considered projects needing to print documents more than 2 or 3 pages long before I started using PDFs
BTW for years I used an open source REALBasic object oriented solution from about 2005 because it could do that and more . In fact while it had some shortcomings it supported more drawing functionality than this Xojo implementation , including a very flexible table feature.