Mako 6.3.0 Release Notes

Introduction

These release notes are presented in terms of the development tasks (MAKO-XXXX) that had to be undertaken to complete this release. Only items of significance – those that add new features / improvements in this release or address identifiable support issues (labeled MAKOSUP-XXXXX) – are included.

MAKO-3527

Integrate ColorLogic CMM into Mako

ColorLogic are renowned for their color expertise, embodied in their products such as ColorAnt, CoPrA ,and ZePrA.

These products are built with their own SDK, which we have used to build a version of Mako that makes use of this for all color conversions, rather than the default of LittleCMS.

For the Mako 6.3.0 release, the ColorLogic builds of Mako remain in beta but are otherwise equivalent to the standard (LittleCMS-equipped) builds, to allow for meaningful testing.

Please contact your Global Graphics account manager to arrange access, should you need them.

It is anticipated that the ColorLogic build will become a standard feature of the Mako distribution in future versions.

MAKO-1328

Provide easy methods for creating path geometry – XPS style

With Mako, it’s possible to add new content to a page, or even create a document from scratch. APIs exist for adding text and images, but until now, creating arbitrary vector content – open and closed paths consisting of lines and curves – has required many lines of code.

To solve this problem, Mako now supports XPS abbreviated geometry syntax. The method IDOMPathGeometry::create() acquires a new signature, whereby a string of abbreviated instructions can be passed. For example:

CPP

IDOMPathGeometry::create(mako, "M 100,100 L 300,100 L 200,300 z");

Further details can be found in the online documentation. A benefit of this approach is that this syntax is also used in .NET, specifically for graphics described in XAML. A Mako C# example that exploits this relationship is available on GitHub. It interprets an XAML graphic that is added to a page then saved as a PDF.

MAKO-3611

Provide easy methods for creating path geometry – PostScript style

A new interface, IDOMPathGeomteryBuilder, is also introduced. It can be used to construct geometry with PostScript-style commands using the following member functions:

moveTo() : Move to the given user point
lineTo() : Line to the given user point
curveTo() : Bezier curve to the given user point with the given control points
quadCurveTo() : Quadratic curve to the given user point with the given control point
arcTo() : Arc to the given user point with the given radius, rotation and sweep parameters
close() : Close the sub path if it is not already
createGeometry() : Create an IDOMPathGeometry from constructed path with the given fill rule

CPP

IDOMPathGeometryBuilderPtr geometryBuilder;
geometryBuilder->moveTo(FPoint(100,100));
geometryBuilder->lineTo(FPoint(300,100));
geometryBuilder->lineTo(FPoint(200,300));
geometryBuilder->close();
IDOMPathGeometryPtr geom = geometryBuilder->createGeometry(IDOMPathGeometry::eFREvenOdd);

MAKO-3461

Support PPML as an input to Mako

(Includes MAKO-3485, MAKO-3486, MAKO-3487, MAKO-3501, MAKO-3526)

A third-party development of a PPML 2.1 converter, developed using Mako, is integrated into Mako 6.3.0 as a new input class, IPPMLInput().

The class expects a ZIP package that conforms to the PPML 2.1 specification from PODi. This is a legacy format that is no longer widely used; adding this to Mako makes it possible to convert legacy content to PDF (or any of the Mako-supported output PDLs), or just rasterize it.

The makoconverter example has been updated to recognize .zip as a PPML package, so this command line can be used to convert from PPML to PDF:

makoconverter.exe multipage-tiff-0006.zip multipage-tiff-0006.pdf

PPML 3.0: Support for PPML 3.0 is not currently included but could be added should a Mako OEM require it.

MAKO-3358

Get name(s) of color channels

Most ICC profiles have three (RGB) or four (CMYK) channels but a profile for an extended gamut may have more (for example, CMYKOGV). To help identify the additional channels, a new method is added to IDOMColorSpace to return colorant names, if they are available in the ICC data, which the following C++ code snippet shows:

CPP

