Skip to main content
Skip table of contents

Mako 6.3.0 Release Notes


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.


Integrate ColorLogic CMM into Mako

ColorLogic GmbH

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.


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:

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.


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
IDOMPathGeometryBuilderPtr geometryBuilder;
IDOMPathGeometryPtr geom = geometryBuilder->createGeometry(IDOMPathGeometry::eFREvenOdd);


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.pdf

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


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:

// Create a colorspace from the ICC profile
IDOMColorSpacePtr iccBasedColorSpace = 
			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;


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.


ISeparator - convert DeviceN shading patterns

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


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


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.


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.


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.


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:



Information returned



The input page number, starts at 0



The RIP number, starts at 0 but can be -1, which indicates a blank page



Job X resolution



Job Y resolution

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.


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.


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

Now fixed.


IJPDS Support page rotation natively in IPageRaster output

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


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.


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.


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.


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.


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:

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


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.


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

Caused due to insufficient bounds checking. Now fixed.



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:

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:

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.


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:

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.


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.


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.


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

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


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


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


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.


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:

// Open Mako
IJawsMakoPtr mako = IJawsMako::create();

// Load the image
U8String imagePath = "multichannel.tif";
IDOMImagePtr image = IDOMTIFFImage::create(mako,
    IInputStream::createFromFile(mako, imagePath));

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::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));


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/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.


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.


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:

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.


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:

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.


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.


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.


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.


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.



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:

IPDFOutput::overrideMaximumICCVersion(uint32 majorVersion, uint32 minorVersion)

Alternatively, associated setParameter() parameters can be applied:

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.


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.


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:

class CTestMediaHandler : public IMediaHandler
    void sizeRequest(const PValue& size, double& pageWidth, double& pageHeight) override
        switch (size.getType())
        case PValue::T_INT:
            printf("Unknown MediaSize: %d\n", size.getInt32());

        case PValue::T_STRING:
            printf("Unknown MediaSize: %s\n", size.getSysString().c_str());



CTestMediaHandler mediaHandler;

IPCLXLInputPtr pxlInput = obj2IPCLXLInput(input);
if (pxlInput)

IPCL5InputPtr pclInput = obj2IPCL5Input(input);
if (pclInput)



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.


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:

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’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.


MAKOSUP-10812 Strange exception when calling renderSeparations

The problem was caused by an attempt to reuse an image from a stale file. Now fixed.


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.


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.


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.


MAKOSUP-10830 Failed to generate thumbnail

This issue was caused by an incorrect assumption in matrix arithmetic. Now fixed.


MAKOSUP-10833 Error: Jaws panic exit

Now fixed.

Other issues fixed


Change cache folder on Linux

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.


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


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.


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.


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.


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.


IComplexColorSimplifier transform does not handle /None correctly

It does now.


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.


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.


Exception in vector flattening code path

Found during testing. Adding Type3 font handling fixed the problem.


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.


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 ( 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)
JavaScript errors detected

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

If this problem persists, please contact our support.