Skip to main content
Skip table of contents

Mako 6.4.1 Release Notes

Introduction

This is a maintenance release that addresses identifiable support issues, labeled MAKOSUP-XXXXX. The link is live and can be followed to the Mako support portal, but it only works for the customer who reported it.

Issues fixed

MAKO-3916

MAKOSUP-10816 Support merging of CID CFF fonts


The exhibit has many embedded fonts and the customer was disappointed that after processing with Mako, the number of fonts remained similar. Mako’s PDF output makes every effort to merge font subsets and eliminate duplicate fonts, but not in this case. This is due to the fonts being CID/CFF (Character Identity / Compact Font Format), which hitherto Mako was unable to merge in the usual way.

This change enables merging of CID/CFF fonts, reducing complexity (Acrobat’s font list now displays in 30 seconds rather than the approximately 10 minutes previously) and file size. The change solves the problem for the customer case.

Merging fonts must be carried out with care to ensure that no information is lost or inadvertently changed. While it has been thoroughly tested, as a precaution you can block CID/CFF merging. To do so, set the environment variable MAKO_DONT_MERGE_CIDCFF to anything, and Mako does not attempt to merge CID/CFF fonts at all.

MAKO-3912

MAKOSUP-10859 Image is reencoded, even with setReencodeImages() set to false


The customer exhibit had an image that was RLE and Flate compressed. After processing with Mako, the image was RLE encoded but not Flate compressed, ballooning the output file size.

To solve this, a new method is added, IDOMPDFImage::getImageTypes() that returns a vector rather than a single value, enabling Mako’s PDF output to correctly encode images with more than one compression scheme.

It has always been the case that images that are LZW compressed cannot be "passed through" to the output when converting to PDF/X or PDF/A, as these standards specifically prohibit LZW. Such images are decompressed and recompressed using Flate compression.

A consequence of this change is that a PDF with an image with multiple compression filters that includes LZW also has to be decompressed and recompressed. If the image includes JPEG compression, which is a "lossy" compression algorithm, decompressing and recompressing may have an impact on quality.

MAKO-3920

MAKOSUP-10882 Transparent images flatten with artifacts


The customer reported poor results when processing PDFs to PDF/X-1a, which requires flattening of transparency, in this case an image with an SMask (soft mask). A problem arises when the image resolution is below that of the rendering resolution of the transparency flattener, which leads to unwanted stepping and image artifacts.

This change attempts to mitigate this kind of case. With this change, and the vector flattener, Mako can detect that an image is sufficiently isolated (on the page) and can flatten it at the image resolution. The file size of the output is smaller as a result, and as there is no scaling there can be no scaling artifacts. This happens only when the resolution of the image content is lower than the target resolution – if it’s higher, Mako still renders to the higher resolution.

This becomes the default behavior, but it can be disabled, for testing purposes perhaps, with:

IRendererTransform::setUseImageResolutionForRenderingWherePossible(false)

MAKO-3870

MAKOSUP-10892 Memory leaks: Investigate client-reported issues found using Valgrind


The customer reported some memory leaks and uninitialized memory warnings from a Valgrind-monitored Mako project. When investigated, these were found to be benign in nature but nonetheless have been addressed in this release.

MAKO-3809

MAKOSUP-10893 Using MakoConverter to optimize PDF Documents- JPEGQuality improvement


The customer exhibit contains many artificial images (for example logos, rasterized text, and so on) that are DCT compressed, otherwise known as JPEG compression. A feature of the algorithm is a technique known as chroma subsampling. Chroma subsampling is desirable for natural images, as it can result in lower file sizes without significantly lowering perceived quality. However, for artificial images such as rasterized text where sharp transitions from one color to another are present, the result can be unwanted artifacts that compromise the perceived quality of image.

To make it possible to strike a better balance between output file size and image quality, a new PDF output setting is introduced in this release. The setting is JPEGChromaSubsampling, which can be set to true or false.

This setting is used in conjunction with JPEGQuality. The default value is true (on) for a JPEGQuality of 1, 2, or 3 and false (off) for a JPEGQuality of 4 or 5. This new setting allows the default to be overridden, for example by setting:

JPEGQuality=3, JPEGChromaSubsampling=false

