Among the many services that OpenText Content Suite provides is PDF rendering. For years Content Suite offered rendering through the AdlibExpress rendering services. Following OpenText's acquisition of IGC, Blazon was offered as a substitute for Adlib.
Some of our customers reached out to us as they ran into rendering challenges, both with AdlibExpress and with Blazon. Their most common challenges have included:
- Performance, specifically throughput, the volume of documents that Adlib and Blazon can process. As customers increased their use of PDF rendering, overall system performance declined.
- Rendering of 8-bit font sets, character sets for languages such as Arabic, Chinese, Japanese, and Urdu.
- Supportability - both Adlib and Blazon require the document's native application (e.g. Microsoft Word) be installed on the rendering server. Most systems administrators much prefer to separate end-user, client-side applications from their production servers, but Adlib and Blazon must have those client applications installed and correctly patched to perform the rendering. And let's not forget the requirement that Tomcat be installed and configured too. A pretty complicated and relatively hard to support configuration for a production, lights-out environment.
In response to these needs, we added rendering to both PowerTools for Documents and to PowerTools Viewer - both use the same underlying rendering technology. PowerTools for Documents provides enterprise-scalable document production including rendering while PowerTools Viewer enables users to render individual documents that they're viewing.
Both products address all the challenges highlighted above:
For production rendering, PowerTools for Documents implements true server-side rendering as well as multiple rendering threads so as production demands increase you can increase the number of threads. Our customers tell us that they're getting excellent throughput with no increase in thread count (beyond what they've configured for users).
On-the-fly rendering is performed by PowerTools Viewer leveraging the user's Content Suite access thread.
- Our PDF Rendering engine has a specific compilation of the PDFJS engine which correctly implements Arabic and other languages scripting so both PowerTools for Documents and PowerTools Viewer correctly render 8-bit character sets.
- Neither PowerTools for Documents nor PowerTools Viewer require the native application nor Tomcat to run. Instead, PowerTools for Documents installs both Content Suite modules and a server-side service while PowerTools Viewer is installed solely as a Content Suite module - note that neither requires any client-side components or installations. PowerTools Viewer is a pure HTML5, zero-footprint viewer.
We've installed and configured both PowerTools for Documents and PowerTools Viewer on our Customer Portal. To test out both, we've prepared demo folders that enable you to try out both products using your Customer Portal login:
PDF Rendering Folder: Upload your test document to this input folder and our PowerTools for Documents rendering service will render it.
Note: Please don't upload sensitive documents and feel free to delete your document's rendition from the output folder after you've done your testing (we'll auto-delete the uploaded document from the input folder).
- On-the-fly rendering from the PowerTools Viewer Demo: Read the “Read Me” first file to learn how to use PowerTools Viewer. In the first step of the demo you'll see the “Export as PDF” button on the Action Bar - give it a try!
If you're a Global Cents customer and need a login to the Customer Portal, email firstname.lastname@example.org. If you're an OpenText Content Suite customer and would like a demo, drop me an email to email@example.com.