Skip to main content
Skip table of contents

Mako 6.6.3 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 only works for the customer who reported it.

Issues addressed

MAKO-4252

 

MAKOSUP-11080 Performance issue converting PDF to PostScript

Implementing a new feature to cache images when writing to PostScript (as Mako already does for PDF) reduced processing time for the customer exhibit from 5 hours to 7 minutes.

MAKO-4321

 

MAKOSUP-11100 Huge memory usage when processing a PDF

The customer exhibit has PDF forms (XObjects) that are cached for later reuse. However, the large number of these caused memory use to grow excessively, causing a problem. The change made to alleviate this issue extends the IJawsMako::freeMemory() API to also clear form cache(s). While this may mean form reuse is reduced, the memory saving is significant: for the customer case, a ~75% saving.

MAKO-4338

 

MAKOSUP-11104 PCL to PDF conversion

There were two issues, both concerning Intellifont fonts. The first was a poorly formed font that triggered an error, which Mako now works around. The second issue required creating a new Hebrew symbol set to map to, allowing the customer files to convert correctly.

MAKO-4339

 

MAKOSUP-11105 Jaws Panic in Mako x86 build

An assertion seen in the debug build is now fixed.

MAKO-4341

 

MAKOSUP-11107 Problem rasterizing PDF with MAKO

A problem with painting a shading pattern, within a tiling pattern, that used unusually large matrix values was fixed to solve this customer issue.

MAKO-4354

 

MAKOSUP-11114 Rendering fails Internal RIP error: PS limitcheck

The fix required an implementation of a function to copy a specific object type found in a color space.

MAKO-4369

 

MAKOSUP-11121 Problem rendering PDF with transparency in CMYK profile

The fix required an improvement to CMYK rendering with an alpha channel plus spot colors (RGB was OK).

MAKO-4409

 

MAKOSUP-11122 Get and set XMP using the attached PDF fails to write original XMP

This issue arose because Mako deliberately excludes XMP properties that fall outside the predefined schemas in the XMP specification (or the ISO specifications for PDF/X, PDF/A, and so on) when writing to the output.

To allow a customer to override this behavior, the following output option is now available, and can be set with either of these two methods:

  • Set IPDFOutput::setValidateXmp()
  • Set with a parameter: IPDFOutput::setParameter()

Code example:

CPP 
const IPDFOutputPtr output = IPDFOutput::create(m_jawsMako);
output->setParameter("ValidateXmp", "false");

or

CPP 
output->setValidateXmp(false);

MAKO-4411

 

MAKOSUP-11130 Problem rendering ai file RGB + alpha

This rendering issue is now fixed.

MAKO-4401

 

MAKOSUP-11132 Enlarging page boxes does not update the UserUnit value without a document reload

By design, Mako does not update the page dictionary UserUnit (the scaling value for oversized pages, introduced in PDF 1.6) as it is only required for PDF output. To solve this, a new convenience function, IPage::getUserUnit() is added which recalculates UserUnit, returning the value that is present when the PDF is written.

MAKO-4436

 

MAKOSUP-11137 Protect against file deletion/modification of open inputs on macOS

The customer wished to protect against the user throwing away or modifying a PDF that they have opened with Mako, on macOS. Although it was thought this may not be possible with the POSIX semantics used by macOS, it was found that by using chflags(), Mako can set a file as immutable, thereby preventing deletion or overwriting.

This setting is off by default, and must be enabled manually by using

CPP 
IJawsMako::lockOpenFiles(true)

while there are no files open in Mako. This setting has no effect on operating systems other than macOS.

MAKO-4431

 

MAKOSUP-11138 Modifying the Media Box inserts a transformation

Due to the architecture of Mako (which uses a coordinate space that originates top left versus that of PDF that originates bottom left) a top-level transformation is added to a page. The customer discovered that manipulating the media box (with the IPage::setMediaBox() API) resulted in proliferation of parent transformations. This is now addressed, and a single transformation is updated as required.

MAKO-4325

 

