Mako 8.3.0 Release Notes

RELEASED JANUARY 9TH, 2026

Introduction

Mako 8.3.0 is a regular, quarterly release of MakoCore SDK with new features and the usual round of fixes and improvements in response to support requests.

There was also a lot of work carried out in this release cycle to improve performance, reliability and rendering accuracy that these release notes do not fully reflect.

There are changes to the platforms available in the Mako software distribution. See Distribution below for further information.

New Features

MAKO-5339 MAKOSUP-11663 Feature request for upsampling images

This change introduces IImageUpsamplerTransform and IDOMImageUpsamplerFilter. These support image upsampling using bicubic and bilinear methods, and are analogous to the existing methods for downsampling.

MAKO-5406 Apex: Support DeviceN decomposition and a spot colour database

Apex can now decompose DeviceN spaces and color manage spots and process components separately. A full explanation can be found in the online documentation.

MAKO-5484 Provide a means to quickly establish if a PDF is using an “All” separation

This improvement adds an optional includeAll flag (default false) to IPDFInput::scanPdfForInks(). An inkname of “All” is returned when the flag is true and an All separation is detected.

MAKO-5476 Apex - XPS opacity and other issues

This release includes several improvements to the Apex renderer to correctly interpret the XPS imaging model in areas of color, gradients, transparency and image clipping.

MAKO-5388 Allow the CMM configuration to be overridden in IRendererTransform::inkInfoToColorantInfo()

Testing revealed a color shift when rendering a page from the Altona test suite. A mismatch between the ICC profile used to render the process colors and the colorspace used to determine the color of the spots was the underlying cause. The solution is to use using the same colorspace for both. To simplify that, the IRendererTransform::inkInfoToColorantInfo() method acquires an optional parameter to take a CMM override configuration, one that can be passed both to the renderer and to this API when determining the spot component information, thereby ensuring the color calculations match.

See the online API docs; search inkInfoToColorantInfo.

MAKO-5514 MAKOSUP-11704 Provide a method for ignoring non-graphical PDF items when opening a PDF

The customer reported that a job takes 500s to render with Mako 8.2.0 as opposed to a couple of seconds with Harlequin clrip. The reason for this is that Mako interprets non-graphical information to populate corresponding Mako DOM data structures, and in this case was taking a long time to do so. The customer exhibit contains a monstrous Structure tree, with a parent that contains about half a billion array entries, including many 10k+ arrays populated entirely by nulls. These are stored in (very large) compressed object streams that need repeated access. Suffice to say that reading this structure tree is very expensive and requires a lot of memory.

Rather than attempting to optimize the processing of such an unusually large structure tree, a new API enables it to be bypassed altogether when rendering is the sole requirement, as in this case.

This change adds a new API to Mako’s IPDFInput class:

CPP

void setIgnoreNonGraphicalObjects(bool ignoreNonGraphical);

Setting this to true will cause PDF input to ignore:

Dests
Outlines (Bookmarks)
Document Structure (StructTreeRoot)
Threads
Any other /Catalog entry for which Mako does not have an explicit API
Page PieceInfo entries

This solved the customer’s problem. This setting has been added to the rendering examples included in the SDK such as simpleapexrender.

MAKO-5540 Implement a transform to add noise to Type 2 shading patterns

A new transform, IShadingPatternNoiserTransform, reduces banding in Type 2 gradients by adding noise to smooth out color transitions. A complete code example that shows how to make use of this feature can be found on GitHub.

MAKO-5508 Add screen angles to simpleapexrender

This example found in the Mako Apex distribution now allows for screen angles to be input on the command line.

MAKO-5519 Update the C#, Java and Python simpleapexrender apps to match C++

These example apps are updated with halftone screening and other features added to the C++ version.

MAKO-5539 Update zlib in MAKO to 1.3.1

The version of the zlib library, used for Mako operations such as flate compression in PDF, is updated to a more recent version.

Customer issues

Customer issues include a link to the support request (MAKOSUP-xxxxxx), which will work only for the customer who reported the issue.

MAKO-5507 MAKOSUP-11428 Speed up obtaining colors from 2500 page PDF

