[quote=8889:@Sean Mitchell] RA: <To be true, I don’t care if the result can be considered as “sub-standard”>
You customers will care if the PDF doesn’t wok in their favorite PDF reading app.[/quote]
The correct quote is <To be true, I don’t care if the result can be considered as “sub-standard” if it works>.
Definitions (just to be clear):
As “if it works” I mean “Opens correctly in any standard PDF reader”.
As “sub-standard” I mean “Don’t need to follow the entire PDF specification with all kinds of situations, just the basics to complete the necessary tasks of generating great reports with graphics included in all supported platforms”.
Well, I expect the feature to be added to Xojo. It’s scheduled in Feedback already. But still you may do some things there, but not all the stuff DynaPDF offers.
About creating document PDF i download DynaPDF Plugin from, but i cant integrate the plugin into xojo, i copy the file MBS Real Studio DynaPDF Plugin.rbx and it does not appear at plugin Controls, do someone could help me?
About creating document PDF i download DynaPDF Plugin from, but i cant integrate the plugin into xojo, i copy the file MBS Real Studio DynaPDF Plugin.rbx and it does not appear at plugin Controls, do someone could help me?
[/quote]
It’s not a control. It’s a set of classes that lets you create the PDF. Take a look at the multitude of examples that MBS has specifically for DynaPDF.
[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]
There should be a lot more open source projects for frameworks that solve problems in Xojo. This is one thing the RealBasic/Xojo community lacks (to make it more popular): either you pay hundreds of dollars for 3rd party plugins or have to reinvent the wheel. Ok, there is MacOSlib, but there is need for a WinLib, a LinuxLib, a decent database abstraction layer, … too. Other languages have dozens of open source frameworks to solve problems
I understand that just demanding something is not the best way to get it done, but I’m pretty sure that there are people here who think the same
Agreed. But there are a lot more things that Xojo Pro should provide to make it a decent platform to develop with. Most of these features were on the “scheduled”-list for years…
I think there is a PDF feature coming in one of the next versions. At least it’s scheduled.
But writing a complete PDF library which does everything and keeping it updated is a lot of work. So DynaPDF has it’s price.
Why do I do not understand ?
A pdf file is ‘only’ a ‘printed in a pdf’ file.
Actually, and for nothing (or so), I create pdf in both OS X (nothing to add, only click in the Print to PDF button ) and Windows XP (I need to add a free ‘pdf virtual printer’).
Mainly, I print ListBox data contents into pdf (I never tried to print to paper with the code). Then the pdf is used (eventually) to paper. This is done in production (with either OS X and Windows XP). It have front page, header and footer in all other pages (with page number, left / right footer).
The only thing I was not able to do was to print two columns in one or more pages as Landscape while the first page is Portrait. Note that I do not waste time to really try. I only ‘skip’ the feature
Is it possible for someone to explain the concern ?
PS: of course, a native Xojo ‘command’ Export as PDF like Apple have done with TextEdit is welcome.
Otherwise as “John Scanlan” mentioned download RSPDF (https://github.com/roblthegreat/rsfpdf) which is a port of the php PDF library. The application is made for windows and using the zlib.dll. But this could easily be made for other platforms as well.
[quote=37811:@Emile Schwarz]H
A pdf file is ‘only’ a ‘printed in a pdf’ file.
Actually, and for nothing (or so), I create pdf in both OS X (nothing to add, only click in the Print to PDF button ) and Windows XP (I need to add a free ‘pdf virtual printer’).
[/quote]
You are missing the point.
Let me give you a few examples… I wrote an app that people use to submit test requests… They fill out an on screen form from info in a database… From their choices behind the scenes I create a PDF sample submission form as file. That file is NOT printed but automagically Emailed to the department doing the testing and the submitter.
Another example is taking a batch of data files ( usually 10-50, both Text and PDF) produced from a instrument, reading them , renaming the PDFs to something human readable, creating a PDF summary report as a FILE , Taking the PDFs produced by the instrument and the one I created in code, zipping them and Emailing them to the requestor. There is very little the operator has to do and is a huge time saver. I also wrote an web app with that functionality. In Web Apps PDF printers are often not an option ON THE SERVER. So in a web app PDF reports created as files on teh server that can be downloaded and displayed in the browser would be huge
Neither of these things could be done using a PDF printer but it allows us run a paperless. As I said right now I am using Asher Dunn’s open source classes but they have some issues
Open source projects require a certain number of contributors to succeed. Historically the community has not come through with the exception of a few libraries (but then mostly through the hard work of a few key individuals).
So that leaves the 3rd party community (such as myself). Like you, I have to pay my mortgage and feed my family, so the work I put into a product has to see some monetary feedback. There are lots of products that died out after a few years simply because the developers weren’t making any money at it. Some of this is because the community has, historically, not supported 3rd party tools and developers very well and add in that the Xojo community is smaller than some other dev tools.
So it’s a double whammy. Little 3rd party development because few buy. People complain about lack of 3rd party options. Entire community has few options and depends upon Xojo Inc. for all options.
PDF is like a complete programming language. I’ll bet that the scheduled “PDF support” will be very very simple. Something like iText for Xojo would be really nice. This was much easier to understand than DynaPDF where I gave up.
Well, the third party market is indeed small. While I can make a living from my work, but I got already 10 different products with reasonable pricing. I can see that people giving away classes/plugins for just a few dollar will never make enough to justify the time.
DynaPDF was I think the 3rd or 4th library I wrote something for. But as it has everything and does things right, we continued with it. It has a price (starting at about 200 USD), but it does the things you need. I have seen many other solution which had problems with font embedding, templates, referencing one image on multiple pages and not doing compression/encryption wrong. Not to mention all the trouble with colorspaces. And with Jens we have a dedicated developer working all day on this library and responding to problems very quickly.
I don’t expect too much from a built in PDF function in Xojo except maybe it being very comfortable (just one or two extra commands on graphics class). But for real PDF handling you’ll need more.
Just an unsolicited testimonial for Christian’s plugin: I’ve used his DynaPDF more than a few times, and it works great. Documentation is sometimes a bit sparse, but there are lots of examples. I’d rather pay a fee once a year than spend days hunting around for an open source solution that may or may not have the parts of the PDF spec I’m interested in implemented.
[quote=37838:@Karen Atkocius]You are missing the point.
…
Neither of these things could be done using a PDF printer but it allows us run a paperless. As I said right now I am using Asher Dunn’s open source classes but they have some issues[/quote]
Exactly. Generating the PDF yourself also ensures you have 100% control over it (whereas “printing to a PDF” relies too much on what the user has installed and what he touches around in the print dialogs). This means PDFs that are 100% the same regardless of platform.
Lastly: Controlling the PDF generation you can implement functionality that may not be native to the platform’s “PDF Printer”, add metadata (PDF supports a ridiculous amount of metadata, which is vital for efficient paperless offices and automation) and programmatic barcodes, etc.
