Mako 8.0.0 Release Notes

Introduction

Mako 8.0.0 earns its major version increment because it includes APIs for Apex, announced alongside this release. Apex is GPU-native rendering, a new technology that dramatically accelerates rasterization of complex, transparency-laden PDF, and will render any Mako-supported PDL.

The new IApexRenderer class headers are included in Mako 8.0, but the Apex library itself is not a part of the regular Mako distribution, and only available to Mako licensees that extend their Mako agreement to include Apex

Users of the Mako Core SDK will be the first Global Graphics customers that will be able to license this new technology for use in their own developments. Ready-built sample applications built with Apex are available to Mako licensees to help them evaulate Apex.

Otherwise, this release of Mako is focused mainly on customer 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.

Issues addressed

MAKO-5051 MAKOSUP-11448 Handling of Prescribe commands in PCL6 / PS

Changes to allow Mako to handle Kyocera PRESCRIBE commands within PCL6 / PostScript streams.

MAKO-5085 MAKOSUP-11452 Retrieve Encoding of a Font

A new feature makes it possible to retrieve the encoding for fonts found using IPDFInput::scanPdfForFonts()in a manner that is similar to the way that Acrobat reports font encoding.

Mako stores the encoding as a string in the font information, reporting the Encoding as described in the PDF reference, that is, for simple fonts:

An Encoding name of MacRomanEncoding, MacExpertEncoding or WinAnsiEncoding are allowed.

Mako will throw an exception if any other name is encountered.

If the Encoding is a dictionary and contains a /Differenceskey, then Custom is reported, regardless of the BaseEncoding
If there is no Encoding (valid for simple fonts), StandardEncoding is reported for non-symbolic fonts, and Built-in for symbolic fonts.
For composite fonts, either the name of the predefined CMap will be reported, or Custom if the font uses an embedded CMap stream.

MAKO-5086 MAKOSUP-10923 Determine if a Color channel is used

A customer asked: “How can we determine if a process color channel is used on a page?” This sample shows an efficient way to do this.

MAKO-5112 MAKOSUP-11498 Missing setting for TU entry for Widget

Add support for alternate field names to IWidgetAnnotation /IFormField. Specifying an alternate name when creating widgets, or setting with setAlternateName() adds a /TU entry to the appropriate dictionary. Acrobat uses this to display a tooltip when the mouse is hovered over a widget.

MAKO-5160 ILayout: Recognise a break character to jump to the next frame

This is a new ILayout feature. It adds two ways of breaking a run so that it “jumps” to the next frame. There two ways to do this; the first method is to add a form feed character to a text run, for example:

CODE

ILayoutTextRunPtr textRun = ILayoutTextRun::create("Before break\fAfter break", font, fontSize);

Assuming there are two or more frames already created, this code will create a text run that would layout text into two frames.

The second method is a new API, ILayoutParagraph::addBreak(). This makes it possible to break after image runs.

MAKO-5161 MAKOSUP-11477 PDF/X-4 is not compliant according to callas PDF Toolbox

Two small changes, neither of which were relevant to output quality (for example, one was to add seconds to Create and Modify dates in the PDF’s metadata), ensure the preflighter passes PDFs saved with Mako’s PDF/X-4 preset.

MAKO-5178 Extraneous pixels in vector path scan conversion

A PDF job with a curved stroke in black had a thinner white stroke either side, the intention being to ensure a smooth edge to the black path. At low resolution, the scan conversion resulted in “orphan” black pixels where the white stroke did not fully cover the edge of the black. This is now fixed, and has been found to be a general rendering improvement.

MAKO-5180 Defer decoding Embedded File streams in PDF

To improve performance when a PDF has either a large quantity of attachments, or when those attachments are large files, Mako now defers decoding those attachments until the data is called upon.

MAKO-5241 MAKOSUP-11552 PDF with selected image format encoding

A customer asked how they can control the output format of images saved in a PDF. Mako does not provide explicit control over how images are encoded/compressed when saving to PDF. Instead, it uses some logic to choose whether an image needs reencoding, attempting to select an image format based on the image type of the incoming image. For example, if an image is lossy, then encoding as JPEG is appropriate; if the image is lossless, then Mako will choose between DCT/JPEG, Flate (aka zip compression), and CCITT based on the image type.

Moreover, Mako does not allow the direct selection of LZW or RLE (run length encoding). This lack of control is deliberate. Mako’s current behavior of selecting Flate instead of LZW or RLE is generally a better choice; LZW and RLE are outdated formats and using them does not improve the output, or affect quality in any way. Additionally, LZW is not allowed at all in some formats (PDF/A and PDF/X).

Nevertheless, some additional controls are introduced in this release.