A new caching mechanism is introduced to avoid unnecessary unpacking of repeated transparency group forms. This is a general performance improvement to the IPDFInput class, and for the customer example reduced scanning for inks across 2500 pages from more than 20s to just 8s.

MAKO-5255 MAKOSUP-11556 PCL5 to PDF rendering issue - Content missing

This was caused by image processing ending earlier than it should. Now fixed.

MAKO-5315 MAKOSUP-11592 PCL5 to PDF conversion - Missing vertical line from right-hand column

The solution required a new option to the PCL5 input class, IPCL5Input, to support edge-to-edge printing, a feature that is supported by some PCL printers.

This feature can be enabled by setting setDefaultEdgeToEdge(true). This will enable edge-to-edge printing when the job does not explicitly specify what to do.

Additionally, the PJL parser (IPJLParser) will now recognize a PJL "SET EDGETOEDGE = <YES|NO>" command to enable/disable edge-to-edge printing.

A default setting is added to allow the default behavior to be set when using setDefaultsFromPjl()
IPCL5Input will also pick up any EDGETOEDGE command set via PJL.

MAKO-5461 MAKOSUP-11674 Preserve “closed” status on PDF paths when filled

A customer reported a PDF was broken when processing with Mako. The cause for this was an inconsistency in the way Mako wrote PDF paths, leaving them open when the original path was closed. While this has no effect on rendering, it interfered with the customer’s subsequent processing that relies on this condition. To solve this, Mako now preserves the closed status of filled paths.

MAKO-5467 MAKOSUP-11682 No progress reporting when generating IDOMFonts during scanPdfForFonts

The issue here is that the call to the scan-for-font API set the domFont parameter to true, which signals that IDOMFont objects should be generated from the PDF font objects. It was this part of the process that was not reporting its progress. This is now addressed, with the reporting divided equally between initial scan and font generation.

MAKO-5531 MAKOSUP-11682 scanPdfForFonts performance improvements

The goal was to improve performance when generating IDOMFonts with IPDFInput::scanPdfForFonts(). This was achieved with a new hashing / caching mechanism, that had the useful side effect of improving hashing for Type 1 fonts.

For the customer exhibit, these changes saw scanning and font generation reduce from over a minute to around a second.

MAKO-5478 MAKOSUP-11686 PCL5 to PDF conversion - Line / box issue

This issue was caused by an overlay macro in the PCL5 having a MacroID of 38000, which according to the PCL specification is invalid, as the maximum is 32767. Mako correctly ignores this macro, but this means the overlay macro is set to the current macro ID and results in incorrect output. Other PCL interpreters are more relaxed about out-of-bounds macro IDs, and when Mako is made to behave in the same way, correct output is produced. The original behavior can be reinstated by defining an environment variable, MAKO_PCLIN_IGNORE_INVALID_MACRO_ID to any non-null value.

MAKO-5482 MAKOSUP-11691 Mako throws an exception when opening a PDF

The customer file was a bad PDF, but Mako should not have crashed. This is now fixed.

MAKO-5505 MAKOSUP-11692 Crash in writeAssembly when processing PDFs with images

The customer exhibit has a somewhat unusual progressive DCT image that is causing occasional crashes in the Jaws DCT decoder. The issue was meticulously diagnosed and code to support this scenario was added.

MAKO-5517 MAKOSUP-11694 IDOMTIFFImage::createWriterAndImage() creates an unusable image

This required a fix to Mako’s lz4 stream handling.

MAKO-5490 MAKOSUP-11696 Address/Investigate Vulnerability in LibTIFF

A vulnerability was reported in LibTIFF, a library used in Mako. Although Mako does not make use of the affected API, the version in Mako was updated to 4.7.1 which has the required fix.

MAKO-5511 MAKOSUP-11705 Issue with Incorrect Rasterization in PDF

This was a mask-inside-a-softmask rendering issue in Jaws (Apex was OK). Now fixed.

MAKO-5523 MAKOSUP-11711 Error raised when attempting to open a XPS file

This required a change to ignore font GSUB information that points to glyphs that are out of range.

MAKO-5530 MAKOSUP-11715 Mako crashed - "Pages from Taibao2_20170905.pdf"

This required working around a broken TrueType font in the customer exhibit PDF.