// Create a colorspace from the ICC profile
IDOMColorSpacePtr iccBasedColorSpace = 
	IDOMColorSpaceICCBased::create(jawsMako, 
		IDOMICCProfile::create(jawsMako, 
			IInputStream::createFromFile(jawsMako, "myIccProfile.icc")));

// List the process color names
for (uint8 i = 0; i < iccBasedColorSpace->getNumComponents(); i++)
    std::cout << iccBasedColorSpace->getColorantName(i) << std::endl;

MAKO-3478

ISeparator - convert Type 1 shading patterns

Introduced in Mako 6.1.0, Mako’s ISeparator class generates color separations, not as bitmaps but as new fixed pages, thus retaining their object nature. This work improves the handling of shading patterns, which are now separated without the need to render them.

MAKO-3479

ISeparator - convert DeviceN shading patterns

Continuation of the improvements to shading pattern handling in ISeparator, this time to support DeviceN shading patterns

MAKO-3480

ISeparator - convert shadings with overprint

Continuation of the improvements to shading pattern handling in ISeparator, this time to support shading patterns with an overprint setting

MAKO-3481

ISeparator - convert XPS linear and radial gradients.

Continuation of the improvements to shading pattern handling in ISeparator, this time to extend support to XPS linear and radial gradients

Release testing indicates that this feature may not work as expected. The issue observed is confined to XPS and does not affect PDF.

MAKO-3297

Lines in ISeparator output for AltonaVisual_1v2a_pt1com_x3.pdf

The improved support for shadings added to ISeparator, allowing for improved color-separation of the types of shadings seen in the exhibit, solves issues observed with the Altona suite example AltonaVisual_1v2a_pt1com_x3.pdf that resulted in artifacts from a rasterization process that are now avoided.

MAKO-3528

IJPDS: Direct to Raster

This is a significant feature addition to the IJPDS input class introduced in Mako 5.2.0. This feature was released in Mako 6.2.3, but as some OEMs may have missed it, is included here.

A new class, IPageRaster, offers a faster method to get from a Mako input to raster output. It is essentially a generic framebuffer class that is returned by IPage::getPageRaster(). The caller can use this to obtain rasterized content instead of IPage::getContent(), which returns an IDOMFixedPage.

This is optional for every PDL, but currently only IIJPDSInput supports it. The IPageRaster class has enough information so that the caller can write it as an image. Sample code included in makoconverter.cpp shows how to do this.

For the public IJPDS interface, an IJPDSPageRaster class (which inherits from IPageRaster) has been added so that the caller can get extra information like the input page number and RIP number.

MAKO-3447

IJPDS: Return additional job information

The customer expects the count of pages to be the same as the number of input pages on the job, regardless of the number of RIPs. Mako generates one page for each page/RIP combination, so it doesn't always match that expectation.

Providing the customer can find out the total number of pages and number of RIPs, then they can calculate the number of input pages – it is then simple math to map from [inputPageNo, ripNo] -> pageNo

To support this easily (without breaking the API) new properties are added to the IDOMFixedPage class. The properties are:

Property	Type	Information returned
`InputPageNo`	`PValue::T_INT`	The input page number, starts at `0`
`RipId`	`PValue::T_INT`	The RIP number, starts at `0` but can be `-1`, which indicates a blank page
`ResX`	`PValue::T_INT`	Job X resolution
`ResY`	`PValue::T_INT`	Job Y resolution

CPP

IDOMFixedPagePtr fixedPage = page->getContent();
PValue propertyValue;
fixedPage->getProperty("InputPageNo", propertyValue);
int32 inputPageNo = propertyValue.getInt32();

The total number of output pages is returned by getNumPages().

To get the number of RIPs in the job, loop through the first few pages and count the number of pages whose InputPageNo is 0. This yields the number of RIPs.

A modified makoconverter.cpp is available that illustrates how a mock Array interface can get the required information from Mako.

MAKO-3609

IJPDS Allow any random page to be re-rendered even after page release

