Mako 7.3.0 Release Notes

Introduction

As usual, this Mako release is a mixture of new features and fixes.

• A new class, IPDFValidator, introduces a means to check the conformance to a PDF ISO standard (PDF/X-1a)

• New APIs to allow a PDF to be “rolled back” to an earlier, incrementally saved version

• A new rendering API to render separations directly to a frame buffer

• A new input class, IPRNInput, simplifies processing PJL-wrapped PCL5, PCL/XL, PostScript and PDF

• Incremental improvements to the ILayout class, to control letter spacing and simplify adding text

• A new API to draw a polygon

New features and improvements

MAKO-4685   PDF/X conformance check - sample code

A user request led to this new feature. Building on Mako’s capability to automatically reconfigure a PDF to meet the PDF/X-1a ISO standard, Mako is now able to report which aspects of a PDF pass or fail the standard. A new simpleexample is included in the MakoApps folder of the distribution that shows how to use the new class, IPDFValidator. The sample (pdfvalidation.cpp) not only produces a PDF report (using the ILayoutclass), but it also copies pages from the file under test, adding relevant comments adjacent to the page element that fails validation.

Similar support for PDF/X-4 will follow in a future release.

MAKO-4729   Incremental save rollback

Mako’s support for PDF’s incremental save feature is extended in this release with new IPDFInput methods that report on the number of incremental saves available, and to choose which of these are loaded as an assembly.

• Each API function has variants that will take a IInputStream, U8String or String.

• Incremental saves are added in order of the last save. For example, to obtain the PDF as it was before the last save, use:

  • openIncremental(filename.pdf, 0)

  • or use the first element in the array returned by getIncrementalSaves()

Further documentation and sample code can be found here.

MAKO-4633 IJawsRenderer::renderSeparationsToFrameBuffers()

This requirement arose during a discussion with a customer, who wished to access a separation raster data directly, rather than having to unpack an IDOMImage. As Mako already offers renderToFrameBuffer() and renderSeparations(), this is a straightforward change.

This knowledge base article provides some additional details and the new API is fully described in the API documentation. Use the Search box to look for IJawsRenderer.

MAKO-3579   Support .PRN files as input file type in MAKO

A new input class, IPRNInput, is introduced in this release. It is designed to simplify processing files without a meaningful file extension such as .PRN or .BIN. Typically produced by a print driver, such files consist of a PJL wrapper with one or more documents in an arbitrary PDL, preceded by an ENTER LANGUAGE tag. IPRNInput can handle embedded PCL5, PCL/XL, PostScript and PDF.

Previously we provided sample code to demonstrate how to accomplish this task - see https://gist.github.com/mako-team/d471cd43c882fbfe3a87c25a6977d2c6

This new class greatly simplifies building solutions requiring this approach. You can see an example of its implementation in makoconverter, the code sample that ships with the SDK.

MAKO-4773   Add IDOMPathGeometry::createPolygon() method

An additional API is added for drawing polygons with a given number of sides and initial angle. For example, this code will draw a black hexagon:

const auto black = IDOMSolidColorBrush::createSolidCmyk(mako, 0.0, 0.0, 0.0, 1.0);
const auto box = FRect(0.0, 0.0, 96.0, 96.0);
fixedPage->appendChild(IDOMPathNode::createStroked(mako, IDOMPathGeometry::createPolygon(mako, box, 6), black));

MAKO-4760   Prototype opening a 7C TIFF

Sample code is provided here for opening a TIFF with more than 4 color channels, for example a 7-color CMYKOGV TIFF. This works by supporting the TIFF PHOTOSHOP tags that define the extra channels, by using LibTIFF.

A future release of Mako will support this directly in the IDOMTIFFImage input class.

Support issues

Solutions for specific support issues included in this release are labelled MAKOSUP-XXXXX. The link is live and can be followed to the Mako support portal, but work only for the customer who reported it.

MAKO-4748   MAKOSUP-11332 ILayoutTextRun letter spacing

ILayoutTextRun()now takes an optional letter spacing argument, where the value is in terms of em. A positive value adds letter spacing, e.g 0.6 spreads out text by adding 0.6 em to the default spacing, whereas -0.6 would condense text by reducing letterspace by that amount.

Additionally, a more convenient method for creating a single ILayoutTextRun is added in this release. See this documentation page for further details.

MAKO-4768   MAKOSUP-11349 PCL/XL job crashes

