Mako 8.1.0 Release Notes

RELEASED 31ST JULY 2025

Introduction

Mako 8.1 adds new functionality to the Apex GPU-based render that we introduced in Mako 8.0. In particular, we have opened up post-processing on the GPU, thereby enabling what may be CPU-intensive processing of a rendered image to be carried out on the GPU before retrieving the result. Now you can write your own OpenGL shaders, and have Apex run them on your behalf. A new documentation page shows how, with an example of screening.

Mako API documentation improvements

https://api.globalgraphics.com/mako

The documentation generated with Doxygen from the interface APIs has been improved to include classes that were previously minimally documented or missing altogether. Additionally, overlooked API parameters and return types have been added. One result of this is that the search is improved. To look up a class or enum, type its name into the Search box to display a link. The API documentation is also relevant to developers writing C#, Java or Python, since the SWIG APIs mirror the C++ implementation. Although the syntax may be slightly different, their purpose and the details of parameters and return types are the same.

New features

MAKO-5298 Apex-enabled IJawsRenderer classes

To help those evaluating Apex, Mako’s GPU renderer, a new API allows a developer to substitute a call to the IJawsRenderer() constructor with one that will instantiate an Apex renderer behind the scenes. Subsequent rendering calls are then redirected to Apex, with the performance benefits that can offer.

This <doc page> shows how to use Apex Eval.

MAKO-5355 Implement Apex post-processing API

In Mako 8.0, applying tone curves is carried out after Apex has rendered the page, but before the result is retrieved from the GPU. As it happens after the rendering has taken place, we refer to it as post-processing. Mako 8.1 opens this approach up to developers by offering a public API for post-processing. Now developers can write their own GPU shaders and request Apex to run them on its output before the result is retrieved. Different processes are possible, for example:

• Post processes that operate on (process) color samples

• Post processes that operate on spot (color) samples

• Post processes that merge spots into the color samples

The <doc page> that explains the different type of post processing and how to use to the new APIs. A sample shader is included that applies a traditional line screen to CMYK output.

MAKO-5356 Apex: Support ignoring PDF colour management

A new CRenderSpec entry, ignoreInputIccProfiles, is provided. When set to true, Gray, RGB and CMYK ICC profiles in the Mako DOM will be ignored and instead be mapped to DeviceGray, DeviceRGB or DeviceCMYK as appropriate.

MAKO-5357 Apex: Improve fine lines

This change adds support for automatic stroke adjustment (strokeadjust) in Apex and improves the rendering of thin lines. strokeadjust controls how strokes are aligned to the pixel grid — specifically, it helps ensure crisp, single-pixel-wide lines by adjusting the positioning of strokes during rendering.

MAKO-5363 Apex: Move settings into the render spec

Mako 8.1 sees some IApexRenderer settings migrate to CRenderSpec settings, so that they can be set on a per-render basis. Those settings include:

This is a breaking change as the IApexRenderer APIs have been removed.

MAKO-5267 Apex: Support applying tone curves to the final space

Applying a tone curve now becomes an Apex post-processing step. Though the method for specifying a tone curve remains unchanged, there is more flexibility about where in the (post) rendering process the tone curve is applied.

MAKO-5319 Apex: Enable process colours to be turned on and off

No API change was necessary to meet this requirement, as it can be easily achieved with a 0-0 tone curve. See <doc page on post processing> for an example.

MAKO-5263 Add a Total Ink Limiting (TAC) mechanism to Apex

The is implemented as an Apex post-processing feature. See <this doc page> for an explanation of Apex post-processing. With it you can control maximum total ink coverage (for example, 300%) and control over whether black is left as is, adjusting only the other components. Apex renderer makes these adjustments to the rendering result while still on the GPU, meaning it happens very quickly.

MAKO-5224 Enable rendering intent to be set for images

Two new parameters, rgbImageRenderingIntent and cmykImageRenderingIntent, are added to the Apex CRenderSpec class to enable rendering intent to be set independently for RGB and CMYK images.

MAKO-5380 Allow unique color management options to be specified for each render request

Previously, color conversion settings were made with IColorManager APIs and were global in nature. These settings would affect the behavior of the renderers, Jaws and Apex. For Apex, a more flexible approach is adopted in Mako 8.1 that allows color settings to be defined on a per-render basis. These are the settings available:

• The intercepts for gray, RGB and CMYK

• Whether we are mapping device gray to CMYK black

• Whether we are converting gray via CMYK black