In the initial implementation of IJPDS Direct to Raster, it wasn’t possible to retrieve a page raster a second time that would allow a job to be restarted from any page.

This is now permitted.

MAKO-3618

MAKOSUP-10823 IJPDS crash when calling getContent() and getPageRaster() on the same page object

Now fixed.

MAKO-3583

IJPDS Support page rotation natively in IPageRaster output

Work to improve performance of rotation of rasters extracted from IJPDS input

MAKO-3469

IJPDS: Characters missing from mako_mark_knockout.ijp output

A character was being omitted from the output due to an optimization of ROP (raster operations) code. Now fixed.

MAKO-3465

IJPDS: Stitched output should not have a fixed page length

An issue with the IJPDS input class, IIJPDSInput. The exhibit (vendor.ijp) reported an incorrect page size when stitched. Now corrected.

MAKO-3507

IJPDS: Incorrect page size when stitched and rotated 90° or 270°

An issue with the IJPDS input class, IIJPDSInput. The exhibit (vendor.ijp) reported an incorrect page size when rotated to landscape. Now corrected.

MAKO-3514

IJPDS input: Text incorrectly positioned when stitched and rotated

When processing the exhibit (vendor.ijp) to PDF with stitching and rotating applied, it was found that some text may be incorrectly positioned at the bottom of pages 5, 6, 7, and 8. This occurs when stitching vertically and rotating 270 degrees, and when stitching horizontally and rotating 180 degrees. Other combinations do not appear to be affected. Now fixed by an adjustment to the layout calculation.

MAKO-3536

IJPDS: Fix unit test failures when running on Windows x86

IJPDS processing requires a lot of memory and is not recommended for running as a 32-bit process. In this instance, certain unit tests were setting the IIJPDSInput() parameter retainpagecontents unnecessarily; turning this off solved the problem (at the expense of performance, of course). Parameters such as this are set as follows:

CPP

IInputPtr = IInput::create (m_jawsMako, eFFIJPDS);
input->setParameter ("retainpagecontents", "1");

MAKO-3553

IJPDS: IJPIn_InputPageNo_RipId.ByRipRot90 intermittently fail on macOS

This was found when running the unit test 1000 times; at round 800 iterations an exception occurred. The issue was tracked down to an incorrect memory allocation. Now fixed.

MAKO-3654

IJPDS: Crash when rotating mako.ijp and Test1.ijp through 270 degrees

Caused due to insufficient bounds checking. Now fixed.

MAKO-3597

Add an API to IDistiller to apply password security to the PDF

To meet a customer requirement that enables password-based security (user password or owner password) plus security settings to be applied to a PDF converted from PostScript, additional parameters and a new API are added to IDistiller. To use in code:

CPP

IDistiller::setEncryption(owner_password, user_password, permission_flags);

Both passwords are supplied as UTF8 strings. The user password, when set, is required to open the document. The owner password protects the security settings and is the same as the user password if only the latter is supplied.

The permissions flag is set with a uint32 with the appropriate bits set, or alternatively use an IDOMStandardPDFSecurityInfo::ePermissionFlags object, for example:

CPP

auto permission_flags = IDOMStandardPDFSecurityInfo::ePermissionsFlags::eEverythingAllowed;

See the Mako API documentation for further details.

Passwords and permission flags values can also be set with IDistiller::setParameter().

Using MakoDistillerCmd command-line switches:

-dso : Set the ownerpassword string.

-dsu : Set the userpassword string.

-dsp : Set the permissions flags integer.

The permissions flags defaults to 0xFFFFFFFC or -4 decimal. See the PDF spec for details of bit meanings. The permissions integer must be specified in decimal.

A version of MakoDistillerCmd, ready-built for Windows x64, is included in the Mako distribution. Source code is provided for building for other platforms.

MAKO-3596

Add API to IDistiller to allow PDF metadata to be set

To meet a customer requirement that enables the Title, Author, or Subject of a PDF to be set when converting from PostScript, additional parameters are added to IDistiller for setting metadata. To use them in code:

CPP

IDistiller::setParameter("author",  "string_representing_the_author");
IDistiller::setParameter("subject", "string_representing_the_subject");
IDistiller::setParameter("title",   "string_representing_the_title");

Using MakoDistillerCmd command-line switches:

-dA : Set the Author string.

-dS : Set the Subject string.

-dT : Set the Title string.

A version of MakoDistillerCmd, ready-built for Windows x64, is included in the Mako distribution. Source code is provided for building for other platforms.

MAKO-3430

Update libjpeg library to libjpeg-turbo to improve decoding/encoding performance

Implemented on Mako’s major platforms (Windows, macOS, Linux) the introduction of libjpeg-turbo offers a significant increase in decoding and encoding performance. Results vary but informal testing indicates this is a worthwhile improvement.

MAKO-3648

Windows SWIG build has an unexpected dependency on a VC runtime

These are now built against the releasestatic versions of Mako’s Windows libraries to eliminate this dependency.

MAKO-3619

SWIG C# generated interface for IUserStreamWriteCallback::userWrite() has internal SWIG type

Before this change, these classes were unusable, as they referenced inaccessible internal types:

C#

IInputStream.createFromRAUserFunc()
IInputStream.createFromUserReadFunc()
IOutputStream.createFromUserWriteFunc()

This is now fixed. A C# sample that shows them in use can be found on GitHub.

MAKO-3443

Remove use of variable arguments in IDOMColor::create()

This is a “tidying up” of the IDOMColor::create() method that was necessary to ensure consistency with other bindings, such as C# and Java. Previously, it was possible to provide a variable number of arguments, to match the number of color channels of the specified colorspace. As these vary by color space, a variable number of values could be supplied, and it was up to the caller to make sure the correct number of values was added. Now, the number of component parameters can be 1, 2, 3, 4, 5, 6, or 32 and are treated in this way:

1-6 parameters: Checks that the number of components passed in match the number of components required by the colorspace (gray, RGB, CMYK, CMYKOG, and so on)
32 parameters: A minimum of 7 components, the rest are optional with a default value of 0.0. This variant does NOT check the number of components required by the colorspace.

The IDOMColor::createFromVect() and IDOMColor::createFromArray() methods are unchanged.

While this change does not require user code adjustment, it is possible that an exception is thrown by existing code that happens not to supply the correct number of component value parameters to calls of this method.

Support issues fixed