The customer exhibit was missing data. Although there was a UEL (Universal End of Language) marker at the end, the PCL/XL stream was truncated, and caused Mako’s parser to fail. The fix required an additional EOF check so that such a job will cause an exception to be thrown that can be caught.

MAKO-4775   MAKOSUP-11354 Missing fonts in the document converted from XPS to PDF

This was caused by a font processing error that is now fixed.

MAKO-4795   MAKOSUP-11356 glyphsNode->getUnicodeString(); returns Garbage for a specific PDF

For this issue we have made Mako behave as Acrobat would, when dealing with a font in the customer job that does not conform to the PDF specification.

MAKO-4821   MAKOSUP-11362 & MAKOSUP-11370  Exception Failed to unpack cmap table

To solve these issues, a minor change is made to Mako’s OpenType font handling, to add support for an additional platform type in the TrueType CMap table.

MAKO-4823   MAKOSUP-11363 Simulate overprint does not work as expected

Two overprint simulation issues were reported. Now fixed.

MAKO-4824   MAKOSUP-11365 Embedded SVG font results in unspecific message

This was not, as the support issue suggests, anything to do with SVG fonts, but an issue with a Type 3 font in a PDF. Now fixed.

MAKO-4828   MAKOSUP-11368 Excessive scanPdfForInks scan times

A 39,000 page PDF with a flat page tree (a single-level array for all pages) punished the IPDFInput::scanForInks() method as it fetched a page reference for each page processed, becoming progressively slower as it processed the file. A change to this method restores the usual performance.

MAKO-4830   MAKOSUP-11375 PCL5 to PDF conversion - Text vertical position shifted down

The order of PCL operators caused Mako to incorrectly position text, vertically. Now fixed.

MAKO-4860   MAKOSUP-11393 MAKO 7.2.0 - Rasterizing pdf to image is blank page

This appeared to occur only at low resolution, which gave a clue as to what was going wrong. Now fixed.

MAKO-4769   MAKOSUP-11339 Compiler error: Unterminated C++ character

An unused #DEFINE that was causing a problem is now removed.

MAKO-4851   MAKOSUP-11383 IDistiller cannot suppress /ViewerPreferences

Prior to this release, the IDistiller class would always include a ViewerPreferences dictionary in the catalog when writing a PDF, without providing a mechanism for suppressing this behavior should that be needed. With this change, IDistiller will no longer emit this dictionary by default, and a new distillerparam is added to control this behavior explicitly:

<</EmitViewerPreferences true>> setdistillerparams

In this case to switch the feature on.

Other improvements

MAKO-4817   Add support for vector object when creating CColorantInfo

Previously, Mako allowed variable arguments to pass the component values to CColorantInfo. This is unsafe as the number of components may not match the actual number of components passed in; a safer way is to support std::initializer_list.

An invocation like

IDOMColorSpaceDeviceN::CColorantInfo ("Foo", 4, 0.8, 1.0, 0.1, 0.3);

is replaced by

IDOMColorSpaceDeviceN::CColorantInfo ("Foo", { 0.8, 1.0, 0.1, 0.3 });

where the number of components is implied in the list.

Those making use of this class may find that this is a breaking change.

MAKO-4847   Type3 scaler transform in the PCL5 parser caching improvements

This issue is one of several improvements to the PCL parsers (both PCL5 & PCL/XL) intended to reduce memory consumption and improve performance. These will be introduced in this release (Mako 7.3.0) and the next (Mako 7.4.0).

Profiling revealed that the scaler transform, part of the PCL5 parser, uses too much memory. This change implements two improvements that can dramatically reduce memory consumption, particularly for high page count / high font usage PCL5 input.

MAKO-4850   Add setFlattenRops() for PCL/XL input

This is another of the improvements to the PCL & PCL/XL interpreters that reduce memory consumption and improve performance.

MAKO-4845   Add a colour and solid color brush cache to PCL5 input

This is the third of several improvements to the PCL & PCL/XL interpreters intended to reduce memory consumption and improve performance.

MAKO-4799   Improve Mako compatibility with MFC

Until now, when using Mako in an MFC project, normal debugging was not possible, as MFC remaps the new operator in a way that was incompatible with Mako. With this release, we have solved this problem and the regular MFC debugging is now possible without the need for any workarounds.

MAKO-4792   FRect, FPoint, FMatrix copy constructors

In C++ you can use the following code to create an FRect and a copy thereof:

FRect myBox = FRect(0.0, 0.0, 100.0, 100.0);
FRect myBoxCopy = myBox;

myBoxCopy will be independent of myBox, meaning that changes to it will have no impact on the values of myBox.

If you do the same in C#, the behavior is slightly different.

FRect myBox = new FRect(0.0, 0.0, 100.0, 100.0);
FRect myBoxCopy = myBox;

In this case, myBoxCopy is simply a pointer to myBox, meaning that changes to it will also change the values of myBox.

To solve this, a copy constructor is added.

FRect myBox = new FRect(0.0, 0.0, 100.0, 100.0);
FRect myBoxCopy = new FRect(myBox);

This will make an independent copy. The same is available in C++ too:

FRect myBoxCopy = FRect(myBox);

The copy constructors are available to the related structs, FBox, FPoint and FMatrix.

MAKO-4818   Add IJawsRenderer::render::maskToInterestingNodes() to the docs

Documentation for this API was previously missing for this IJawsRenderer flag.

MAKO-4800   Inconsistent behaviour of incremental vs. non-incremental save of OCG changes

This issue affecting changes to OCGs (aka layers in PDF) which was discovered during routine testing, is fixed in this release.

MAKO-4853   Overprinting anomaly when rendering to RGB

Routine testing revealed incorrect overprinting behavior when rendering a GWG (Ghent Workgroup) example to RGB. The PDF specification is that overprint mode does not apply if the device's native color space is not DeviceCMYK. Now corrected.

MAKO-4837   Internal RIP error: PS rangecheck error: with IDistiller

An improvement to IDistiller is made to ensure embedded PJL commands, even when very long (>255 characters) are correctly skipped.

MAKO-4749   Better locking and caching in Mako’s FreeType interface

This improvement improved performance for a test case when rendering in multiple threads.

MAKO-4835   Resolving page references for PDF page trees with large Kids arrays.

Following on from MAKO-4828, a generalised solution to improve performance when resolving page references for a PDF with a flat page tree (single-level array for all pages) is implemented by this change.

It should also be noted that Mako will always write a balanced page tree, so opening and saving such a PDF with Mako will “fix” a bad page table.

Distribution

MAKO Version 7.3.0 is built for the following platforms:

• iOS

• macOS

• Linux (for Debian-based distributions, eg Ubuntu 22.04 LTS, Mint)

• Linux (for Debian Bullseye)

• Linux (for Debian Buster)

• Linux (for Alpine Linux v3.17)

• Linux (Centos)

• Linux (Red Hat Enterprise v7.0)

• Linux (Red Hat Enterprise v8.4)

• Linux (for Debian Buster) (arm32v7 for Raspberry Pi)

• Linux (for Debian Bullseye) (arm64v8 for Raspberry Pi)

• Windows (static and dynamic libs, VS 2019 (V142), x86, x64 and ARM64)

• Windows (static and dynamic libs, VS 2017 (V141), x64)

• Windows UWP/WinRT

The Android build is excluded from this release. Contact MAKO support if you need MAKO for Android.

MAKO supports the following programming languages.

• C++ (MAKO is written in C++)

• C# (.Net Core (multiple platforms) and .Net Framework (Windows only))

• Java (built with OpenJDK11 and therefore compatible with later versions.)

• Python (v3.8 / 3.9)

The alternatives to C++ are built using SWIG (http://www.swig.org ) which provides a translation to the native libraries. They found in these distribution folders, found in the SWIG folder:

• Linux_SWIG_(C#-Java-Python)

• Linux_Centos7_SWIG_(C#-Java-Python)

• Linux_Centos8_SWIG_(C#-Java-Python)

• Linux_Ubuntu_SWIG_(C#-Java-Python)

• macOS_SWIG_(C#-Java-Python)

• Windows_SWIG_(C#-Java-Python)

Cross-platform Java build

The folder SWIG/CrossPlatformJAR contains Java builds that combine the implementations for multiple platforms into a single JAR package, thereby simplifying deployment. The folder contains two combinations, one for Windows & Linux and another for Windows, Linux and macOS. A pre-built sample app (MAKOconverter.jar) is included.

ColorLogic

MAKO is available with the ColorLogic CMM, supplied by our Hybrid Group sister company, ColorLogic Gmbh. All builds can be found in the ColorLogic folder. C++ builds are available for Windows, macOS and Linux, and there is also a Windows SWIG build for development with C#, Java or Python that uses the ColorLogic CMM.