Set the environment variable MAKO_ALLOW_LZW_PREFERRED to force LZW to be selected instead of defaulting to Flate, if an input LZW image type is encountered.
Set the environment variable MAKO_ALLOW_RLE_PREFERRED to force RunLengthEncode to be selected instead of defaulting to Flate, if an input RLE image type is encountered.
Set the environment variable MAKO_ALLOW_PREFERRED_FOR_MONO to have Mako attempt to honor the preferred image format, based on the input image type.

These environment variables don’t need to be set to any specific value, they just have to exist to trigger the behavior described.

It should also be noted that Mako does not have encoders for JBIG2 and JPEG2000 (JPX). This is likely to change in a coming release, but currently these formats cannot be reencoded. They can be passed through, so if the image is untouched it will remain in its original format.

For an IDOMRawImage, which is by definition a non-specific image type, there is a property defined by an eDomImageType to specify a preferred image type when being created.

MAKO-5159 MAKOSUP-11381 Fonts are always embedded on saving a file

The customer was setting IPDFOutput::setEmbedFonts(false) and expecting fonts to be unembedded, but it turns out that CPDFOutput::setEmbedFonts() was setting the embedded flag to true regardless of the function argument. The equivalent setting using setParameter()works correctly, so in this case the issue could be worked around. This change fixes IPDFOutput::setEmbedFonts().

MAKO-5166 MAKOSUP-11518 PDF/A output parameter and presets are dropping XMP properties

This change adds the following API, and code to work with it, particularly for PDF/A:

CODE

    void setIgnoreXmp(bool ignore)

Its purpose is to allow custom XMP entries to be preserved into PDF output when setting the output to PDF/A, which previously would overwrite existing XMP with a packet that was guaranteed to be PDF/A compliant.

The new behavior can be summarized as:

If the setIgnoreXMP flag set to true then XMP in the input is ignored in the PDF output
If the setIgnoreXMP flag is set to false then XMP in the input is preserved in the output
The default value of setIgnoreXMP is false
PDF/A presets set setIgnoreXMP to true

This is a change in behavior. Just setting the PDF output version to a PDF/A variant will result in XMP being reused. (It should be emphasized that the presets, where available, are the preferred starting point for output configuration, for safety and compatibility.)

Since it is now possible to set PDF/A output to make use of the XMP metadata in the input, XMP validation is also disabled so that custom entries can be retained. The customer is therefore responsible for ensuring that nothing in the input XMP will cause the output to be invalid PDF/A. Mako will now take greater care when examining the extension schemas that may be present in the input XMP, preserving them as necessary. If there are no extension schemas found, Mako creates fresh PDF/A extension schemas as per its previous behavior.

MAKO-5202 MAKOSUP-11540 PCL5 Processing Error: Ran out of nodes in contour tree

The customer exhibit was a PCL5 job containing a very broken Intellifont font. Changes are made in this release to workaround the issue, with the result that the job now converts correctly.

MAKO-5205 MAKOSUP-11533 Expanded XObjects look different than the original file

This issue was caused by Mako’s PDF output not using correct source for specific font information, in this case. Now fixed.

MAKO-5207 MAKOSUP-11546 Losing a µ character when double-saving a PDF

This issue was triggered by a specific set of circumstances. A PDF with a font that had a single glyph that was marked as composite (when in reality is was not) was saved twice with font subsetting explicitly disabled. On the second save, the reference in the composite glyph to the glyph source was not written, resulting in the glyph being absent from the output. This is now fixed.

MAKO-5249 MAKOSUP-11561 XPS file fails to load in Mako

This was caused by an error when reading a key from the customer exhibit, an XPS file. Now fixed.

MAKO-5265 MAKOSUP-11567 PDF file fails to load in Mako

This was caused by an unexpected indirect reference when an integer was expected. Now fixed.

Deprecated functions now removed

MAKO-4885 DeviceParams properties can no longer be used

In Mako 7.4.0, new APIs were added to apply overprint and stroke adjust properties to DOM nodes. They superseded a more awkward method which will no longer work in Mako 8.0, and calling them will throw an exception.

Distribution

Changes in Mako 8.0:

macOS is now built with developer SDK version 15.2 (was 13.3)
Linux - Debian Buster & Debian Bullseye are replaced by Debian Bookworm
Python: On Windows, the minimum version is now 3.11, and later versions are allowed

MAKO Version 8.0.0 is built for the following platforms:

iOS
macOS
Linux (for Debian-based distributions, eg Ubuntu 24.04 LTS, Mint)
Linux (for Debian Bookworm)
Linux (for Alpine Linux v3.17)
Linux (CentOS8)
Linux (Red Hat Enterprise v8.4)
Linux (for Debian Bookworm) (arm32v7 for Raspberry Pi)
Linux (for Debian Bookworm) (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

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

Linux_GNU_SWIG_(C#-Java-Python)
Linux_Alpine_SWIG_(C#-Java-Python) – Alpine v3.17
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.