MAKO-3529	MAKOSUP-10522 Linux arm support Mako 6.3.0 sees a new build added to the Linux folder, GNU_Linux-x32_Debian_Buster. This is a 32-bit build for the Cortex A9 CPU, which suita the customer who made the request. It also runs on a Raspberry Pi.
MAKO-3001	MAKOSUP-10545 Support opening and reading of multichannel TIFF files A customer reported an error attempting to read data from a TIFF file in Mako. Investigation revealed that the exhibit was a multichannel TIFF file (that is, separated CMYK + extra channels) that Mako was not configured to accept. This change solves that problem. An additional parameter, `allowMultiChannel`, is added to `IDOMTIFFImage::create()`. It defaults to `false` and must be set to `true` to open a multichannel TIFF. (An exception is thrown if an attempt to open a multichannel TIFF is attempted without this parameter set to `true`.) Once the image is opened, an `IImageFrame` can be retrieved; from this, the number of channels can be obtained and if required, a `DeviceN` colorspace constructed from the available colorant information. If an ICC profile was included in the TIFF, this is set as the alternate colorspace (of the `DeviceN` space). If one of the extra channels is an alpha channel, the TIF specification mandates that this is always the last of the extra channels. This code snippet shows PNG previews being written out for each channel found in the multichannel TIFF: CPP // Open Mako IJawsMakoPtr mako = IJawsMako::create(); mako->enableAllFeatures(mako); // Load the image U8String imagePath = "multichannel.tif"; IDOMImagePtr image = IDOMTIFFImage::create(mako, IInputStream::createFromFile(mako, imagePath)); try { (void)image->getImageFrame(mako); } catch (IError& e) { if (e.getErrorCode() == EDL_ERR_IMAGE_DECODE_FAILURE) { // Retry with multi-channel switch set to true image = IDOMTIFFImage::create(mako, IInputStream::createFromFile(mako, imagePath), 0, true); } } // Get the image frame auto frame = image->getImageFrame(mako); auto deviceN = frame->getColorSpace(); // Separate out for checking for (uint32 i = 0; i < frame->getNumChannels(); i++) { IDOMImagePtr separated = IDOMFilteredImage::create(mako, image, IDOMImageChannelSelectorFilter::create(mako, IDOMImageChannelSelectorFilter::eSelectChannel, (uint8)i)); // Encode to PNG for manual checking. char fileNameBuff[32]; _sprintf_p(fileNameBuff, sizeof fileNameBuff, "Image_%u.png", i + 1); IDOMPNGImage::encode(mako, separated, IOutputStream::createToFile(mako, fileNameBuff)); }
MAKO-3183	MAKOSUP-10572 Mako: Object too small to be rendered by Jaws Before this change, Mako’s internal RIP (Jaws) was restricted to a page size of 1x1 point (a point = 1/72^nd inch) and would throw an exception when rendering objects smaller than that limit. In Mako we allow for smaller sizes, so this change removes the previous limits, enabling very small objects to be rendered, thereby eliminating the exceptions.
MAKO-3472	MAKOSUP-10680 IJawsRenderer::renderSeparations() performance with specific TIFF is worse when multi-threading than on single thread There were two significant factors affecting the customer’s job. The first was the presence of a Photoshop-specific TIFF tag that Mako was reading unnecessarily. The second was that when dividing the job between threads, each thread was having to decode all the image to reach the data it needed, meaning that threading simply added overhead and made processing slower. This change for Mako 6.3.0 does two things to improve the situation: A modification to the TIFF reader to skip the Photoshop tag, reducing the opening of the exhibit to a negligible amount of time Implementation of `skipScanLines()` for TIFF, enabling threading to improve overall performance For TIFF, skipping scan lines really means skipping to the next strip (which is image-dependent) but for this job- where the images are stored in 7-scanline strips - it’s very effective.
MAKO-3446	MAKOSUP-10758 ISeparator issue: Path converted to image `ISeparator()` uses the renderer transform to flatten transparency prior to separating. This can result in vector objects included in transparency being rasterized. The customer wanted a vector path preserved after separating. Mako 6.2.0 introduced a vector-based transparency flattening feature, for composite color. Mako 6.3.0 extends this capability to `ISeparator`, by adding two API functions that correspond to the equivalent `IRendererTransform` settings to enable vector flattening: CPP `setEnableVectorMode(bool enable); setRasterFallbackThreshold(uint32 threshold);` `setEnableVectorMode()` enables the feature. `setRasterFallbackThreshold()` controls automatic fallback to raster behavior when excessive complexity is detected. The threshold specifies the maximum number of generated objects per square inch; when exceeded for any individual flattened/rendered area, the process falls back to rasterizing that region.
MAKO-3533	MAKOSUP-10759 getPageText from pagelayout returns texts without space Mako’s `IPageLayout` APIs enable text to be retrieved from a page. Unlike authoring formats, PDFs do not typically contain space characters; the space between words is inferred from the “advance” – the amount of horizonal space between one character and the next. Depending on the nature of the source material, this interpretation may or may not be accurate, and for the customer exhibit, text was returned that had no spaces between words. This change introduces two APIs that allow the text interpretation to be “tweaked” – adjusted to suit the source material. They are: CPP `IPageLayout::setVirtualSpaceThreshold(double virtualSpaceThreshold) IPageLayout::setMultipleSpaceMode(bool multipleSpaces)` The first sets a threshold that controls whether the horizontal advance between two adjacent characters should be considered a space. The second determines if a wider gap between characters should be considered to be multiple spaces, or just a single space.
MAKO-3467	MAKOSUP-10763 SigSev error while rendering a PDF When processing the customer exhibit, a rounding-to-zero error in font matrix calculation eventually leads to an uncaught exception being thrown. The unusual circumstances under which this occurred are now handled appropriately.
MAKO-3510	MAKOSUP-10770 Missing glyphs regression This issue concerned the customer’s workflow that involved first processing a PDF with Mako, then rendering the result with Mako. An error in the initial PDF processing led to a character being dropped during subsequent processing and therefore missing from rendered output. Now fixed.
MAKO-3508	MAKOSUP-10771 Mako IDistiller does not use internal fonts when using external fonts This is a new feature to enable `IDistiller` to use both in-memory and disk-based resources when setting a `%font%` or `%resource%` device with `setFontDevice()`or `setResourceDevice()`, respectively. Previously, `IDistiller` behaved in the same way as its predecessor, Jaws PDF Library. When setting a disk-based font/resource device, only the files present on disk would be used, overriding the internal `%font%` or `%resource%` devices that would be ignored. This change means that Mako first looks for a font or resource on disk, then falls back to the internal font or resource devices if it is not found. This provides more flexibility, as users may only need to add/modify specific resources. Before this change, this would have required all of the resource files to be on disk.
MAKO-3513	MAKOSUP-10772 Work around a bad reference to a non-existent annotation The customer-supplied exhibit is a poorly-constructed PDF containing an annotation array entry that is a reference to an object whose xref offset is zeroed out. Mako’s PDF input class rejects the file because of the bad reference. However, as Acrobat can open the file, the customer would like the job to process. The fix is a modest modification to first throw a more appropriate exception, then in the annotation code catch that exception and (like Acrobat) treat the reference as though it were a null. The job now processes normally.
MAKO-3521	MAKOSUP-10781 ICC profile 4.3 not supported by PDF/X-4 The customer wishes to allow ICC 4.3 profiles to be embedded in PDF/X-4 documents. A strict reading of the specification says that this is not allowed, but there is a bit of a gray area here. However, we are happy to oblige. This change adds a new API to PDF output to control this: CPP `IPDFOutput::overrideMaximumICCVersion(uint32 majorVersion, uint32 minorVersion)` Alternatively, associated `setParameter()` parameters can be applied: CPP `IPDFOutput::setParameter("OverrideMaximumICCVersionMajor", "true"); IPDFOutput::setParameter("OverrideMaximumICCVersionMinor", "true");` For non-PDF/X-4 (and PDF/A-2b), if Mako decides that an ICC profile is too new for the given PDF version, it is color-converted to something else, depending on configuration. However, for PDF/X-4 (and PDF/A-2b), Mako rejects the job instead. This new API simply allows the OEM to raise the limits beyond our defaults.
MAKO-3541	MAKOSUP-10785 Mako returns swapped mediabox for some PCL5 documents The dimensions of a built-in page size were expressed in the wrong order. Now fixed.
MAKO-3540	MAKOSUP-10786 Mako returns A4 mediabox instead of the document-defined size This issue concerned PCL and PCL/XL documents that set a media size unknown to Mako. In this situation, Mako would set the media size to A4 and not indicate that the size expressed in the document had been overridden. Two changes were made to address this: The media size is set to the values set by `IPCLXLInput::setDefaultPaperSize()` A new interface, `IMediaHandler`, is added to interrogate or alter the page size when a PCL media size is unknown. The media handler can be set for both PCL5 and PCL/XL input with `IPCL5Input::setMediaHandler()` or `IPCLXLInput::setMediaHandler()`. A simple example follows, showing how this can be used: CPP class CTestMediaHandler : public IMediaHandler { public: void sizeRequest(const PValue& size, double& pageWidth, double& pageHeight) override { switch (size.getType()) { case PValue::T_INT: printf("Unknown MediaSize: %d\n", size.getInt32()); break; case PValue::T_STRING: printf("Unknown MediaSize: %s\n", size.getSysString().c_str()); break; default: break; } } }; ... CTestMediaHandler mediaHandler; IPCLXLInputPtr pxlInput = obj2IPCLXLInput(input); if (pxlInput) { pxlInput->setMediaHandler(&mediaHandler); } IPCL5InputPtr pclInput = obj2IPCL5Input(input); if (pclInput) { pclInput->setMediaHandler(&mediaHandler); } ...
MAKO-3653	MAKOSUP-10798 Vector-based transparency flattener fails Vector-based flattening, enabled with `IRendererTransformPtr::setEnableVectorMode()`, failed for the customer's exhibit with unwanted artifacts appearing. Now fixed.
MAKO-3561	MAKOSUP-10804 Fixing font problems This change allows customers to disable the generation of `3,0 cmap` subtables for symbolic fonts and remove `notdefs` from output These are features that are used by most flavors of PDF/A and PDF/X. The customer wishes to get rid of warnings raised by preflighters, and here we provide the machinery to eliminate warnings about `notdef` use and symbolic fonts with multiple `cmap` subtables. These are broken out as discrete APIs, so the customer can enable these features without having to write PDF/A or PDF/X. They are: CPP `IPDFOutput::setBlockNotdefGlyphs(bool blockNotdefGlyphs) IPDFOutput::setEmit30CmapSubtableForSymbolicTrueTypeFonts(bool emit)` The default for the first is `false`, and the default for the second is `true`. There are equivalent `IPDFOutput::setParameter()` versions available. When `setBlockNotdefGlyphs (true)` is used, some PDF jobs which use marking `notdef` characters will error. An exception is raised that contains in the message: “CID text references marking Glyph ID 0 - blocking” or an invalid font error, depending on where in our code the issue is spotted. Both settings are ignored for PDF/X and PDF/A.
MAKO-3572	Mako’s `IPDFOutput` class endeavors to merge fonts and font subsets when writing a PDF that may have been combined from more than one source, as in this case. However, the result appeared to contain two fonts with the same name, suggesting they could have been merged but were not. It transpired that merging was prevented because fonts from the source document(s) had different encodings, despite having the same name. An improvement was made to the algorithm that evaluates font use within the job to make it smarter, thus avoiding the split that took place previously. The result now contains a single, merged font.
MAKO-3623	MAKOSUP-10812 Strange exception when calling renderSeparations The problem was caused by an attempt to reuse an image from a stale file. Now fixed.
MAKO-3602	MAKOSUP-10818 Open and Write Assembly produces problematic PDF After PDF-to-PDF processing with Mako, the exhibit failed a PDF Syntax check. The problem was traced to an incorrect assignment to the soft mask portion of an `SMasked` image. Now fixed.
MAKO-3616	MAKOSUP-10821 document->getJobTicket() exception Even though the exhibit passes Acrobat's preflight, it is simply not valid. The job's `Dests` dictionary has several keys that are very long, one over `900` characters in length. PDF 1.7 specifies that the limit is `127` characters. PDF 2 doesn't specifically impose a limit but notes that “…in previous versions of PDF it was recommended that the maximum length of the internal representation of a name object was limited to `127` bytes.” In any case, the PDF in question is v1.4, where `127` is the limit. Rather then introduce complex logic to support completely arbitrary name sizes, the maximum size of a name object is increased to `1024` bytes. This solves the problem for this job and provides plenty of headroom for other PDFs that may exceed the `127`-byte limit.
MAKO-3629	MAKOSUP-10828 Internal RIP Error generating thumbnails for a Photobook PDF file The error was triggered by the presence of a zero-length DHT marker segment in a DCT (JPEG-compressed) image stream. While this is extremely rare (we found no other file in an extensive test suite that has this characteristic), it does not appear to be illegal. Now fixed.
MAKO-3632	MAKOSUP-10830 Failed to generate thumbnail This issue was caused by an incorrect assumption in matrix arithmetic. Now fixed.
MAKO-3645	MAKOSUP-10833 Error: Jaws panic exit Now fixed.