MAKOSUP-11139 PostScript input with Type 32 fonts - Can they be handled in PDF/XPS output?

This release implements support for Type 32 fonts, which are bitmap fonts. Internally, they undergo a conversion to a supported font type compatible with PDF or XPS output.

MAKO-4434

 

MAKOSUP-11143 Error: undefined; OffendingCommand: @PDFopexec

Fixed two issues relating to soft masks. The customer exhibit now renders correctly.

MAKO-4450

 

MAKOSUP-11145 PDF/X Non-UTF8 colorant names

An issue often seen in PDF is non-UTF8 colorant names. The PDF specification merely recommends UTF8 encoding for names of spot colors, and consequently authoring tools are free to use alternatives, which often reflect the operating system or locale on which they are installed. ISO standards such as PDF/X-4 attempt to address this shortcoming by stipulating spot color names be encoded as UTF8, which means that Mako may need to convert the string. This change adds a new feature to PDF output, enabled by default, whereby Mako automatically fixes non‑UTF8 names, selecting an appropriate encoding based on the character codepoints encountered.

Should the result be incorrect, control over the choice of encoding is provided as a fallback, by way of a parameter setting for IPDFOutput() that can be set with either of these two methods:

  • Set IPDFOutput::setNonUtf8InkNameFallbackEncoding()
  • Set with a parameter: IPDFOutput::setParameter()

Code example:

CPP 
const IPDFOutputPtr output = IPDFOutput::create(m_jawsMako);
output->setParameter("NonUtf8InkNameFallbackEncoding", "MacRoman");

or

CPP 
output->setNonUtf8InkNameFallbackEncoding(eIFEMacRoman);

MAKO-4451

 

MAKOSUP-11146 IRenderTransform “tearing”

This issue was caused by a poorly defined “hint” (the font mechanism that improves glyph appearance when rendered at low resolutions) which caused the dot above an "i" to spread upwards. The problem was identified and a workaround implemented.

MAKO-4463

MAKOSUP-11153 Wrong rendering of PostScript document

The customer exhibit featured what appeared to be boxes filled with a solid color, but were actually constructed of numerous scan lines, alternately colored and white. Due to this unusual arrangement, different resolution rendering produced different results; sometimes solid, sometimes banded or occasionally disappear altogether. The underlying problem was identified and fixed.

MAKO-4464

MAKOSUP-11155 Error: [jawsmako/metadataunpackers.cpp:469] Undefined

Mako signalled an error while processing a PDF that itself had previously been processed by Mako. The problem was identified and fixed.

MAKO-4461

 

Use #pragma comment to load libraries in Windows builds

In response to a customer request, two Windows libraries used by Mako (ws2_32.lib and rpcrt4.lib) are now loaded by a #pragma comment in the relevant header file.

This means they do not need to be included in the build properties of a Visual Studio project (Linker/Input/Additional Dependencies). This change applies only to Windows.

MAKO-4372

 

Unit test failures – TrueType fonts.

This internally reported issue was caused by a broken font included in macOS Ventura, so this may be relevant to some customers. The issue was fixed by detecting the error and generating correct information from the font’s CMap (character map).

Known issues in this release

There are two minor PostScript conversion issues that were found during release testing that we have decided to release with:

  1. When testing PostScript to PDF. A possible invalid font error when converting Type32 to Type10 (see MAKO-4325 above), but as Type32 fonts are rarely used we considered this to be low risk.
  2. When testing PostScript to XPS. We saw some sup-optimal pattern rendering results.

Should you encounter any issues with these conversion paths, please raise a support ticket in the usual way.

Distribution

MAKO Version 6.6.3 is built for the following platforms:

  • iOS
  • macOS
  • Linux (for Debian-based distributions; for example, 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; for example, Alpine Linux)
  • 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 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_Centos8_SWIG_(C#-Java-Python)
  • macOS_SWIG_(C#-Java-Python)
  • Windows_SWIG_(C#-Java-Python)
  • Windows_SWIG_(C#-Java11-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