MAKO-5537 MAKOSUP-11719 PCL5 to PDF conversion - Text missing on page 2

The problem reported by the customer was caused by Mako not behaving like other PCL interpreters when switching to HP/GL mode, with the result that content present in the job was clipped out. Now fixed.

MAKO-5544 MAKOSUP-11721 ILayoutFont::findFonts() does not list Mac user fonts

The macOS user font folder was overlooked by this API. Now fixed.

MAKO-5549 MAKOSUP-11724 Text line is broken into single characters, making text editing impossible

To overcome the reported issue, Mako will now attempt to merge charpath groups, thereby providing a solution for the customer. It will do this only when there are simple shows (e.g., no character positioning) and simple fonts (e.g., no composite glyphs). The original behavior can be reinstated by defining an environment variable, MAKO_MERGE_PDF_CHARPATH_TEXT with a value of disable.

MAKO-5552 MAKOSUP-11727 Rendering with parallel threads creates a memory leak

Background

The issue that the customer is seeing isn’t really a memory leak. It’s just the way that the Jaws memory allocator works, due to the constraints of PostScript. Jaws reserves a large portion of address space (via VirtualAlloc() on Windows and mmap() on other platforms), and “commits” pages from that address space as needed for new allocations (via VirtualAlloc() on Windows and mprotect() on other platforms). When the pages are no longer in use, they are kept in a free list for the next allocations that are coming.

When the customer is rendering in threads, the various Jaws instances all need memory at once, and so a significant amount of memory from the reserved address space is committed. When the renders are complete and the job is closed, those pages are still committed, they are just in the free list, available to service allocations from the next render, or job, or whatever Jaws is asked to do. This is very fast; no communication with the OS is required and the memory is ready to use immediately. The actual committed memory represents the high-water mark of memory demand for anything that has happened up to that point in execution. And this is what the customer is seeing. For the customer case, this is largely raster memory, but this is possible for anything.

Solution

Mako now features a mechanism to return some memory back to the OS, which works well. The memory in use after rendering has completed in the customer example is much lower, and after the closing of the job, lower still. Rendering performance is unaffected.

By default, Mako will release a set of pages if they are over a megabyte. This is adjustable with the environment variable J_UNCOMMIT_THRESHOLD (specified in bytes); setting this to zero disables this new behavior.

Distribution

Windows VS2017 builds removed: This version no longer includes Mako libraries built for Visual Studio 2017 (V141 build tools)

Windows VS2019 builds deprecated: Although Mako libraries built for Visual Studio 2019 (V142 build tools) will continue to be available, we recommend you switch to the new Mako libraries built for Visual Studio 2022 (V143 build tools). The VS2019 builds will be removed some time in 2026, which includes x86.

Windows UWP/WinRT build deprecated: This is the final version that will include Mako libraries built for Universal Windows Platform.

Mako is distributed in a folder labelled MakoSDK that you will find in your support FTP folder. If you have access to Apex, there will be a second folder labelled MakoApexSDK. Obviously, the latter should be used for Apex-related development, but in all other respects the Apex release is identical to the Jaws release and can be used for non-Apex development too.

Mako Version 8.3.0 is built for the following platforms

Apple:

iOS (iOS 6.0 and later)
macOS (universal binary - x86 & ARM, macOS 11 (Big Sur) and later)

GNU / glibc–based Linux:

Ubuntu 24.04 LTS
Mint 22.2
Debian Bookworm
Red Hat Enterprise v8.4
CentOS8
Debian Bookworm (arm32v7 for Raspberry Pi)
Debian Bookworm (arm64v8 for Raspberry Pi)

musl-based Linux:

Alpine Linux v3.17.10

Windows platforms:

Windows (static and dynamic libs, VS 2022 (V143), x64 and ARM64)
Windows (static and dynamic libs, VS 2019 (V141), x64 and x86)
- Found in Windows_VS2019 folder
Windows UWP/WinRT (deprecated)

Android:

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 is included: makoconverter.jar, and additionally for Apex, simpleapexrender.jar.

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 use the ColorLogic CMM.

Windows: All Windows C++ ColorLogic builds are VS2022 only (V143 build tools), beginning with this release