PDF feature request

This feature request : <https://xojo.com/issue/10701>

to be able to create PDFs in Xojo is number 4 and has been marked as scheduled since September 15, 2011…

Given everything else on the table, is there any chance at all of this seeing the light of day this year?

  • Karen

Well, I heart some time ago they would be working on it.
But well, if you need something today, you may consider the DynaPDF Plugin from us.

I still use Asher Dunn’s open source classes to create simple reports that are mostly tables… While the PDFs produced display/print correctly on both Mac and windows, unfortunately on Windows you also get an error message saying the file damaged and when you go to close the PDF it asks if you want to save changes… No users have complained and nothing is lost or unusable, but sooner or later I’m sure someone will…

I have been waiting for Xojo Inc to implement PDF creation so I could replace Asher’s code.

Guess I will need to be more patient! :wink:

  • karen

I use Christian’s plug-in. It works pretty well but it has a zillion functions and I feel like I’m not taking advantage of them because the docs are rather terse. More example code would be helpful. For example the DynaPDF has a function for creating a table but I make them from scratch because I couldn’t figure out how it worked.

If xojo added PDF then I’d guess the code would be more discoverable/straightforward like the rest of the language and that would make it compelling. Let me define a few parameters (size, columns, headings, xy coordinates, etc) and then send it a few arrays. Boom! Instead I’m drawing lines and creating loops that are understandable when I write them but weeks later I stare at them and wonder what I was doing… It’s annoying.

And even integrated with the report designer.

Pardon ?
PDF is an output destination like a file, printer, pdf etc.
It has nothing to do with HOW the data gets there - a report could be output to a PDF just as easily as a hand written dump of data or perhaps even the printout of a project.

So I’m really not sure what “integrated with the report designer” would even mean

We’ve talked about creating our own PDF library. Then we see everything we can do with DynaPDF without living a finger (other than writing the check). It’s hard to get started when you know there’s a solution already there, not to mention already using in some projects.

The table class in DynaPDF is brand new. Not even documented in the normal manual. But that will come soon.
I just have the docs I wrote for the plugins and the sample code.
In my tests it’s quite fast and very easy to use, so please check the newer examples.

And for Xojo, if PDF is added there, don’t expect too much. Maybe writing a PDF with lines, text and images. But DynaPDF Starter will probably do much more.

Well, it would actually be best if they allowed subclassing the Graphics class. That way, we could easily come up with methods that both draw to a picture object or a PDF file using any 3rd party solution like Christian’s or RPDF.

I encourage you to sign on this feature request: <https://xojo.com/issue/11391>

[quote=8818:@Norman Palardy]Pardon ?
PDF is an output destination like a file, printer, pdf etc.
It has nothing to do with HOW the data gets there - a report could be output to a PDF just as easily as a hand written dump of data or perhaps even the printout of a project.

So I’m really not sure what “integrated with the report designer” would even mean[/quote]

I expressed myself erratically. Better to say “report engine” than “report designer”.

Capability to generate PDFs, even unattended in background, without external PDF printer drivers that can be inexistent on the target machine. Things like (illustratively):

rpt1.Document.PdfSave(“report1.pdf”)
rpt2.Document.PdfAppend(“report1.pdf”)

Or something better Xojo engineers can imagine, because this way the PDFs will be huge, due to the nature of Xojo Report Documents being currently bitmaps.

You have sample code for the TableClass? I can’t seem to find it.

It’s “DynaPDF Table.rbp” in the 13.1 examples.

My apologies. That’s actually a really good example. I’m not sure how I missed it.

Grab a copy of esoTalk and make one of these forums for your suite of tools. Or do you already have one that I missed? Honestly, I get a bit lost on your site. Sorry if I sound critical but I feel like I’m not taking full advantage of the great tools you make and having a place to ask questions would be helpful.

To me it would mean that whatever report I created could just be “sent” to the pdf class and viola it would be rendered. Something like

mInvoice.RenderPDF(SpecialFolder.Desktop.Child("Invoice #"+mInvoiceNum)). 

