Created Date: Mar 24, 2021 18:25
Last Modifed Date: Mar 24, 2021 18:25
New Feature: PDFLib Replacement
Jaws PDF Library, usually abbreviated to PDFLib, was created to provide easy access to the Jaws RIP technology for the purpose of converting PostScript to PDF and vice versa. This role has been superseded by Mako.
For most PDFLib use cases, the introduction of PostScript input in Mako 5.0 (the IPSInput() class) allowed a PDFLib user to make the switch to Mako, opening up many opportunities for document processing beyond the simple conversion task that PDFLib is able to handle.
However, the two stage conversion (using IPSInput() followed by IPDFOutput(), for example) is slower than the direct conversion offered by PDFLib. Additionally, IPSInput() is less flexible in its handling of a PostScript prolog to modify the conversion process.
Mako 5.2.0 introduces the IDistiller() class to overcome these limitations. Designed as a replacement for PDFLib, testing has shown up a significant speed improvement over the previous conversion route, matching or in many cases improving on the PDFLib performance.
Fuller documentation of the new class can be found on the Mako documentation site:
Add support for IDistiller::setProlog()
An API to load a PostScript prolog, PostScript code that is executed before parsing of the input file begins. This example loads a prolog from a local file, prolog.ps:
IDistillerPtr distiller = IDistiller::create(jawsMako) distiller->setProlog(setProlog(IInputStream::createFromFile(jawsMako, "prolog.ps"));
Add support for IDistiller::setEpilog()
Similar to a prolog, an epilog is executed after parsing of the main file has completed.
Add support to IDistiller for PANOSE matching
PANOSE was an early standard for mapping unavailable fonts to a suitable alternative. It is available in PDFLib and is implemented in IDistiller()
Add new class enabling fonts to be installed permanently to disk
A feature of PDFLib allows fonts to be installed from disk and to be made available to subsequent PostScript conversions. This work replicates that capability in Mako’s IDistiller() implementation.
Create a testpdflibcmd.exe equivalent for IDistiller()
PDFLib comes with a sample command-line application, testpdflibcmd, that provides a convenient method for exercising PDFLib without the need to write code.
Mako provides an equivalent, MakoDistillerCmd, that supports the same command-line options and many of the arguments that can be added to a control file (usually referred to as an args file). In most cases it can replace testlibpdfcmd in a script or batch file.
MakoDistillerCmd is supplied as sample code. Source code can be found on the developer pages referenced above. A ready-built version is included with the Mako SDK.
Prototype feature: IJPDS support
IJPDS implementation - Create a skeleton parser
IJPDS (Inkjet Printer Data Stream) is a format developed by Kodak for input to their Versamark printing systems. In this release we have included a prototype of a new input, IIJPDSInput() to enable conversion of this format to PDF and other supported PDLs.
This is a new feature that is in the early stages of development. As such its testing has been confined to a small number of input files. It is included in Mako 5.2.0 to facilitate evaluation by interested Mako developers, who do so at their own risk. It will be developed into a mature feature in subsequent releases of Mako.
Dash is lost after converting text
Found during testing. Linjoin/linecaps properties not forwarded correctly. Now fixed.
Inconsistent hashing of screened images caused a unit test failure. Now fixed.
Other New or Improved Features
SWIG: Support Custom Transforms
Support for custom transforms in C# was absent from the implementation in Mako 5.1. It is now supported.
Crash caused by corrupt data stream in JPEG2000
Fixed in Mako by porting a fix from Mako Jaws RIP to gracefully handle an error in the encoding of a JPEG2000 image.
Exception during PDF to PDF processing of veraPDF test suite file (6-2-5-t03-fail-a.pdf)
Caused by insufficient checking of the data type. Now fixed.
Set internal renderer to run in 16-bit to improve accuracy of component values required for transparency blending
The need for this change was uncovered during routine testing, to improve the rendering of ColorDodge and ColorBurn blend modes.
Implement a better solution for handling CFF fonts with non-standard FontMatrices in PDF input and XPS/SVG output
In Mako’s PDF input, when a CFF font containing a non-standard CFF font matrix is encountered, it adjusts the font to have a standard CFF font matrix and adjusts the DOM to suit. This was to overcome what is now a very old Windows font system problem but causes problems in other contexts.
This work removes the font manipulation on input and deals with the issue, via a transform, before outputting to formats such as XPS and SVG. This transform is also available externally should it be required by a Mako developer.
Populate print ticket entries from PostScript setPageDevice declarations
When parsing PCL5 or PXL/XL file streams, Mako populates print tickets to persist job information such as numbers of copies, duplex printing etc. A fuller explanation can be found on this documentation page:
Mako 5.2.0 introduces the same concept for PostScript. Currently it only supports an IDocumentAssembly-level ticket for the number of copies, derived from this PostScript generated by an HP PostScript printer driver:
%%BeginNonPPDFeature: NumCopies 3
This capability will be expanded in future releases of Mako.
Linked to the developer page is a code sample that can automatically recognise the language of a PJL-prefixed print job, based on the @PJL ENTER LANGUAGE=… statement and switch to the correct parser. It also demonstrates the use of Mako print tickets. This is that link:
PostScript parsing error
This issue was triggered by the presence of Adobe TBCP (tagged binary communications protocol) characters in the PostScript stream. Sample code was developed that intercepts these characters enabling the PostScript parser to complete normally. The code can be found here: https://gist.github.com/mako-sdk/d471cd43c882fbfe3a87c25a6977d2c6
Prevent IPSInput() from downsampling images
Automatic downsampling to 288dpi is disabled by default and can be controlled via an API.
Incorrect output for a shading case in the Ghent GWG tests with overprint simulation
A fix to the overprint simulation transform to ensure correct rendering of Ghent Working Group print examples.
Support requests fixed
(Mako Support Request #10371) Kerning Issue
The customer reported that text is moving very slightly after processing PDF to PDF with Mako. The problem was found to be the outputting of kerning parameters. Kerning parameters are expressed in PDF in thousandths of text units but Mako was rounding these to integral quantities.
This change allows an extra two floating point digits for:
Now fixed and extensive regression testing proves that the problem is solved.
(Mako Support Request #10372) Color difference issue
If an input PDF page contains a transparency page group, Mako does not emit a page group in an output PDF unless it detects that the page contains transparency. In this instance the input page has a CMYK page group, but no transparency for that page. Had the original page group been present, the renderer would have converted the content to CMYK before converting back to RGB. Without it, it simply paints RGB, causing the rendering difference.
Since the absence of the page group is the reason the results render differently, a new option is provided for PDF output (IPDFOutput::setForceEmitPageGroup()) that can be set to true to prevent color differences of this type from occurring. It can be set by either of these methods. Assuming:
It’s safe to use at all times (and may be made the default rendering behavior in future Mako versions). The sample makoconverter allows this parameter to be set on the command line.
(Mako Support Request #10389) Mako color issue
A minor rendering issue was corrected by this fix.
(Mako Support Request #10391) Dotted path offset
This issue was triggered by an output optimisation intended to reduce the possibility of identical paths being written multiple times. In this case it had a side effect of changing the way a dashed line was written, whose appearance is dependent on start point and direction. Now fixed.
(Mako Support Request #10396) RE: Sigkill
This job was poorly constructed, with a number of patterns that each contained a ~30MB image that exhausted display list memory allocated for patterns. The introduction of an environment variable allows this limit to be changed:
Setting to 10MB solved the problem, improving processing time and reducing memory consumption.
(Mako Support Request #10402) Part of image missing
The job had a non-zero MediaBox that led to incorrect positioning of a pattern. Now fixed.
(Mako Support Request #10406) Ps undefined error
This issue was triggered by an indirect reference to a color space array which is not expected. Now fixed.
(Mako Support Request #10424) Missing image with signature issues
This issue was triggered by a PDF form (XObject) containing an image that is used multiple times. Subsequent instances incorrectly inherit a clipping path setting that renders it invisible when it should not be. Now fixed.
(Mako Support Request #10426) Mako evaluation issue
An incorrectly formed PCL/XL file triggered an arithmetic overflow. Bounds checking was added to enable the job to complete and produce output.
(Mako Support Request #10432) Add support for 16-bit anti-aliased output to IJawsRenderer::renderSeparations() method
Sixteen-bit, anti-aliased rendering is now available from this API, producing high-quality renditions even at low resolutions.
(Mako Support Request #10434) Issue with PCL to PDF conversion
This issue triggered an exception in Mako’s PCL5 input parser, “PCL5 Processing Error: Unexpected stable font…”. Now fixed.
(Mako Support Request #10454) PDF parsing issue
This issue was triggered by incorrect handling of a CFF (Compact Font Format) font in the PDF. Now fixed.
8-bit rendering issues in Mako
While testing fixes to some 16-bit rendering issues some 8-bit rendering issues were uncovered. Now fixed.
16-bit rendering issues in Mako
Quality issues affecting 16-bit rendering were fixed.
PCL file 94.jb2 causes Makoconverter to silently quit
This problem was solved by unrelated work to improve PCL ROP (Raster Operations) performance.
An image object with an imagemask is treated as opaque, not transparent
An issue with a PowerPoint-originated file and seen only when rendering to RGB, is now fixed.
Spacing incorrect when setting locale to de-DE
The issue was caused because code to convert a string to a floating-point number was not taking the locale into account and in this case not interpreting a comma as a decimal separator. Now fixed.
PCL5 & PCL/XL improvements
The following are a list of customer-supplied PCL5 test files that caused problems in earlier versions of Mako. All were tested in this release and are producing the correct output.
Bad arguments error when processing
Line spacing incorrect when processing
Additional page output when processing
Undefined error when processing
Incorrect output when processing
2.jb2 and 74.jb2
Missing text when processing
Grid lines are too dark when processing
Vertical lines in table missing or incorrect when processing
PCL5 test file 106.jb2
Objects incorrectly placed when processing
Mako Version 5.2.0 is built for the following platforms:
- Linux (for Debian-based distributions, eg Ubuntu, Mint)
- Linux (Centos)
- Linux (for Debian Stretch)
- Linux (for MUSL distributions, eg Alpine Linux)
- Windows (static and non-static libs, VS 2019 (V142) x64 only)
- Windows (static and non-static, VS2015 (V140), x86 and x64)
- Windows UWP (Store apps, Windows 10 IoT)