Mako 5.1.0 Release Notes

New and Improved Features

MAKO-1470   Expanded bindings: C#

The headline feature for Mako 5.1 is the full release of a C# API for Mako. Implemented using SWIG (Simplified Wrapper and Interface Generator), each C++ class and method has a C# equivalent.

Consider this PDF to XPS converter example:

All the simpleexamples are available as C# projects, for use on Windows, macOS and Linux.

A NuGet package is available for Windows, to be used with Visual Studio 2019. See this guide on the developer pages.

MAKO-2195   Implement performance and memory use improvements for PCL5 input

Also relevant to MAKO-2236: (Mako Support Request #10356) PCL file examples

In this release we took a close look at the factors that impact performance of PCL5 input, focusing on:

• File access
• Memory management
• ROPs (raster operations)
• Other performance wins

File access: A new buffering scheme is applied to CFileStream on Windows. This was a port from Linux (and macOS) where it had already been implemented and makes a significant difference to PCL processing where a lot of small reads are involved.

Memory management: A memory leak discovered in the PCL parser’s tracked memory management has been fixed, but the significant change is the introduction of IInput::setSequentialMode(). When enabled, it allows Mako to discard the DOM (document object model) of pages that have been requested and throw an exception for cases where an attempt is made to re-request a page. The documentation for the new API describes how to best make use of it. In the standard example, makoconverter, this option is turned on as we know that a previous page will not be re-requested. It applies equally well to an analyser use case.

ROPs: Raster operations, the means by which PCL enables one element to be blended with another, are expensive to process and when there are thousands of them, can really slow a job down. However, if the purpose of the processing was, for example, simply detecting whether a page is black and white or color, the ROP does not affect this. While it is possible that an RGB ROP operation can result in a grey output, it is incredibly unlikely in practice. But a grey ROP can never result in a colour result. So, with care, it’s possible to ignore ROPs.

A new API, IPCL5Input::setFlattenRops(), is introduced with a default of true. When set to false, ROPs are not processed. The API documentation gives details of how the ROP is represented in the DOM if this is set.

Other performance wins:

• Stubs are added to the Type 3 transform in PCL5 input. Adding these stubs ensures that the underlying custom transform mechanisms do not have to recurse into irrelevant places. This provides a welcome, if modest, performance improvement.
• A fast compression (LZ4) is now applied to received image data. In the customer case this means avoiding having to create temporary data on disk, improving performance. LZ4 is very fast and provides decent compression. To enable this feature, a new IOutputStream argument is added: IOutputStream::createToLz4Compressed() so that LZ4 data may be written to an already open file.

MAKO-2213   Add support for user-defined PostScript Prolog to Mako

A new API, IPSInput::setProlog(), allows an additional stream to be specified that will be processed before Mako begins processing the main PostScript job.

MAKO-2115   (Mako Support Request #10252) XPS Printing

In a PDF to XPS conversion workflow that subsequently used the XPS as a source for printing, two changes were made to overcome identified downstream processing problems.

The first issue was that jobs failed when multiple fonts had the same font names. Uniquely named fonts is not a requirement of XPS – the specification says nothing about it – but the workaround described was effective in this case. A new API, IXPSOutput::setRenameFonts(), will uniquely name all fonts used in the XPS produced by Mako, using a prefix of randomly chosen characters.

The second issue was with disappearing glyphs, which seemed to revolve around xml-escaped Unicode values in UnicodeStrings. The workaround is a new parameter that can only be set with IXPSOutput::setParameter(). This is StripUnicode(), which if set to true will remove all Unicode strings from the emitted XPS. Instead, explicit glyph IDs will be used.

Both of these new parameters are described on the XPS Output Parameter documentation page.

MAKO-2141   (Mako Support Request #10328) Support for Debian Stretch

As long-term support for Debian Jessie has ended, this build has been removed. A new Linux build has been added for Debian Stretch. The GCC version is 6.3.0.

MAKO-2153   (Mako Support Request #10358) Ref counts

An API has been added to assist debugging of object reference counting. Use as follows:

int32 refCount = object->getRefCount();

MAKO-2163   Add support to recognise @PJL ENTER LANGUAGE=POSTSCRIPT

PostScript jobs intended for printing on devices that support both PCL and PostScript may have a PJL preamble. This work ensures that PJL at the start of a PostScript job will be processed (and the print tickets appropriately populated) then switch to parsing PostScript when the @PJL ENTER LANGUAGE=POSTSCRIPT command is encountered. The work adds IPJLParser::ePREnterPs to the PJL parser

MAKO-2149   Remap littlecms symbols

Mako implements its color management module (CMM) with littlecms. This interfered with a customer’s separate use of the same library, so we now ensure we no longer export the littlecms symbols when building Mako.

Support requests

MAKO-1999   (Mako Support Request #10321) FW: PDF render raster issue

The root of this problem lay in the complex interplay between the active graphics state, PDF form (XObject) processing and the caching of said forms. Now fixed.

MAKO-2008   (Mako Support Request #10330) Letter jumps after processing with mako

Width and kerning values were coming from mixed sources leading to this prob

MAKO-2110   (Mako Support Request #10331) PDF issues (file 1)

Fixed in Mako’s TrueType interpreter. A broken PDF contained a font with a NPUSHW instruction that attempted to write past the end of the stack, which was not being caught correctly. Now fixed.

MAKO-2128   (Mako Support Request #10331) PDF issues (file 2)

The job contains a font that uses the old, deprecated SEAC form of the Type 2 endchar operator. Mako has code to deal with this, but not in the circumstances of this job. Now fixed.

MAKO-2130   (Mako Support Request #10331) PDF issues (file 4)

The job contained an /Info entry that pointed to something other than /Info dictionary. Mako will now ignore any /Info entry that is not a dictionary.

MAKO-2280   (Mako Support Request #10339) Mako missing special characters or emojis

This issue concerns fonts that have marking glyphs in the notdef position in the font. Normally these are blank or a small rectangle, but occasionally font designers put a special character in that position, in this case an emoji. Depending on the font type, the glyph at the notdef position may get ignored. To solve this case, when writing PDF, Mako will now ensure TrueType fonts that have marking notdef glyphs that were CID (character ID) in the input are also CID in the output.

MAKO-2079   (Mako Support Request #10341) Memory not being freed for PDF

The cause of the excessive memory usage was due to the use in the job of a large number of PDF XObjects, created to facilitate the reuse of pages. Prevously, Mako’s IPDFInput kept a register of all IDOMForms created for all PDF XObjects, leading in this case to excessive memory usage. Rather than simply hold on to these forms, the solution is to introduce a cache.

This change adds the ability to specify an environment variable, J3_PDF_FORMCACHE_COUNT, (minimum value of 2, default 500) to set the number of forms to cache. The default will be ample for most jobs.

MAKO-2138   (Mako Support Request #10344) Mako file having difference in square root thickness and adding characters

This issue was traced to a problem with graphics state (gstate) synchronization, the consequence of which was that a line appears thinner and fainter than it should after incorrectly inheriting a transparency state. Now fixed.

MAKO-2084   (Mako Support Request #10345) configuration on RAM

To improve processing time for a 933MB, 90094-page PDF with unusual construction (a lot of forms (XObjects) specified per page, most of which go unused) some resource and memory management improvements were added. A resource dictionary cache (consulted when a form is referenced) can now be expanded from its default size of 100 entries by setting an environment variable beforehand:

MAKO_PDF_DICTCACHE_COUNT=20000

A value of 20,000 was effective for the customer’s job.

The improvement to the memory allocation mechanism is internal and automatic, ie does not require any external setting to make it active.

It was also noted that because the output PDF version was set to PDF/X-1a, flattening of transparency and color conversion of images is required. To improve the performance of the output, an enhanced makoconverter was developed that uses a custom transform to flatten transparency and convert colors immediately, rather than deferring the processing until the PDF is written. This reduces the time it takes to write the PDF by preventing repetitive image resampling that was occurring in this case.

The combination of the improvements halved the processing time for this use case.

Although the makoconverter code was written with this use case in mind, it can be applied to others so we have made this available here on GitHub.

MAKO-2092   (Mako Support Request #10346) Mako Rip Times -

Time-critical monochrome RIP performance was impaired by (unnecessary) color correction. Now off by default. Testing shows RIP performance has been restored.

MAKO-2238   (Mako Support Request #10373) Path thickness issue

This issue was caused by a gstate (graphics state) syncing issue, resulting in the wrong stroke thickness being set. Now fixed.

MAKO-2210   (Mako Support Request #10374) OffendingCommand: @PDFopexec

This issue relates to forms (PDF XObject) where the color is set from outside the form, made more complicated in this case because the graphic was a colored tiling pattern that did not set a stroke color. Now fixed by ensuring graphic state (gstate) information is forwarded to the form instance at the correct time.

Also found was invalid nesting of BDC/EMC (Begin/end marked-content sequence) and gsave/grestore pairs. Strictly speaking illegal but Acrobat tolerates, now Mako does too.

MAKO-2295   (Mako Support Request #10376) PDFs failing to process

An oddly constructed PDF triggered Mako to expand an abbreviated PDF key inappropriately, defeating later processing. Now fixed.

MAKO-2227   (Mako Support Request #10378) Re: Issue with diagrams

A drawing issue triggered by incorrect handling of patterns. Now fixed.

MAKO-2277   (Mako Support Request #10380) Background Issue

The difference in rendering that the customer observed is related to tiling type. While it makes no difference to how Acrobat renders a pattern, it certainly does to Mako (Jaws) rendering. The difference between TilingType 2 and TilingType 3 maybe quite marked at low resolutions. The fix is to modify the writing of tiling patterns to preserve the tiling type, where previously Mako would always set TilingType 2.

MAKO-2239   (Mako Support Request #10382) Incorrect rendering

An unusual combination of DeviceN and Indexed color spaces led to content being rendered incorrectly. Now fixed, with additional remedial work to improve ICC Lab profile handling.

MAKO-2266   (Mako Support Request #10386) Set locale to DE causing RIP error

Code to parse a number was not taking account of the locale correctly. Simple to fix but additional work was required as the solution varied between Windows, macOS and Linux.

MAKO-2278   (Mako Support Request #10387) Font Error

This job is rather poorly generated. It has fonts which identify as CIDFontType2 (Character ID TrueType) but are really OpenType containing regular (not even CID) CFF fonts. The fix is an improvement to consider the FontMatrix when a regular CFF is used and a CID/CFF is expected. This ensures the glyphs are scaled correctly.

MAKO-2279   (Mako Support Request #10388) Background disappearance

This problem was caused by a pattern with an excessively large offset, which calculates out to 50m. This exceeds a built-in limit and the content is dropped. The fix is to perform an additional test and make the necessary adjustment to bring the content back on to the page.

MAKO-2269   (Mako Support Request #10390) Mako heap corruption error

An issue that only arises on 64-bit had previously been fixed in Jaws RIP. Now applied to Mako’s equivalent section of code.

MAKO-2306   Incorrect spacing of plus and minus symbols following inferior glyphs

Spotted during testing, a regression was triggered by another change to ensure Type11 fonts remained as CID fonts rather than being converted to Type42, with the consequence that space characters were treated differently. Now fixed.

MAKO-1185   Makoconverter does not finish processing test file PCL5Japan.sqjob

Changes to the PCL parser were made in Mako 5.1 to solve this problem and to improve performance.

MAKO-2010   Altona - CMYK overprinting issue on Page 15

Ensure Mako renders this test element from ECI’s Altona Test Suite correctly.

MAKO-2018   Softmask is not rendered (smask.pdf)

This issue was found during testing and fixed.

MAKO-2050   QualityLogic test file CATX0627.pdf fails VeraPDF compliance check when converted to PDF/A-1b

The non-compliance reported was the inclusion of OPI in the output which is forbidden in PDF/A-1b. Not all compliance checkers report this as an issue, but VeraPDF does. Now fixed by omitting OPI from the output.

MAKO-2064   The simple example separatedrenderaa throws when processing > 32 spot colors

A sample PDF with 36 spot colors exceeded an internal limit of 28. The limit has been raised to 252 spot colors.

MAKO-2070   Text over italicized when converting PDF to PDF on Linux.

This issue arose because in some circumstances, a non-oblique version of a font is slanted by the application of an appropriate font matrix rather than using an italic font. In this instance both the italic font and the font matrix were used, resulting in over italicization. Now fixed.

MAKO-2086   Fix identified overprint issues

An issue with graphics state (gstate) synchronization, causing a line to appear fainter than it should, was found and fixed

MAKO-2105   A non-string producer in a PDF will throw an exception in Mako

A metadata field referenced non-text characters, causing Mako to throw an exception. Now caught correctly so that processing is not interrupted.

MAKO-2154   Cannot open read-only file as an EDLIFStream with default constructor

EDLIFStream's default construction opens a file with a mode of std::ios_base::out, which will fail if the file to open is read-only, even though we only need to read from it. Now fixed.

MAKO-2247   Rendering error

When rendering separations at high resolution, some bands of a spot color separation were missing leading to unwanted color changes. Now fixed.

MAKO-2259   Internal RIP error: VM error

Root cause was a misplaced semicolon after an if() statement. Now fixed.

MAKO-2287   Error when converting PCL5 files to PDF/A-2b and PDF/X-4

The problem occurred due to an issue in the page caching mechanism, triggered because converting to these PDF standards required a page to be fetched twice. The fix involved solving the immediate issue, as well as removing the need to fetch the page more than once.

MAKO-2302   More reliably handle glyph ID 0 when writing CID fonts to PDF/A-2b and PDF/X-4

Improvements made elsewhere had the unintended consequence of invalidating PDF/A and PDF/X output for certain jobs, the standards for which demand that a font’s NotDef glyph should not be referenced. This change addresses this problem.

Distribution

Mako Version 5.1 is built for the following platforms:

• Android
• iOS
• Linux (for Debian-based distributions, eg Ubuntu, Mint)
• Linux (Centos)
• Linux (for Debian Stretch)
• Linux (for MUSL distributions, eg Alpine Linux)
• macOS
• 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)