Mako 5.2.2 Release Notes

MAKO-2886

Add support for IJPDS

A new Mako input class, IIJPDSInput() is available in this release. Designed to convert KODAK VERSAMARK IJPDS formats to PDF, it enables content in this format to be “recovered” into a form that can be easily shared or reprinted.

The document format enumerator is eFFIJPDS, so the input class can be instantiated with IIJPDS::create(jawsMako) or IInput::create(jawsMako, eFFIJPDS).

Several input parameters are available to control how the IJPDS content is assembled into the PDF. These collation options are needed because IJPDS is essentially a sequence of bitmap pages, the order of which is arbitrary and determined at file creation. For example, they may be separate monochrome pages or each a color separation for a page. Although pages are assigned to a logical RIP (raster image processor) for physical printing, IJPDS doesn't directly specify how the different RIPs are to be interpreted. During testing, we encountered:

A job with 8 RIPs which is should interpreted as CMYK separations for the front and back of a (duplex) page

A job with 8 RIPs that are all individual mono pages

The collator works by treating all pages assigned the same logical RIP in the same way. The table below lists these options and are also documented here.

Setting the input parameter:

IIJPDSInputPtr input = IIJPDS::create(jawsMako);

input->setParameter("ripsetup", "cmyk");

These can also be set on the makoconverter command line, eg

makoconverter fullspeed.ijp out.pdf -inputparams ripsetup=cmyk

The table below lists the possible parameters.

ripsetup

mono
cmyk

Default. Each RIP generates its own page.
Groups RIPs together in blocks of 4 to generate a composite page.

ripinterleave

true (or 1)

false (or 0)

Default. Output is ordered in page number major order. All the page 1s from each RIP are output followed by the page 2s and so on.

Output is ordered by RIP major order. All the pages for RIP 1 are output followed by all the pages for RIP 2 and so on.

riporder

0,1,2,3…
0,1,3,2

-1,2,-1,-1

