List of changes

Introduction

This is a curated list of the development stories that were completed during the Mako 9.1.0 development cycle.

As usual, this release includes many improvements made in response to issues and requests reported by Mako customers. Where a link to the support issue is included, it can only be opened by the customer who reported it.

New features

MAKO-5019 Perform input image color conversion on the GPU

This is a performance improvement made to the Apex renderer. To suit the Apex pipeline, images must undergo color conversion. Where possible, this conversion now takes place on the GPU. This improves overall rendering performance, particularly for jobs containing large images. No user code changes are required.

MAKO-5032 Apex: Previewing features

The purpose of this change is to allow editor-style features such as previewing CMYK and Spot Overprints (compares to the Print Production Output Preview feature in Adobe Acrobat).

It’s possible to do these kinds of things already with Apex using the same methods that are used for Mako’s standard, CPU rendering. That is, render to CMKY + spots, and then use those images to generate an RGB preview, folding in the spots. By doing these things on the GPU, response should be significantly faster.

This change adds two new entries to CRenderSpec:

• finalSpace - This is an additional colour space to which Apex will convert following the rendering to the process space. A typical use case would be to specify a CMYK colour space as the process space (to say simulate a press) and an RGB colour space as the final space (the display colour space). Apex first renders and composites to the CMYK space, allowing CMYK overprints to work, and then subsequently converts to an RGB image to be displayed on screen. If a final space is not provided, the process space will be used.

• mergeSpotColors - This is a list of spot colours that the user would like to be simulated, and the actual colours (in the final space) of those spots. Apex will internally render to the process space + spots, convert to the final space (if provided), and then finally merge the spots into the final image.

MAKO-5851 Implement sampled image/texture in Apex

This is a new Apex renderer feature.

The result of rendering is normally presented to a post-processing step as an input attachment (VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT) that offers the shader access only to a single pixel (in GLSL, a subpassInput).

To meet the requirement to enable a post-processing step to read values from adjacent pixels, as may be required for screening, the rendering result can now be a sampled image/texture (VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER). In GLSL, a sampler2D. Further information and a shader example can be found here.

MAKO-5751 Apex: Support passing CFrameBufferInfo buffers as null to the renderer

This change allows for rendering a subset of the process components or omitting them entirely. This applies only to Apex, when rendering with CFrameBuffersRenderSpec. To drop a specific channel, simply pass a CFrameBufferInfo with a null buffer pointer.

This approach can be used in any part of the CFrameBuffersRenderSpec where CFrameBufferInfo is used for:

• Process components

• Spot components

• Alpha channel

• Object map

As this approach requires generating the channel then dropping it, the existing methods for skipping spot components, alpha channel or the object map are preferred for performance reasons, viz.,

• Add spot components to be dropped to the CRenderSpec::ignoredSpotColors list

• If alpha is not required, set CRenderSpec::alpha to false

• If an object map is not required, set CRenderSpec::retrieveObjectMap to false

There are however situations where it may be either convenient or necessary to use this new feature for spots.

MAKO-5840 Apex: Add API to obtain GPU that Apex has chosen

Apex supports multi-GPU systems. IApexRenderer::getGpuInfo() now identifies the selected GPU when no GPU is explicitly specified, returning the same type as IApexRenderer::enumerateGpus().

MAKO-5676 APO: Add support for PDF/X-4

Apex PDF Output (APO), the Apex Performance Pack feature added in Mako 9.0.0, now supports output to PDF/X-4. When using this feature, a PDF is conditioned to comply to the standard, ensuring fonts are fully embedded, color spaces are correctly specified, etc.

MAKO-5859 APO: Add feature to call transforms

The key reason for the extraordinary performance of APO (Apex PDF Output) over Mako’s standard PDF output is that it processes pages in parallel. This change enables customers to take advantage of the threaded nature of APO. With APO, the transform chain applies to pages in parallel, potentially leading to very significant performance improvements.

The new API is

IPDFOutput::setTransformChain(const ITransformChainPtr &transformChain, bool alwaysApply);

The transform chain will be applied to each page being written before other content manipulations take place for PDF output. If alwaysApply is true, the chain will always be applied; if false, the chain will not be applied to pages being written to incremental output that would otherwise need not to be re-written.

• Any transform passed in must be thread safe, as noted in the API documentation.

This API is also available for standard PDF output, but the transforms will run on a single thread.

MAKO-5593 MAKOSUP-11712 Inspect and modify contents of XObjects

The customer wants a way to edit a shared XObject such that every use of the object sees the same changes. To help meet this requirement, a new built-in transform is added, IObjectReplacerTransform(), the use of which is documented in this knowledge-base article.

MAKO-5743 MAKOSUP-11639 Make PCL font selection information visible

A new feature to add a font selection monitor (derived from IPCL5FontSelectionMonitor) that is added to IPCL5Input to obtain font selection information related to a particular IDOMFont.

This knowledge base article describes in detail its purpose and how to use it.

Fixes and other improvements

MAKO-5872 MAKOSUP-11720  Create specialised Windows build

At the request of a customer, a new configuration was added for building a variant of Mako that uses the MinGW-w64 runtime with MSYS2/UCRT64 environment, using GCC 15. See Distribution below.

MAKO-5845 MAKOSUP-11761 PS to PDF conversion leads to incorrect orientation when DynaFont is used

Now fixed.

MAKO-5747 MAKOSUP-11773 (Optionally) work around bad marked content nesting

The PDF specification asserts that marked content and text objects must be nested properly. Despite this, PDFs continue to show up with this rule broken. The customer exhibit is yet another example. Mako already has workarounds in place for this scenario, but in this case, those were not quite enough. An additional workaround has been added, but this feature is enabled only when the MAKO_PDFIN_ALLOW_SPLIT_TEXT_STATES environment variable is set to something non-empty.

