Created Date: 01 Nov, 2023 18:21
Last Modifed Date: 02 Nov, 2023 13:46


This release is primarily driven by customer support requests, with some new features.

As Mako is used to build print workflow components for Global Graphics’s SmartDFE, where performance is vital, the Mako development team have also been working on “under the hood” performance improvements in the core SDK that you as a Mako developer will benefit from.

Fixes 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 will work only for the customer who reported it.

Issues addressed


MAKOSUP-11172 Cross platform Java (Linux/Windows)

This was a customer request to repackage the Mako libraries for Java for both Windows and Linux into a single jar, to simplify their deployment. We have now automated the repackaging process on our build server and made it part of the regular release. See Distribution below for further details.


MAKOSUP-11190 Open specific PDF Fails

This was solved by an improvement to Mako’s parsing of PDF dictionaries.


MAKOSUP-11221 Mako RIP Error

This issue was caused by a missing checksum on the end of a flate- (zip-) compressed object inside the PDF. Most PDF consumers seem to ignore this error; Mako will now do the same.

This issue had a high prevalence (it was reported by several customers) because the error seemed to be associated with a popular authoring application, in this case Adobe InDesign.


MAKOSUP-11231 Incorrect font selection

This was an issue with Mako’s PCL interpreter. Now fixed.


MAKOSUP-11238 SDK crashes when saving a PDF

The customer exhibit has a bad annotation, but as other PDF consumers seem to ignore this error rather than throwing an exception, Mako will now do the same.


MAKOSUP-11239 Mako keeping files open

This was happening because a cached image was preventing an XPS source from closing. Mako avoids this situation for PDF, but not XPS. This problem is rectified in this release. Subsequent work has improved this situation still further. See MAKO-4585 below.


MAKOSUP-11242 Eggplant emoji causes an exception

The customer case has a bad TrueType font that triggered an exception when converting a glyph to an outline. Mako now detects the error and applies a workaround.


MAKOSUP-11247 The SDK mangles some characters in PDFs

The customer exhibit uses Helvetica but does not embed it. The job uses several characters such as Rcaron that are not present in the standard Latin character set, with the result that output from Mako is missing characters as the DOM value points to a notdef. This is now changed; Mako correctly encodes such characters so that a PDF consumer will ‘know’ what the character is supposed to be. It will also duplicate the Latin portion of augmented Latin characters to make content more readable.


MAKOSUP-11253 IJawsRenderer::renderSeparations limited to 252 Spot Colors

Responding to a customer support request, this release raises the limit on the number of separations that can be generated from a single page from 256 (252 spots plus 4 process) to a whopping 4096 (4092 spots plus 4 process). While the customer’s use case was unusual, color charts and color books can easily exceed the previous limit.

While this is not a breaking change, it may be worth checking code that may have taken the previous limit into account and adjusting accordingly.


MAKOSUP-11254 Job crash while flattening

This was caused by a font in the customer exhibit that contained more than one marking notdef. Mako could handle one of these (and often does to achieve PDF/X-4 compliance) but not when the are multiple instances. This is now fixed.


MAKOSUP-11257 Text extraction error

An incorrect interpretation of a font’s ToUnicode CMap is corrected, resulting in accurate text extraction for the customer exhibit.


MAKOSUP-11267 Include user-installed fonts when scanning for font files

Mako will now scan for fonts (in Users\<username>\AppData\Local) that have been installed just for the current user, as well as those installed for all users (as found in Windows\Fonts).


MAKOSUP-11268 Custom Built Makoconverterdd.exe can't convert PDF document

Fixed issue when resolving CIE image colour space dictionaries.


E acute jumps out

This was an issue reported by a Jaws RIP customer and ported to Mako. The issue concerns a composite glyph i.e., one composed of different elements, in this case an uppercase E with acute accent that was jumping off its baseline. Now fixed.



Use shared files for XPS input to reduce the number of open calls on the filesystem

This relates to the issue above (MAKO-4601). This change reduces the number of active file handles by using shared streams rather than opening a file multiple times.


Implement smarter handling of strokes in the renderer transform

Improvements are made that increase the opportunity for object reuse, which can lead to faster PDF processing, for example when flattening transparency with the IRendererTransform class.