• The default black point compensation

The settings are encapsulated in a CColorManagerConfig class, an instance of which may be supplied to the render via the renderSpec->overrideCmmConfig entry.

MAKO-5242 Extended gamut output support for Apex via wide gamut CMYK

This improvement introduces wide gamut support, such as CMYKOV or CMYKOG, to the Apex renderer. You can now pass an ICC profile with those extra channels to Apex to produce additional separations.

MAKO-5328 Support spot color aliasing in Apex

A new class, CSpotColorAlias, specifies aliasing for a spot colorant in a render.

An alias can map a spot component (spotName) to any other component (remappedColorant) in a render, including a process component. For example, it is possible to alias "GlossBlack" to "Black" such that GlossBlack is treated as if it were the Black process colorant. Multiple aliases may map to the same final component.

MAKO-5225 Support PACKZ .tcb format for defining colors

A new class, JawsMako::ITCBFileIO, reads color definitions (color space, colorant values) from a text stream that specifies colors according to the Hybrid Software PACKZ Color Book format, version 1.0.

MAKO-2664 Enable color conversions from DeviceGray to use a CMYK ICC profile

This is a new feature that adds the ability for the color manager to specify that the DeviceCMYK profile be used for colour conversions from DeviceGray, and add support to Apex.  This feature can be enabled by setting IColorManager::setConvertDeviceGrayUsingCMYKBlack() to true.

There is an existing feature, setMapDeviceGrayToCMYKBlack() that will map to DeviceCMYK in a similar manner, however, this will only apply to DeviceGray to DeviceCMYK conversions.  The convertColors()routines (floating point, integer) have been updated to map for other conversions when this feature is set. Mako will map CMYK black in a similar way, before converting to the target colour.

MAKO-5313 Add colour conversion API to use ColorLogic deltaE00 conversion

This new API, IColorManager::getOptimizedSpotFromLab() is available only on ColorLogic builds of Mako. It uses ColorLogic to find the best possible (lowest error) device color for a given spot color, where the spot color is specified as LAB.

MAKO-5269 Update C# simpleapexrender to match C++ simpleapexrender

The C# example for rendering on a GPU (found in the SWIG builds folder for C#) is updated to match the C++ version.

MAKO-5291 Make python simpleapexrender match the C++ simpleapexrender

The Python example for rendering on a GPU (found in the SWIG builds folder for Python) is updated to match the C++ version.

MAKO-5275 SWIG : Clarify API for IInputStream.createFromMemory()

In Mako 8.0 and earlier, this API has the following signature in C#:

public static IRAInputStream createFromMemory(
  IEDLClassFactory pFactory,
  byte[] mem,
  uint length,
  bool copy,
  bool free);

Because of the way in which Mako’s SWIG APIs interface with Mako’s C++ implementation, it was wise to always specify True for the copy parameter to ensure the shared buffer memory remained available for the lifetime of the object. To prevent errors that arise from these values not being set correctly, they have been removed from the SWIG APIs altogether and are set internally to the correct values. They can be safely removed.

This is a breaking change for C#, Java or Python code that may have explicitly set these parameters and will most likely manifest as a build error.

MAKO-5280 Reporting progress when writing output using a page event

An application built with Mako that saves a PDF can now monitor progress by means of an event at the start and end of each page. This is fine for a document with many pages, and since the number of pages is known, easy to represent in a UI a progress indicator of some kind. Se <doc page> for an example of how to implement.

MAKO-5372 Implement a progress call back for saving

An application built with Mako that saves a PDF can monitor progress by means of an event at the start and end of each page. See MAKO-5280.

For documents with a single or a small number of complex pages, this approach is lacking as there is no way to monitor progress while the page is being processed, until now.

This change offers a developer a mechanism to get feedback as a page is written, essentially a tick, the frequency of which can be controlled. It does not provide an estimate of the number of events, but it does at least enable a developer to present a UI that shows that a save process is continuing, and a means to abort the process cleanly if the user decides to cancel the operation. See <doc page> for an example of how to implement.

MAKO-5293 Switch to new FreeType hinting engines.

Mako makes use of FreeType libraries for various purposes, and this update improves hinting, the process of fine-tuning how vector fonts are rendered, using instructions to align features cleanly to the pixel grid for better legibility at small sizes.

MAKO-5270 Six-color TIFF color names incorrect