Other issues fixed

MAKO-3378	Change cache folder on Linux
MAKO-3378	A customer reported an issue with a General I/O Error being thrown when instantiating `IJawsMako`. The reason for this is that their home folder was redirected to an NFS (Network File System) mount. The error occurs when opening `FontMap` and applying an `FLOCK`; attempting to `FLOCK` a file opened read-only on NFS fails with an `EBADF` (bad file descriptor) error. This change does two things: Changes the default cache location Changes the mode in which the file is opened The default cache location is now `/var/tmp/jawsmako/<username>`, instead of a folder under the user’s home folder. As the `FontMap` is intended to reflect the fonts available on the local machine, writing it under the user's home folder, which may move with them, is counterintuitive – the machine they are logged onto may have different fonts, invalidating the `FontMap` and defeating its purpose. So this is a sensible change. The mode in which the file is opened is changed from read-only to read-write; doing so allows the `FLOCK` to complete successfully, even if it is on an NFS mount, thereby fulfilling its purpose of preventing the file from being overwritten while it is being read.
MAKO-3531	Increase default size of the renderer color management profile and transform caches The need for this was discovered when profiling the rendering performance of a PDF exhibit that contained two large CMYK ICC profiles. The combination of the two exceeded the default cache size (10MB), which resulted in the color profiles being repeatedly loaded rather then being read from the cache. On 64-bit platforms, the defaults are now 50MB of profiles and 50 transforms. If this becomes too small or too large, then OEMs can adjust it with two new environment variables: `J_PROFILE_CACHE_SIZE_MB` – Size of the profile cache, in integer megabytes `J_TRANSFORM_CACHE_COUNT` – Size of the transform cache. That is, the number of transforms that can be present in the cache at any one time
MAKO-3626	Export to WEB PDF causes error 1073741819 When outputting to linearized PDF, there was an issue with the creation of the `PageLabels` tree. Now fixed.
MAKO-3335	Jaws Base 14 fonts are not metrics compatible with the fonts in Harlequin Global Graphics compares rendered output from Mako’s built-in RIP (Jaws) to that of Harlequin RIP, as part of the testing regime. Tiny pixel-level differences were detected that can be attributed to differences in font metrics of the base 14 fonts (that is, Times and so on). Rather than amend the fonts themselves, font stubs are amended to insert overriding metrics into the font dictionary, and corresponding changes to relevant code paths to make use of these.
MAKO-3468	SWIG Simple Examples prnstream not processing PostScript in PJL The prnsteam example from simpleexamples (found in the MakoApps folder of the distribution) in C# and Java did not match the behavior of the C++ example. Now fixed.
MAKO-3537	Honor the default intent of the color space In the (rare) circumstance where a DOM node does not specify an explicit intent, Mako now applies the default intent of the associated color space.
MAKO-1417	IComplexColorSimplifier transform does not handle /None correctly It does now.
MAKO-1946	Undefined error when converting LT968AP2.pdf Found during testing. A particular construct in the exhibit would previously have been treated as an error, but as other PDF consumers choose to ignore it, Mako now does the same to allow processing to continue to completion.
MAKO-3326	Pattern background incorrect when converting PDF to PDF An improvement to Mako’s `/Pattern` handling code corrected a problem with the background color of a pattern in the exhibit PDF.
MAKO-3520	Exception in vector flattening code path Found during testing. Adding Type3 font handling fixed the problem.
MAKO-3565	Unable to convert a PCL/XL document on macOS / Linux The PCL/XL exhibit converts successfully on Windows but not on macOS or Linux. The root cause is now fixed.

Distribution

MAKO Version 6.3.0 is built for the following platforms:

iOS
macOS
Linux (for Debian-based distributions; for example, Ubuntu, Mint)
Linux (Centos)
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)
Windows UWP (Store apps, Windows 10 IoT)

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 Framework and .Net Core)
Java (built with OpenJDK11)
Python (v3.8)

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

Linux_SWIG_(C#-Java-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)