MAKO-5841 MAKOSUP-11777 Improve performance when creating / resaving OCR searchable layer

The customer complained of an exponential slowdown when creating/resaving a PDF with an invisible, searchable text layer. Investigation showed that to ensure text lines up with the scanned image, font information was manipulated in a manner that caused a caching bottleneck. Refactoring this code path solved the performance issue and reduced output file size.

MAKO-5830 MAKOSUP-11798 Rangecheck error in pdfmark command

Fixed an issue with the NI pdfmark command in IDistiller.

This was a port from Jaws RIP where the issue was first fixed.

MAKO-5815 MAKOSUP-11835 Regression in PCL5 Import - Missing rectangles and text since MAKO 8.2.0

Investigation showed that the change in behavior was caused by a fix introduced in Mako 8.3.0 that was concerned with HP/GL clipping. That change was not quite complete, as it did not correctly account for text rotation present in the customer exhibit. Now fixed.

MAKO-5805 MAKOSUP-11841 PCL5 Conversion Issue - Missing Horizontal Separator Lines

The missing lines were composed of graphic characters that were absent from the symbol font in use, and the fallback mechanism designed to cope with this scenario failed to select an appropriate alternative. Now fixed.

MAKO-5864 MAKOSUP-11845 Mako crashes when retrieving the media box

The problems experienced by the customer required some refactoring of metadata handling code.

MAKO-5836 MAKOSUP-11846 Processing failed with customer’s test file

The customer exhibit had 60,000 pages, every other one of which had thousands of images and more than a hundred color spaces. Just caching references to these eventually exhausted Mako’s internal memory. Mako now takes a more efficient approach to storing information about the incoming pages, with the result that the job completes and keeps runtime memory usage at a modest level, without detrimentally affecting performance.

MAKO-5844 MAKOSUP-11859 Correct handling of ligatures

A problem reported by a customer uncovered an issue in Mako’s handling of Unicode ligatures containing spaces. Now fixed.

MAKO-5860 MAKOSUP-11864 Crash in IDOMJPEGImage::encode

The JPEG image in the customer exhibit was broken, but Mako was crashing. This is now improved such that the libjpeg exception is passed up to Mako so that in can be caught by user code.

MAKO-5869 MAKOSUP-11875 Error rendering page 661

An obscure font handling issue was fixed.

MAKO-5875 MAKOSUP-11878 Opening a specific PDF ends in error(s)

The customer exhibit is bad; it has marked content (BDC / EMC) and text operators (BT / ET) that are not correctly nested. Although a breach of the specification, PDF consumers often ignore this requirement, including Adobe Acrobat. Mako already has some mitigation in place, but the job in question is particularly bad. To solve this, the workarounds are strengthened but are only switched on when a specific environment variable () is made non-empty.

MAKO-5889 MAKOSUP-11894 PDF fails to import when /Size is wrong

The customer exhibit fails in Mako because the xref table size is declared incorrectly. Mako detects this anomaly, but the repair code needed some improvements to deal with null characters. With this change, the job now processes as expected.

Bug

MAKO-5867 MAKOSUP-11872 How to generate pure Gray PCL/XL output

Before this change, Mako’s PCL/XL output always converted everything to DeviceRGB upstream of the PCL/XL output core. So regardless of the input, RGB is what you would get at the output.

Now you can now choose an output colorspace with a new API, IPCLXLOutput::setTargetColorSpace(). This accepts DeviceGray, DeviceRGB, sGray or sRGB. This change meets the customer requirement that pure gray objects in the input remain so in the output.

MAKO-5833 Apex: Support extended gamut profiles for color conversion

This requirement arose from the need to convert to RGB for a color-accurate on-screen preview of a job rendered in an extended-gamut colorspace, such CMYKOV. This change make it possible to specify a CColorConversionPostProcess to convert from an extended-gamut color space, as the first step.

MAKO-5885 Apex: Add const to the pointer passed to Apex image uploading and shader definition

A customer pointed out that many of the Apex functions take a pointer to data, and that pointer should be declared const. In this change, we have updated the declarations accordingly.

MAKO-5817 APO - Convert restricted fonts to curves

This is an enhancement to APO (Apex PDF Output) that ensures restricted fonts (those that are not permitted to be embedded) are converted to curves. As vectors retain their quality at any zoom level, this is a significant improvement over the standard PDF output that renders such content to a raster.

MAKO-5885 Support C++ .data() expression

Support is added for .data() when accessing the CEDLVector and CEDLSimpleBuffer memory addresses. In C++, you can now write buffer_name.data() instead of &buffer_name[0].

MAKO-5791 Spot color knocks out another spot color

A customer reported a rendering issue whereby a spot color appeared to knock out another spot color. This was caused by inappropriate handling of the DeviceN colorspace that defined the two spots. Mako now renders correctly.

MAKO-5839 / MAKO-5876 Processing causes excessive increase in file size

Both defects caused output file-size growth by preventing XObjects from being identified as reusable, resulting in repeated object duplication. The root causes were distinct: one was due to overprint detection, while the other was due to incorrectly processed image metadata. The issues have been resolved, restoring output file sizes to expected levels.

Distribution

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 9.1.0 is built for the following platforms:

Apple:

• iOS (iOS 6.0 and later)

• macOS (universal binary - x86-64 & ARM64, macOS 11 (Big Sur) and later)

GNU / glibc–based Linux:

• Ubuntu 24.04 LTS

• Mint 22.2

• Debian Bookworm

• Debian Trixie

• 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 (V142), x64 and x86)

  • Found in Windows_VS2019 folder

• Windows UWP

• Windows MinGW-w64

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.