Mako’s IDOMTIFFImage::create() function that loads a TIFF file into an IDOMImage has an option (allowMultiChannel) to recognize extra channels in multi-channel TIFFs, i.e., those with spot color channels in addition to the CMYK process colors. This requires creating a DeviceN color space with the required number of colorants. Until now, the extra colorants would be given a name based on their order, e.g., “5” & “6”. With this change, Mako will look for Adobe Photoshop tags associated with those channels to obtain the name seen in Photoshop’s ‘Channels’ side panel, and assign the colorant names accordingly, if they are found.

MAKO-5382 Overprint detection

A new class, IScanOverprint, enables a fixed page to be examined for overprint. For Jaws and to a lesser extent, Apex, simulating overprint in the rendered result takes longer than a regular render, therefore knowledge of whether it's required is clearly valuable.

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-5306 MAKOSUP-11429 Exclude selected colors from flattening

Mako’s IRendererTransform is a class that is used to flatten transparency, by rendering areas of page content to an image or vector objects with no transparency.

There may be a requirement to exclude certain page objects from the flattening process, for example a die line or other non-content artefacts. This is made possible by two complementary APIs:

• IDOMNodeFlag::eNodeExcludeFromRender()

• IRendererTransform::ignoreNodesWithExcludeFlagSet()