The combination of these two settings keeps the output file size low without compromising the quality of artificial images. They should be set in the order shown (that is, JPEGQuality first).

MAKO-3907

MAKOSUP-10889 Error in a PDF (MakoDOMPage)


This required working around an invalid ToUnicode CMap stream in a PDF.

MAKO-3913

MAKOSUP-10896 Extraction Problem - Arabic text


The problem the customer saw was due to incorrect handling of "alternate" glyph names. Although the investigation took some time, the solution was straightforward. By allowing alternate names at input, the problems with text extraction and PDF output were solved.

MAKO-3904

MAKOSUP-10901 PDF/X-4 font compliance failure error message


The reason the customer exhibit failed to convert to PDF/X-4 is that there is a character reference to a .notdef glyph. While this is possible in PDF generally, it is prohibited by PDF/X‑4.

It was obvious that the error message Mako produced did not throw any light on the problem, so this has been improved. Such an occurrence now produces an error message that includes the following:

“PDF/X: Regular text references marking notdef glyph – blocking”

MAKO-3830

MAKOSUP-10903 Common names are escaping Mako.lib


The customer reported seeing these link errors when building against the Mako library:

  • error LNK2005: roundup already defined in common.obj
  • error LNK2005: concat already defined in common.obj

Quite rightly, the customer complained that these are common names that shouldn’t be exported from Mako.lib. Now fixed.

MAKO-3911

MAKOSUP-10909 Converting PDF to PS that contains annotation


The customer’s workflow required conversion to Postscript of a PDF with a very high page count. Due to various factors, the conversion was taking an excessive amount of time (several hours in one case). After investigation, improvements were made that reduced processing time to around 30% of the time taken before the change.

MAKO-3839

MAKOSUP-10910 Unable to parse PDF and PS files on ARM


The Linux ARM 32-bit build was referencing a threading library (libdispatch) that is not available on the target the customer was deploying to. This is now removed from the build, replaced by an internal method.

MAKO-3905

MAKOSUP-10911 Mako generates a blank thumbnail


The blank output was the result of incorrect logic in the calculation of visibility of optional content groups. This is now fixed.

The IOptionalContentVisibilityExpression::evaluate() method now returns eOptionalContentVisibility instead of bool. This helps determine when and how groups that should not take part in visibility calculations are handled.

MAKO-3906

MAKOSUP-10915 Odd document rendered blank in viewer, no errors or exceptions thrown


The customer exhibit is another example of a broken PDF that other consumers can cope with, so Mako must too. The file contained several PDF streams where the stream dictionary defined a /Length of 0, but the streams are not zero length. These are now handled appropriately.

MAKO-3875

MAKOSUP-10917 Error while converting PCLXL job to pdf


The customer file triggers an exception because it contains a TrueType font that has multiple tables in the global segment with a signature of zero and length zero, contrary to expectation. Now fixed.

MAKO-3876

MAKOSUP-10919 Unable to open specific PDF - EDL error


The customer exhibit triggered an error in Mako’s PDF input due to incorrect entries in a transparency group Resources dictionary. Specifically, they map DeviceGray and DeviceRGB both to DeviceCMYK, which is invalid. Acrobat appears to ignore these problems and can open the file. Mako now does the same.

MAKO-3908

MAKOSUP-10924 Cannot process watermarked PDF


Now fixed.

MAKO-3871

MAKOSUP-10925 EPS BoundingBox-HiResBoundingBox-CropBox


The customer reported that Mako ignores the HiResBoundingBox DSC comment when it is present in an EPS, which for them led to inaccurate placement when creating impositions. This is now rectified with a new setting, HiResBBox. When set to true (and TrimToBBox or CropToBBox are true), the HiResBoundingBox DSC comment is used for the page size.

MAKO-3910

MAKOSUP-10932 Java 11 support


