PDFDocument - What users desire

I would be interested to know what other users expect from Xojo’s PDFDocument class introduced in 2020, what they need, what extensions they would like to see.

UTF-8 support is my top priority at the moment.

Perhaps this thread can also serve to give Xojo (@Javier_Menendez) an overview of PDF feature requests.

What do you need?
    • UTF-8 Support
    • optional embedded Fonts
    • Comments (Annotations)
    • Encryption
    • Transparency
    • Brushes
    • Shadow
    • Multiple Page Sizes

0 voters

(X) Object2D support

2 Likes

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.

  • Karen
3 Likes

Hyperlinks are not currently supported, but are in the pipeline according to the blog post. I also need these to create a table of contents. I think we will still get this from Xojo.

2 Likes

There are two types of TOCs…

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.

-Karen

Yeah I know, we need Bookmarks and Hyperlinks.

  • html
  • header
  • footer
  • tables
  • text as text and not as image
1 Like

Ability to do page numbering simply…

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”

-karen

IIRC he said that tables were planned, and text already is text and not an image.

-Karen

and text already is text and not an image

Didn’t someone say that the result is one big image? That’s also the reason for the PDFs being so large.

That is what people assumed early on, but I don’t think it turned out to be the case for text… I think I was able to create a test doc and select/copy text in it IIRC…

But as as I said for my current project I have stuck with the plugin, so have not done much with Xojo PDF.

I don’t think they are supporting compression at this point, which might explain the size if it is unexpectedly large.

-Karen

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 :wink: ).

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 :frowning:

The rest are nice add-ons (links, page count, etc.)

That’s only true for the Report Engine. If you draw your PDFDocument from the scratch, it’s selectable and scaleable.

It supports compression.

Sure, if you do your own rendering engine with page objects, you could do page numbering.

What do your mean with HTML?
Header/Footer? You can do it by yourself.
Also like tables. Look in the samples folder, there‘s something which „mimes“ tables.

How would one do that in Xojo?

-Karen

(X) Drawing 300+ DPI Images

1 Like

Quick’n dirty thoughts

  • 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.

You know there is a HUGE difference between te Einhugur PDF and DynaPDF PFD. Xojo should have shot for Einhugur Level PDF support… which really is basic (no tables etc) PDF support

The Einhugur plugin is based on LibHaru is free for any use open source C code. Xojo could have chosen to wrap that and gotten ALL of the basic PDF functionality…

In fact several years back they looked at using LibHaru and decided not to use it.

-Karen

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.

1 Like

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.

-Karen

1 Like