The first marks a node to be ignored when rendering using IRendererTransform. The second controls whether the rendering process should act upon the flag. You can search for these in the online documentation (https://api.globalgraphics.com/mako) for further details.

MAKO-5243 MAKOSUP-11503 Issues with parsing / converting some PDFs

The issue was caused by some bad flate (zip-compressed) streams in the customer’s PDF, which we didn’t handle appropriately. Now fixed.

MAKO-5237 MAKOSUP-11528 Font Encoding changes when saving a file

When Mako saves to a PDF, fonts undergo processing to eliminate duplicates and consolidate subsets. The result of this processing, even when the font is essentially unaltered, is that the encoding of the font is marked as Custom, and reported as such by tools such as Acrobat, even though the encoding hasn’t changed.

This improvement ensures, wherever possible, that Mako’s PDF output accurately reflects the original encoding for a given font, enabling downstream tools including those built with Mako to report font encoding more accurately.

MAKO-5335 MAKOSUP-11535 Retain floating point resolutions in downsampled images

The IDOMImageDownsamplerFilter rounds requested resolutions to the nearest integer. This design decision was made because not all image formats support fractional resolutions, and when writing to such a format, the image would not be scaled correctly. However, PDF does allow for fractional DPI settings, and the downsampler should allow them.

This change (optionally) allows floating point resolutions in the IDOMImageDownsamplerFilter, and the IImageDownsamplerTransform that uses it. This avoids the error that can creep into integer arithmetic when the resolution to be set on the image is low, for example when the image is scaled down on the page, but the local image resolution is also low.

The new behavior is enabled via a parameter and a setter:

• useFloatingPointResolution is added to IDOMImageDownsamplerFilter::create() method

• setUseFloatingPointResolutions() is added to IImageDownsamplerTransform

MAKO-5256 MAKOSUP-11559 PCL5 to PDF missing barcode

This customer issue was caused when the bitmap font used to render a barcode failed to be selected correctly by Mako. This is now fixed.

MAKO-5281 MAKOSUP-11574 One high vulnerability CVE-2025-27363 FreeType

The CVE refers to TrueType GX (variable fonts) that Mako does not make use of, so it would avoid the vulnerable APIs. Nevertheless, we have taken the opportunity in Mako 8.1 to integrate a later version of FreeType to one where this vulnerability no longer applies.

MAKO-5290 MAKOSUP-11582 Processing error

The rendering issue that the customer observed was concerned with the rendering of a Type3 font. Strictly speaking, what Mako is doing is correct according to the PDF specification. However, this is not what is seen in Acrobat. A change has been made in this release to replicate Acrobat’s behavior, but it is not enabled by default. To do so, the environment variable MAKO_PDF_WORKAROUND_TYPE3_KNOCKOUT needs to be set to something non-null. With this setting, the customer exhibit renders as expected.

MAKO-5300 MAKOSUP-11583 Mako conversion of PDF to XPS is losing the image layer

The problem here was not in Mako per se, but in the way the Microsoft’s XPS Viewer interpreted the XPS produced by Mako, which was syntactically and structurally correct. To overcome this issue, a new API is added, IXPSOutput::setAlwaysUseVisualBrushesForMaskedBrushes(), that defaults to true. This means Mako behaves in the same way as before, and a user will need to explicitly set setAlwaysUseVisualBrushesForMaskedBrushes(false) to use this workaround.

MAKO-5282 MAKOSUP-11579 Problem rendering file.

The customer issue was caused by a Shading Pattern rendering issue, which is now fixed.

MAKO-5358 MAKOSUP-11591 Alternative to locking files

A new stream is introduced that copies an input stream into the temporary store on a background thread.  Immediately upon creation, this stream will begin copying from the source stream into the temporary store on a thread, from the start of the file. A throttling mechanism prevents this process from swamping processes running on other threads, which may include file reads. Once the copy is complete, the reference to the input stream is dropped, which should close the file unless it is open elsewhere.

The new creator is IInputStream::createBackgroundCopyStream().

MAKO-5332 MAKOSUP-11598 Single created path becomes a two-segment path after save / reload

A small change was made to drop useless closepaths in PDF input that overcomes this issue.

MAKO-5308 MAKOSUP-11599 Mako sets "/DecodeParms null" parameter for some images in PDF

The issue here is that Mako is writing a null /DecodeParms entry to image dictionaries when all the values are null. In these circumstances, a null entry should, according to the PDF specification, be treated the same as if the entry does not exist. However, a customer’s downstream PDF consumer (a printer) was rendering the page incorrectly when this entry is present. This is a change to Mako’s PDF output to omit the entry when the dictionary values are all null.

MAKO-5303 MAKOSUP-11597 Error loading PDF file

Work around a broken PDF file that had at least one CID font with no defined /CIDSystemInfo dictionary.  As per the spec, this is a required entry, and Mako correctly throws an exception when this entry is missing. Although Acrobat reports an error, it works around the issue and displays the file. Mako now also works around the issue, by assuming Adobe-Identity-0 for the missing entry.

MAKO-5316 MAKOSUP-11601 SWIG: ISeparation.getSeparation() returns incorrectly encoded name

A string conversion issue was addressed to solve this customer problem.

MAKO-5365 MAKOSUP-11622 PCL 5 font mapping issue

A simple fix solved this customer issue.

MAKO-5366 MAKOSUP-11624 Distorted graphics after Mako conversion to PDF

A fix to the PCL RLE decoder solved this customer problem.

MAKO-5370 MAKOSUP-11626 PCL5 interpretation - Top Margin (Y offset)

This problem was caused not by an incorrect interpretation of the top margin, but by an issue with PCL5 image offsetting. This is now fixed, and the customer exhibit converts to PDF as expected.

MAKO-5373 MAKOSUP-11632 Missing glyph when saving file with Mako

This change works around an issue with font merging that exhibited with a particular customer job.

MAKO-5386 MAKOSUP-11635 PCL5 font issue (17004)

The solution to this customer issue required changes to the PCL5 input class (IPCL5Input), namely:

• Support for text parsing mode 83

• Support for symbol set ID 31H

• Support for adding user supplied fonts that are then treated as though they were internal fonts. This is provided by a new API, IPCL5Input::addInternalFont().

MAKO-5289 Apex: Arithmetic overflow with C# simpleapexrender

This problem was uncovered during internal testing, and it’s worth a mention here because the solution is relevant to C# developers working with Apex. The issue was caused by an attempt to create a rendering buffer that exceeded the 2GB limit for regular byte arrays. The solution is to use the ArrayPool class, which is in any case a more efficient method when creating large buffers of this kind. For example, in simpleapexrender (found in the makoapps folder of the Mako distribution) the following code changes from:

int frameBufSize = (int) (stride * pixelHeight);
byte[]  frameBuffer = new byte[frameBufSize];

To:

byte[]  frameBuffer = ArrayPool<byte>.Shared.Rent(frameBufSize);

MAKO-5331 Apex: Customer PDF is slower with Apex than with Jaws

The cause of this issue was a very large image in the customer exhibit. Performance can be improved significantly by setting an image decompressor cache size, but previously this required setting an environment variable. This change adds a public API, IJawsMako::setImageDecompressorCacheSize(), to set this value. It is relevant to both Jaws and Apex renderers. With a value of 8196the customer exhibit rendered more quickly with Apex than with Jaws.

Distribution

Windows 2017 builds deprecated: This is the final version that will include Mako libraries built for Visual Studio 2017 (V141)

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 other respects the Apex release is identical to the Jaws release, and can be used for non-Apex development too.

MAKO Version 8.1.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.