A comma-separated sequence of RIP IDs (a number from 0 to 15, or -1 if a blank is desired for that slot.

This controls the sequence in which the RIPs are processed. By default, the order in which the RIP is defined by the job is followed. For CMYK output it is sometimes necessary to change the plate order (eg "0,1,3,2") to obtain the correct composite output.

If -1 is encountered in CMYK output, then that separation is interpreted as a blank. This is useful to see a separation in a specific color. For example, specifying "-1,2,-1,-1" uses the page from RIP 2 as the magenta plane with all other color planes blank. This results in a CMYK composite output where only RIP 2 comes out in a magenta color.

For non-composite output "-1" is ignored as it does not make sense to output a blank page.

resourcedirectory

<path to resources folder>

Sets the directory where remote resources are located, ie resources referenced by the IJPDS but external to it.

MAKO-2813

MAKO-2897

Add support for multipage TIFF for input

An optional third parameter, imageIndex, has been added to IDOMTIFFImage::create() to select a specific image from a multipage TIFF. The index is zero-based, and defaults to zero if omitted, to return the first or only image. An exception is thrown if the index is out of range.

MAKO-2746

(Mako Support Request #10431) Mako high memory usage

In the exhibit file provided by the customer there is a form (PDF XObject) which contains many paths. It’s reused twice on every second page. However, it’s shared inside other forms that themselves are not reused, leading to higher memory usage. The core issue is that PDF input is not caching form dictionaries that are created for forms not at the page level.

The solution implements a change to the way forms are cached, enabling much higher form reuse across pages, leading to a significant reduction in runtime memory consumption.

MAKO-2754

(Mako Support Request #10442) PDF issues / high memory usage

The customer case is pathological. It has a very large number of images – half a million or so. To have all these available, about 1.5 million paths, brushes, colorspaces, images, filters, etc. are loaded into memory (there are reused images).

The solution requires attacking the problem on several fronts, refactoring of numerous classes to reach the reduction in runtime memory consumption required. For the customer case, a reduction of 1.2GB was achieved.

To accomplish this, it was necessary to:

• Refactor IDOMPathNode::Data, breaking up attributes into categories to allow lesser‑used attributes to be stored in separate classes
• Update IDOMPathGeometry to use a repurposed CDOMPathRectGeometry class able to represent a geometry consisting of a single rectangle. This is much cheaper than storing a rectangle using a points list, and cheaper still than storing as a regular geometry
• Avoid creating an IDOMImageInverterFilter where possible, when processing masked images (the customer case had many), and instead apply the inversion to the image’s /Decode array
• Cache solid color brushes in PDF input, thereby reducing the repeated creation of color spaces, colors and brushes
• Allocate simple color spaces (ie sRGB, scRGB, sGray and the Device spaces) using the same object, as there is no good reason to have more than one instance of these
• Reorder items in the CDOMPointsListGeometryData class to allow the compiler to better pack them in memory
• Use a constant reference counted object with the PDF file name, as the large number of images implies a large number of streams to reference them. Without this improvement, the path to the PDF file is a load on memory as it is repeated for each clone of the PDF input stream

MAKO-2495

(Mako Support Request #10453) Issue with Postscript file referencing external resources

This improvement implements a new read-only rhostfs Jaws filesystem for use with the IDistiller class. The file system is added to the Jaws file device table in Mako as %os%, which means that PostScript operators (e.g file, run etc.) can be used with files on disk.

The %os% device will be added at startup, exclusively for PostScript input and nowhere else.

MAKO-2685

(Mako Support Request #10478) Ricoh PS driver files causes Mako to throw a Read Access violation

The solution required working around a broken font that had an invalid CIDMap which mapped to GIDs greater than the number of glyphs in the font.

MAKO-2686

(Mako Support Request #10480) Kyocera PRESCRIBE chunk break PJL parser

The solution is to ignore Kyocera PRESCRIBE instructions (those bracketed with !R! and EXIT;) allowing the PJL parser to complete.

MAKO-2839

(Mako Support Request #10487) - Extra information required when scanning for PDF fonts

A customer had additional requirements not satisfied by the current code, wishing to obtain:

• Total unique fonts
• Total unique sub-fonts
• Total font dictionary occurrences
• Highest count of font dictionaries found from all pages
• Page number with the highest count of font dictionaries
• Total embedded type fonts

Mako already provides the first and last, but the middle requirements are not achievable with the current API (IPDFInput::scanPdfForFonts()). With the following additions, it’s now possible to meet these requirements:

• Provide the object number (.objectNumber) and generation (.generation) (if present) for all fonts that are found
• If the font is a CID font, find the object number (.subFontObjectNumber) and generation (.subFontGeneration) for the sub-font, if present
• For each font, note which pages reference that font (.referencedPages)

Armed with this information, all the other details can be derived. An example of the new APIs in action can be found here: https://gist.github.com/mako-sdk/5be6c41abdba9dbf76b9fd9a0d6e7ae0

MAKO-2714

(Mako Support Request #10489, #10496, #10507) Image disappears, part of page disappears

The PDF spec requires that the SMask portion of an image have color space DeviceGray. The issue for the exhibits provided is that Mako is producing an Indexed color space, leading to the image being dropped by Acrobat or the job being rejected by Harlequin RIP.

The implemented solution ensures that soft masks attached to images do not acquire automatically generated indexed color spaces.

MAKO-2874

(Mako Support Request #10494) Rendering issue

The solution fixes issues with indirect references in shading patterns, whose pattern attributes were not being exhaustively checked.

MAKO-2684

(Mako Support Request #10497) Rendering error in transparency

The solution required improving handling of knockout groups, especially where color conversion is required.

MAKO-2771

(Mako Support Request #10499) Mako 4.8.8 rendering error issue

The solution implemented fixes an issue with a particular combination of forms where the same form was executed multiple times but with different gstate dictionaries set.

MAKO-2693

(Mako Support Request #10500) Rip Error

The solution was to fix an issue with font merging.

MAKO-2709

(Mako Support Request #10503) Negative HMI

The solution required was to fix an issue when a font’s Horizontal Motion Index (HMI) was negative, due to a bitmap PCL5 font that defined a height of zero in its header.

MAKO-2777

(Mako Support Request #10506) Japanese characters are missing

The solution required changes to CID font handling code. Now fixed.

MAKO-2784

(Mako Support Request #10514) SIGSEGV exit in mako 5.2.1

The exhibit file has a badly formed font. Specifically, the fpgm table has an FDEF at the end that is not terminated. The fix prevents reading off the end of the source buffer (the cause of an exception) if a Type 42 FDEF instruction is missing a trailing ENDF, allowing the job to complete normally.

MAKO-2854

(Mako Support Request #10515) Antialiasing

*** NB This is a breaking change. ***

Previously, IJAWSRenderer::renderSeparations() accepted as its fourth parameter a Boolean, to indicate if anti-aliasing was required. To provide more control, the type of this argument has been changed to a uint8 (byte in C#) and now accepts a value between 0 and 15. A value of zero (or one) means no anti-aliasing. A value of 4 will produce the same result as true before this change. This improvement allows the antialiasing to be ‘tuned’ to the requirements of the job.

Note that progressively higher values increase the size of the ‘cell’ – the area of pixels to be processed – by squares, ie 2x2, 3x3, 4x4, 5x5 etc. and therefore will take longer to process.

MAKO-2862

(Mako Support Request #10517) Kyocera KPDL support

The solution works around an invalid PostScript job which defines a Type 42 font that uses a GlyphDirectory dictionary with no description for .notdef. 

The PostScript Language Reference Manual states: “As for all fonts, there must be a glyph description for the .notdef character—that is, .notdef must map to a glyph index for which there is a glyph description in GlyphDirectory.” However, Adobe Distiller allows this fault, substituting with a blank glyph. The change implemented in Mako works in a similar way, by adding a zero-length .notdef glyph when emitting a TrueType font.

MAKO-2851

(Mako Support Request #10518) Rendering PS errors

The solution implemented fixes an exception due to incorrect word spacing.

MAKO-2845

(Mako Support Request #10519) Allow access to a TrueType font’s original OS/2 table

Mako largely reconstructs the OS/2 table due to too many bad fonts. It’s more important that Mako generate valid entries that will validate on OSs (particularly for XPS and SVG) than the entries be exactly what was in the job.

However, the customer requires access to the unchanged OS/2 entries to match with the behavior of other applications. Mako now provides a simple API to obtain it. The new API is IDOMFontOpenType::getOriginalOS2Table(). It returns a CEDLSimpleBuffer with the data. It’s populated for PDF input only, and this information is not included in the hash of the font.

MAKO-2826

(Mako Support Request #10520) PDF file not rendered properly

The exhibit file contains two fill objects painted with patterns. For objects so constructed, their outline is used to clip the area of repeated pattern, but in this case only one of the objects was rendered correctly. Now fixed.

MAKO-2898

(Mako Support Request #10527) Error rendering 16bpp

When rendering a DeviceGray image to 16bpc, using setMapDeviceGrayToCMYKBlack(true) causes a rendering failure, as this setting circumvents the usual ICC color conversion. Now fixed.

MAKO-2906

(Mako Support Request #10532) EPS overprint

Although this issue manifested when rendering, it was triggered during PostScript interpretation, resulting in the incorrect reading of an overprint setting. The solution ensures the error will no longer occur.

MAKO-2779

(Jaws Support Call #6494) Objects shifted by a pixel with 16-bit output

This was a fix applied to Jaws RIP that was also required in the Jaws integrated into Mako.

MAKO-2831

(Jaws Support Call #6561) Mako transparency / softmask issue?

The customer only sees this issue in Acrobat and the RIP that is in use (presumably an Adobe product). The problem appears to be triggered by repeated uses of Type 2 patterns. The solution for the customer works around this by avoiding reuse of Type 2 patterns when generating a form content stream.

As the issue is not with Mako per se, the solution also adds a new IPDFOutput parameter, ShadingPatternReuseMode, that can modify his behavior. A value of 0 (default) results in the new behavior, while a value of 2 results in the previous behavior, to reuse Type 2 patterns as normal.

MAKO-2725

Grey image with SMask is painted incorrectly

This problem occurred because the processing of the page object skipped an important step (8 to 16-bit conversion) resulting in the mask and content being out of step. Now fixed.

MAKO-2815

Regression due to reused forms

Improved form (PDF XObject) reuse caused a regression in rendering behavior. Now fixed.