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 MakoColorLogic 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 styleWith 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
CPP
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, | ||||||||||||||||
CPP
| ||||||||||||||||
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, 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.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
CPP
| ||||||||||||||||
MAKO-3478 | ISeparator - convert Type 1 shading patternsIntroduced in Mako 6.1.0, Mako’s | |||||||||||||||
MAKO-3479 | ISeparator - convert DeviceN shading patternsContinuation of the improvements to shading pattern handling in | |||||||||||||||
MAKO-3480 | ISeparator - convert shadings with overprintContinuation of the improvements to shading pattern handling in | |||||||||||||||
MAKO-3481 | ISeparator - convert XPS linear and radial gradients.Continuation of the improvements to shading pattern handling in 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.pdfThe improved support for shadings added to | |||||||||||||||
MAKO-3528 | IJPDS: Direct to RasterThis 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, This is optional for every PDL, but currently only For the public IJPDS interface, an | |||||||||||||||
MAKO-3447 | IJPDS: Return additional job informationThe 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 [ To support this easily (without breaking the API) new properties are added to the
CPP
The total number of output pages is returned by To get the number of RIPs in the job, loop through the first few pages and count the number of pages whose 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 releaseIn 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 objectNow fixed. | |||||||||||||||
MAKO-3583 | IJPDS Support page rotation natively in IPageRaster outputWork to improve performance of rotation of rasters extracted from IJPDS input | |||||||||||||||
MAKO-3469 | IJPDS: Characters missing from mako_mark_knockout.ijp outputA 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 lengthAn issue with the IJPDS input class, | |||||||||||||||
MAKO-3507 | IJPDS: Incorrect page size when stitched and rotated 90° or 270°An issue with the IJPDS input class, | |||||||||||||||
MAKO-3514 | IJPDS input: Text incorrectly positioned when stitched and rotatedWhen processing the exhibit ( | |||||||||||||||
MAKO-3536 | IJPDS: Fix unit test failures when running on Windows x86IJPDS 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
CPP
| |||||||||||||||
MAKO-3553 | IJPDS: IJPIn_InputPageNo_RipId.ByRipRot90 intermittently fail on macOSThis 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 degreesCaused due to insufficient bounds checking. Now fixed. | |||||||||||||||
MAKO-3597
| Add an API to IDistiller to apply password security to the PDFTo 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
CPP
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
CPP
See the Mako API documentation for further details. Passwords and permission flags values can also be set with Using
The permissions flags defaults to A version of | |||||||||||||||
MAKO-3596 | Add API to IDistiller to allow PDF metadata to be setTo 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
CPP
Using MakoDistillerCmd command-line switches:
A version of | |||||||||||||||
MAKO-3430 | Update libjpeg library to libjpeg-turbo to improve decoding/encoding performanceImplemented on Mako’s major platforms (Windows, macOS, Linux) the introduction of | |||||||||||||||
MAKO-3648 | Windows SWIG build has an unexpected dependency on a VC runtimeThese 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 typeBefore this change, these classes were unusable, as they referenced inaccessible internal types:
C#
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
The 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 supportMako 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 filesA 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, Once the image is opened, an 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
|
MAKO-3183 | MAKOSUP-10572 Mako: Object too small to be rendered by JawsBefore this change, Mako’s internal RIP (Jaws) was restricted to a page size of 1x1 point (a point = 1/72nd 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 threadThere 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:
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
CPP
|
MAKO-3533 | MAKOSUP-10759 getPageText from pagelayout returns texts without spaceMako’s This change introduces two APIs that allow the text interpretation to be “tweaked” – adjusted to suit the source material. They are:
CPP
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 PDFWhen 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 regressionThis 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 fontsThis is a new feature to enable Previously, 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 annotationThe 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-4The 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
Alternatively, associated
CPP
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 documentsThe 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 sizeThis 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 handler can be set for both PCL5 and PCL/XL input with A simple example follows, showing how this can be used:
CPP
|
MAKO-3653 | MAKOSUP-10798 Vector-based transparency flattener failsVector-based flattening, enabled with |
MAKO-3561 | MAKOSUP-10804 Fixing font problemsThis change allows customers to disable the generation of 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 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
The default for the first is When Both settings are ignored for PDF/X and PDF/A. |
MAKO-3572 | Mako’s 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 renderSeparationsThe 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 PDFAfter 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 |
MAKO-3616 | MAKOSUP-10821 document->getJobTicket() exceptionEven though the exhibit passes Acrobat's preflight, it is simply not valid. The job's In any case, the PDF in question is v1.4, where Rather then introduce complex logic to support completely arbitrary name sizes, the maximum size of a name object is increased to |
MAKO-3629 | MAKOSUP-10828 Internal RIP Error generating thumbnails for a Photobook PDF fileThe 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 thumbnailThis issue was caused by an incorrect assumption in matrix arithmetic. Now fixed. |
MAKO-3645 | MAKOSUP-10833 Error: Jaws panic exitNow fixed. |
Other issues fixed
MAKO-3378 | Change cache folder on Linux |
A customer reported an issue with a General I/O Error being thrown when instantiating This change does two things:
The default cache location is now The mode in which the file is opened is changed from read-only to read-write; doing so allows the | |
MAKO-3531 | Increase default size of the renderer color management profile and transform cachesThe 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:
|
MAKO-3626 | Export to WEB PDF causes error 1073741819When outputting to linearized PDF, there was an issue with the creation of the |
MAKO-3335 | Jaws Base 14 fonts are not metrics compatible with the fonts in HarlequinGlobal 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 PJLThe 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 spaceIn 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 correctlyIt does now. |
MAKO-1946 | Undefined error when converting LT968AP2.pdfFound 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 PDFAn improvement to Mako’s |
MAKO-3520 | Exception in vector flattening code pathFound during testing. Adding Type3 font handling fixed the problem. |
MAKO-3565 | Unable to convert a PCL/XL document on macOS / LinuxThe 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)