Implement skipScanlines() for the downsampler image filter types

The method IImageFrame::skipScanLines, which skips the given number of scanline rows to speed up image processing, is refactored in this release to improve performance when downsampling with an IDOMImageDownsamplerFilter.


Update libpng to latest stable release.

To improve performance or to fix a bug, third-party libraries used by Mako are occasionally updated. In this case, LibPNG. See the Copyright Notices page for further details.


Add clone() to ILayoutFrame and ILayoutParagraph

The clone() method is common to many Mako classes, enabling a copy to be taken of an object that can be modified without changing the original. For ILayoutParagraph, it simplifies adding new paragraphs to a CLayoutParagraphVect with common attributes, such as justification, space before, space after etc. This is a shallow copy, as it does not include any text or image runs already added to the paragraph.

This code snippet shows it in action:

// A vector to point to each paragraph to be added to the frame(s)
CLayoutParagraphVect paragraphs;
uint32 paraIndex = 0;

// Create some template paragraphs
const auto title = ILayoutParagraph::create(ILayoutParagraph::eHACenter);
const auto intro = ILayoutParagraph::create(ILayoutParagraph::eHAJustified, 9, 0, 1.3);

// Title
auto run = ILayoutTextRun::create(paragraphText[0], titleFont.first, titleFont.second, 60, darkBlue);

// Intro
run = ILayoutTextRun::create(paragraphText[1], bodyBold.first, bodyBold.second, 14.0));

A more complete example can be found in this documentation about Output Intents.


Add uniform scaling to ILayoutImageRun::create()

Previously it was necessary to calculate the scaling required to keep an image in proportion when creating an ILayoutImageRun. This change means that the create function will do this for you when you supply the width and/or height, based on these rules:

  • Non-zero width and non-zero height: Image is scaled to the width and height specified
  • Non-zero width and zero height: Image is proportionally scaled to the width specified
  • Zero width and non-zero height: Image is proportionally scaled to the height specified
  • Zero width and zero height: Image presented at 1:1, i.e., no scaling takes place

For predictable results, scaling should be applied to ensure an image will fit inside the intended frame. For example:

// Picture
double width = widthWithMargins / 3 * 2, height = 0;
const auto mountain = getImage(mako, R"(..\..\Images\Mountain.jpg)");
paragraphs[paraIndex]->addRun(ILayoutImageRun::create(mako, mountain, width, height));


Add colour as parameter to ILayoutTextRun::create()

The example above shows how this is used, in this case with a color called darkBlue, created like this:

// Create a colour
const auto darkBlue = IDOMColor::createSolidRgb(mako, 0.0f, 0.0f, 0.5f);


Enumerate available fonts for use with ILayout

The ILayout class allows the use of any OpenType font available on the system, but it’s not always easy to know which fonts are available. This becomes even more problematic for cross-platform development, where fonts with similar appearance have different names.

A new class, ILayoutFont, solves this problem. When creating an instance of this class, one or more font characteristics, such as bold and sans-serif, can be specified. Then a call to its findFont() method returns a CLayoutFontItem, which is the pairing of an IDOMFontOpenType and corresponding fontIndex . It is also possible to call findFonts() which returns a vector of CLayoutFontItems, each a match for the font characteristics supplied. This makes it possible to refine the choice further.

Creating an ILayoutFont instance and specifying no characteristics will return all fonts available for use with ILayout, when findFonts() is called.

An ILayoutFont can be used directly when creating an ILayoutTextRun (see MAKO-4649 below).

These improvements make it possible to write code to generate content with the ILayout tool that will work on different systems and platforms without the worry of missing fonts, while ensuring the content appearance will be broadly the same.

A knowledge base article describing how to use this new class will shortly be published on the Mako documentation website.


Add font specification to ILayoutTextRun

An additional method signature is added to ILayoutTextRun::create() that accepts an ILayoutFont object in place of an IDOMFontOpenType and fontIndex. This simplifies choosing a font which can now be done by selecting the required font characteristics rather than by a specific name.


Improve scanPdfForInks