The customer needed the Mako Java SDK built with Java 11 to meet their development requirements. We obliged and included it in the distribution for this release as a separate build, in the folder Windows_SWIG_(C#-Java11-Python).

MAKO-3909

MAKOSUP-10937 Azure Mako NuGet package function crashing in RELEASE BUILD, works totally fine in DEBUG BUILD.


The customer’s project is C# running in Azure.

The issue turns out to be that the RandomAccessStreamReader object is being garbage collected while it is still being used. In Release builds, .NET is not waiting for the object to go out of scope but instead decides that it is not used anymore and gets rid of it. When this happens during the conversion, a crash results.

As this occurs on Release builds, but not Debug, it's likely that this is due to debug builds being less aggressive in their garbage collection.

The solution is a code change to an enclosed using statement, for example:

C# 
using (var inputStream = new RandomAccessStreamReader(inputFileStream))
{
    // Rest of code here
}

It was also found that simply referencing inputStream after the conversion code also prevented garbage collection.

Although this did not require a code change in Mako, it is useful to call this out in these release notes for the benefit of other Mako C# developers.

MAKO-3931

MAKOSUP-10940 PDFX/4 compliant file fails with typecheck error

The customer exhibit was technically an invalid PDF, specifying an /OPM resource as 1.0. The PDF specification states the overprint mode (OPM) must be an integer, but here it is a real value. Mako’s input has been relaxed to accept a real value, converting to an integer as required, rather than rejecting it and throwing an exception.

New or improved features

MAKO-3902

MAKOSUP-10930 Retrieve "User Output Signals" from IJPDS file

This change adds support for reporting the UserOutputSignals flags from the SDC record of an IJPDS document.

This information is treated in a similar way to the InputPageNo and RipNo, which is to say is recorded and passed along. The information is available in two ways:

  • Via API calls from the IIJPDSPageRaster object
  • Via the properties in IDOMFixedPage

The implementation is limited to obtaining this information from the SDC record, as no test file with a SOD record was available during development.

This code example shows retrieving the value for the first page, using two methods:

CPP 
#include <jawsmako/ijpdsinput.h>
IIJPDSInputPtr pdfInput = IIJPDSInput::create(jawsMako);
IPagePtr page = pdfInput->open("mako_text.ijp")->getDocument()->getPage(0);

// Retrieve the UserOutputSignal from the IIJPDSPageRaster object via dedicated API
IPageRasterPtr pageRaster = page->getPageRaster();
IIJPDSPageRasterPtr ijpRaster = obj2IIJPDSPageRaster(pageRaster);
uint16 userOutputSignalsFromPageRaster = ijpRaster->getUserOutputSignals();

// Retrieve the UserOutputSignal from the IDOMFixedPage object via its properties
const IDOMFixedPagePtr fixedPage = page->getContent();

uint16 userOutputSignalsFromFixedPage = 0;
PValue propValue;
fixedPage->getProperty("UserOutputSignals", propValue);
if (propValue.getType() == PValue::T_INT)
    userOutputSignalsFromFixedPage = propValue.getInt32();

Distribution

MAKO Version 6.4.1 is built for the following platforms:

  • iOS
  • macOS
  • Linux (for Debian-based distributions; for example, Ubuntu, Mint)
  • Linux (Centos)
  • Linux (Red Hat Enterprise v7.0)
  • Linux (Red Hat Enterprise v8.4)
  • Linux (for Debian Buster) (ARM32 for Raspberry Pi)
  • Linux (for Debian Stretch)
  • Linux (for Debian Bullseye)
  • Linux (for MUSL distributions; for example, Alpine Linux)
  • Linux (for Ubuntu 20.04 LTS)
  • Windows (static and dynamic libs, VS 2019 (V142), x86 and x64)
  • Windows (static and dynamic libs, VS 2017 (V141), x64)

The Android build has been dropped from this release pending a tooling change. Please contact Mako support if you need a Mako release for Android later than Mako 6.1.0.

Mako supports the following programming languages:

  • C++ (Mako is written in C++)
  • C# (.Net Core and .Net Framework)
  • Java (built with OpenJDK11)
  • Java (built with OpenJDK15)
  • Python (v3.8)

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

  • Linux_SWIG_(C#-Java-Python)
  • Linux_SWIG_(C#-Java11-Python)
  • Linux_Centos7_SWIG_(C#-Java-Python)
  • Linux_Centos8_SWIG_(C#-Java-Python)
  • Linux_Ubuntu_SWIG_(C#-Java-Python)
  • macOS_SWIG_(C#-Java-Python)
  • Windows_SWIG_(C#-Java-Python)
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close