Created Date: Nov 16, 2020 11:29
Last Modifed Date: Mar 30, 2021 12:57
Mako replaces PDFLib
Jaws PDF Library, usually abbreviated to PDFLib, was created to provide easy access to the Jaws technology for the purpose of converting PostScript to PDF and vice versa. This role has been superseded by Mako Core, the digital document SDK from Global Graphics.
For most PDFLib use cases, the introduction of PostScript input in Mako 5.0 (the
IPSInput() class) allowed a PDFLib user to switch to Mako, opening up many opportunities for document processing beyond the simple conversion task that PDFLib is able to handle.
Jaws PDF Library and the Mako Core SDK are at first glance very similar. They both offer an API to the Jaws kernel, offering conversion from PostScript to PDF and vice versa, with control over image resolution, font embedding, color conversion, etc.
There the similarity ends. To begin with, PDFLib is much older. It is written in C, not a bad thing per se, but it requires a lot of support code to get it going. Mako is much more modern, written in C++, and has been deliberately designed to be easier to get started with.
The type of application to which Mako can be put is much wider, going way beyond the simple conversion offered by PDFLib. Mako can render PostScript or PDF content, fully color-managed with a built-in CMM (color management module), or from any of the other PDLs it supports: PCL, PCL/XL, and XPS. Mako has a unique DOM (Document Object Model) that enables document content to be edited at a page level (such as splitting or merging) or within a page – examine or edit text, images, vector content, fonts, etc.
Two code examples of a minimal PostScript to PDF converter can be found on GitHub. They follow the same pattern, that of a simple command-line app that converts PDF to PostScript (or vice versa). One is written with the PDFLib SDK, the other Mako.
The Mako version is shorter (137 versus 208 lines of code), and tests show it is faster and produces more compact PDF output.
Mako offers several input classes to parse different PDLs (page description languages) for input.
An input class for that PDL (see list left) populates the Mako DOM (document object model) that can then be interrogated or changed.
The DOM may then be saved into any of the supported PDLs, enabling rich conversion from one PDL to another.
However, for PostScript this two-step process is slower than a direct conversion when compared to the way that Jaws PDF Library (PDFLib) works. PDFLib offers direct access to the same Jaws component that Mako uses but without the overhead of the Mako DOM.
For even faster PS to PDF conversion where there is no requirement to change the content in any way, Mako’s IDistiller class offers direct conversion from PostScript to PDF. A code example that is included in the Mako SDK can be found here on GitHub:
Mako IDistiller: (Github)
Bypassing the Mako DOM reduces processing time because the file is processed only once. When changes are required, two processing stages occur: The first is to read the file and populate the Mako DOM, and the second comes later when converting the Mako DOM to the output PDL (which could be any of the supported PDLs, not just PDF).
The difference is shown here diagrammatically.
Processing with the Mako DOM is far more flexible but comes at a small performance cost.
For Mako customers moving from PDFLib to Mako, the requirement is generally PostScript to PDF conversion, as quick as possible, so a direct conversion may be preferred.
Tests carried out with representative documents – color, grayscale, and monochrome – yield these results. The number in the filename refers to the page count, the times are in seconds.
The clear conclusion is that Mako is faster than PDFLib. Interestingly, these results also show that PDFLib got slower between version 5.01 and 5.02. The results also indicate that Mako 6.x is marginally faster than its predecessor, Mako 5.2.2, no doubt due to the tighter integration between Mako and Jaws, introduced in Mako 6.0.0.
The decision to end-of-life PDFLib was taken because it has clearly been superseded by Mako, which is faster, more capable, and easier to use. The introduction of the IDistiller class in Mako offers an API that is closer to the PDFLib approach while retaining the ease of coding common to Mako as a whole, and at the same time improving performance.
Mako is supported by a plethora of code samples, such as those linked above but also as part of the SDK distribution. All are tested examples designed to get developers to working code as quickly as possible.