PowerBuilder’s prowess to be able to create Portable Document Format (PDF), has been supported for a long time in the product’s history. PDF documents have become the gold standard for delivering information, especially in the form of reports. PowerBuilder’s PDF generation capabilities are as follows (in historical order of their introduction):
- External DLL – third party solutions that can be called via PB external method declarations in the early days of PB.
- XLSFO (Extensible Stylesheet Language Formatting Objects) - a Java-based solution included with the PB run-time and supported by the DataWindow, which was introduced in PB 7.
- PostScript Printer – third party printer solutions that do not require a PB interface but only require a PB app to print to an MS-Windows installed printer.
- GhostScript – an open source solution that PB can utilize via a specially installed printer definition named “Sybase DataWindow PS”, which was introduced in PB 9.
- NativePDF – a built-in PDF solution (i.e. doesn’t require separate licensing or installation of third-party solutions), which was introduced in PB 2017.
All the above PDF generation mechanisms are still in place today (for backwards compatibility) in PB 2017. However, it is important to understand the advantages and disadvantages of these PDF generation mechanisms and use the appropriate one for your project, especially considering the enhancements made to the NativePDF option in the upcoming PB 2017 R3 release. In this blog, we’ll attempt to get a better perspective on these PDF options.
A variety of external PDF solutions exists for PowerBuilder and are commonly used in many existing projects. However, they often come with a significant extra price tag. They also come with the requirement to define external functions and maintain PowerScript code to support the external connectivity. Since these are developed and maintained by third party vendors, if you chose an unreliable vendor or the vendor ceases to continue the product then to move to a new vendor’s product usually will require a significant re-programming effort. On the plus side, if you choose a good third-party product, it produces a high-quality rendering and supports advanced PDF features.
The XLSFO PDF feature is a free PDF generation feature that is still based on accessing Java classes. While the latest PB still installs with the XLSFO libraries, this is a deprecated feature and therefore has not kept up with modern generation options. Thus, PDF rendering quality suffers greatly when using this mechanism and also handicaps the application developer from accessing advanced PDF features.
PostScript printer-based solutions are still quite popular. While these PDF implementations are easy to use and externally disconnected from PB-based apps, they come at an extra price, higher challenge to deploy/set-up and maintain. They also handicap the application developer from accessing advanced PDF features.
The GhostScript approach has the advantage of being open source and provides a relatively good rendering. However, the free license prevents the developer from distributing the software with the deployed PB application executables. Instead, the business user must download and install the software on their own. Not a trivial task sometimes for the non-IT person. If the developer would like to deploy GhostScript with their application, they are then required to license the software at a cost. The GhostScript feature is much better at rendering PDF documents than XLSFO, but it still handicaps the application developer from accessing advanced PDF features.
The latest NativePDF feature, which is built into PB 2017, is free and easy to deploy as its part of the PB run-time. Appeon has also been hard at work improving the built-in PDF feature in following revisions (e.g. R2 and R3) since the initial release of PB 2017, in the areas of: performance, flexibility, and functionality. This makes the NativePDF feature now a fairly robust PDF solution for the PB developer that can support some advanced PDF features. Here are some of the highlights of the NativePDF feature:
- No extra cost (included with your PB license) and easy to deploy
- Easily enabled via an INI setting, PowerScript or by the DataWindow object
- PDF can use “custom” print settings and fonts can be incorporated into the PDF
- The developer can set the ISO standard to be used for the PDF generation
- A master and/or user password can be assigned to the PDF document
- Restrictions can now be imposed on a PDF such as: not printable, non-modifiable, no annotations allowed, non-copiable, etc. just to name a few
- Using the new SaveNativePDFtoBlob command, you can now build a PDF directly in memory
With the new NativePDF, free PDF generation options for PowerBuilder has been taken to a whole new level. If your applications are still on one of the older PDF generation mechanisms, you might want to give the NativePDF a test drive to see if it benefits your projects. Feedback from most users is that it will at least simplify licensing and eliminate deployment headaches.