Wow, I really don’t follow the reasoning for adding PDF capability to Xojo. It is better to use classes or a plugin like dynaPDF or other standard PDF library. Producing a PDF library from scratch for Xojo will probably lead to a sub standard version of a pdf engine versus using other PDF engines that already existed for years. If Xojo inc uses and existing PDF library and integrate it into Xojo then it may not be so bad. Having a full PDF engine native in Xojo just seems like over kill.

Also Asher Dunn’s PDF code is pretty old if you have the source code someone on the forums could probably fix it for you. His code should be pretty easy to fix.

These days it’s a very common need (particularly Xplatform and Web) and ideally should be tied into (but not limited to) Xojo vector (2D) graphics. It would be a significant selling point IMO… In any case a starter license for the plugin goes for almost $200US and that is an issue.

BTW Years ago I used Asher’s open source code and created a very limited API to be be able to draw to the screen with object2Ds and use the same code to create vector PDF’s … could not extend it because I would need to go through the PDF spec ( which is frightening large!!!) as Asher went commercial.

[quote]
Also Asher Dunn’s PDF code is pretty old if you have the source code someone on the forums could probably fix it for you. His code should be pretty easy to fix.[/quote]

I have the source code for his initial older less capable open source version… In the last open source versions he mentions me in the docs for helping understand something I have long since forgotten!

In any case It’s not the RB (oops I mean Xojo) code itself that is the issue… I can and have updated that for language changes (changes were minor). Again it is learning/understanding the PDF spec well enough to know why SOME PDF readers complain. (Preview has no issue with the PDFs I produce BTW)

  • Karen

You just pointed out a good reason why using and established PDF library is probably the best thing to do. I understand that the price for a pdf library like dynaPDF but it is a pretty good library. Some years ago I created a PDF library from scratch and it took me some time to a create a PDF library good enough to be rendered without error. Understanding the PDF specification is not the only thing you need know but reverse engineering also plays a big part in the process of creating a decent PDF engine or library. Some PDF readers just aren’t worth the code they created with.

Is Asher’s code open source? I might be able to take look at it if you like. If so forward me the link so I can download the source and take a look. Also do you have a description of the error that you are running in to?

To be true, I don’t care if the result can be considered as “sub-standard” if it works, but being able to generate PDFs from a report writer engine is a standard nowadays, and great for web reports. You could create visually and easily a report, and then you integrate it into your app, not needing “coding by hand” as we did in the past, and your app can generate a large financial report, save it in a PDF, register this in a database and people would download it. It saves time and work. We can’t presume the quality level they will reach. They can use code and help from some expert, for example. :slight_smile:

I forgot to add that Apples Preview is one of the most forgiving apps out there for reading the printable part of a PDF. Preview can read PDFs even later versions of Adobe reader or Acrobat will not read.

You customers will care if the PDF doesn’t wok in their favorite PDF reading app.

I understand the value of having a PDF library for use in Xojo apps its the reason why I have built my own library. Experience has show me that if I build a basic PDF engine for one purpose and it works for one app. The next time I build and that app my needs for a PDF engine changed. You then realize that the work done on the first version the PDF engine was not enough so you add more functionally to the next PDF engine. Afterward it becomes a long cycle of adding functionally for every app new app you create. So I go the point were I had to come to the Conclusion that the purpose of my app wasn’t to create PDFs. The PDF functionality at that time was only to enhance the functionality of my app and I should speed time building the app not worry about building a PDF engine because there are others who build a PDF engines for the sole purpose of building a PDF engine. Thus reason for native building a PDF engine in to Xojo from scratch does make much business sense to me.

It would be better just to start and open source project for A PDF engine/library for Xojo. I would definitely use my experience to help out where I could if such and open source product was created.

[quote=8889:@Sean Mitchell]
It would be better just to start and open source project for A PDF engine/library for Xojo. I would definitely use my experience to help out where I could if such and open source product was created.[/quote]

It would be better if the Xojo Pro actually had Pro like features like DynaPDF licensed and integrated out of the box.