Two new arguments are added to IPDFInput::scanPdfForInks() to allow users to specify a range of pages to scan:

  • startPageIndex is used to specify a page to start scanning from
  • endPageIndex is used to specify a page to scan until

Indexes begin at 0 where the number of pages to scan is equal to (endPageIndex - startPageIndex). For example, specifying 0,1 would scan the first page of a PDF, and 2,4 would scan pages 3 and 4.  A special endPageIndex value of 0 (the default) may be used to indicate that the scan should continue for all remaining pages in the PDF.


Allow more than one OutputIntent to be added to a document

The PDF specification allows for more than one Output Intent (an ICC profile that may be used for rendering plus some supporting metadata) to be present in a PDF. Until now, Mako allowed only one to be added, using IPDFOutput::setOutputIntent(). In this release, an additional API, IPDFOutput::setOutputIntents() is added that takes a COutputIntentVect (a vector of output intents) enabling more than one to be added to the output. Full documentation for this feature can be found here.


Add new API to getMutableGeometry

Regular IDOMPathGeometry allows editing. You can add figures, segments, whatever. Internally Mako has two other geometry types:

  • A points list geometry type describing geometry in a much more compact form as a list of points, instead of a series of discrete figures, segments, etc.
  • A compact geometry for a single rectangle

These are transparent to the user, who will be unaware that these are being used. Moreover, they have a significant drawback, which is that they cannot be edited. This information is exposed to the user by IDOMPathGeometry::getFiguresImmutable(), IDOMPathFigure::getIsImmutable() and IDOMPathSegment::getIsImmutable().

As we have had customers who want to be able to edit these geometries, we have, in the past, provided sample code to customers that allowed them to take one of these geometries to create a version that is editable. This change formalizes that approach into a standard feature. The new API, IDOMPathGeometry::getMutableGeometry(), returns a path that the user can edit freely.


Support macOS universal binary builds for SWIG

The C#, Java & Python implementations were previously available on macOS as two separate builds, one for ARM and another for x86. This has been replaced with a single distribution that makes use of Mako’s Universal Binary build, meaning that there is one library to run on both platforms. Accordingly, the NuGet package name is updated, and for this release is:



Deprecate IJawsRenderer::renderAntiAliasedToFrameBuffer()

This API is deprecated in this release and will be removed in Mako 7.2.0. 

IJawsRenderer::renderAntiAliased() continues to be available.

Python improvements

Mako’s Python API continues to improve. Here is a roundup of the changes in this release.


Port nativestream and userrastream simpleexamples to SWIG Python

This release sees the completion of the implementation of stream handling when coding with Python The two examples show exactly how to use random-access streams with Mako, matching the equivalent examples in C# & Java.

This change also prompted renaming the offset parameter in userRARead to streamOffset. This is to emphasize that this an offset into the source input stream, not the buffer. This change applies to C# & Java too, not just Python.


Add support for Python iterators in CEDLVector

Mako’s own vector implementation (CEDLVector) that is available to Python developers now supports iterators without the need to convert to a native vector type.


Output from the Python imposition simple example does not match that of C++

Testing uncovered a discrepancy between the output produced by Python example code vs. that of the C++ equivalent. Now fixed. See the MakoApps folder included in the distribution.


MAKO Version 7.1.0 is built for the following platforms:

  • iOS
  • macOS
  • Linux (for Debian-based distributions, eg Ubuntu 20.04 LTS, Mint)
  • 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)
  • Linux (for Debian Bullseye)
  • Linux (for MUSL distributions, eg Alpine Linux)
  • Windows (static and dynamic libs, VS 2019 (V142), x86 and x64)
  • Windows (static and dynamic libs, VS 2017 (V141), x64)
  • Windows UWP/WinRT

N.B. 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 and .Net Framework)

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

Python (v3.8)

The alternatives to C++ are built using SWIG ( which provides a translation to the native libraries. They found in these distribution folders:







Cross-platform Java build

The folder Cross-platform Java contains Java builds that combine the implementations for Windows and Linux into a single JAR package. This can be deployed on either platform. The distribution consists of two Windows/Linux combinations, one for GNU Linux and another for Ubuntu. A pre-built sample app is also included.


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 SWIG build for development with C#, Java or Python.