Mako 5.2.0 Release Notes

MAKO-2420

IDistiller() class

Jaws PDF Library, usually abbreviated to PDFLib, was created to provide easy access to the Jaws RIP technology for the purpose of converting PostScript to PDF and vice versa. This role has been superseded by Mako.

For most PDFLib use cases, the introduction of PostScript input in Mako 5.0 (the IPSInput() class) allowed a PDFLib user to make the switch to Mako, opening up many opportunities for document processing beyond the simple conversion task that PDFLib is able to handle.

However, the two stage conversion (using IPSInput() followed by IPDFOutput(), for example) is slower than the direct conversion offered by PDFLib. Additionally, IPSInput() is less flexible in its handling of a PostScript prolog to modify the conversion process.

Mako 5.2.0 introduces the IDistiller() class to overcome these limitations. Designed as a replacement for PDFLib, testing has shown up a significant speed improvement over the previous conversion route, matching or in many cases improving on the PDFLib performance.

Fuller documentation of the new class can be found on the Mako documentation site:

https://documentation.globalgraphics.com/support/mako/mako-core/mako-applications/mako-distiller

MAKO-2421

Add support for IDistiller::setProlog()

An API to load a PostScript prolog, PostScript code that is executed before parsing of the input file begins. This example loads a prolog from a local file, prolog.ps:

IDistillerPtr distiller = IDistiller::create(jawsMako) distiller->setProlog(setProlog(IInputStream::createFromFile(jawsMako, "prolog.ps"));

MAKO-2422

Add support for IDistiller::setEpilog()

Similar to a prolog, an epilog is executed after parsing of the main file has completed.

MAKO-2424

Add support to IDistiller for PANOSE matching

PANOSE was an early standard for mapping unavailable fonts to a suitable alternative. It is available in PDFLib and is implemented in IDistiller()

MAKO-2461

Add new class enabling fonts to be installed permanently to disk

This work replicates in Mako’s IDistiller() implementation a feature of PDFLib that allows fonts to be installed from disk and to be made available to subsequent PostScript conversions.

For IDistiller there are two new API functions to set devices on disk:

• setFontDevicePath() specifies the path to a %font% device on disk that IDistiller will use instead of the usual ROM font device.

• setResourceDevicePath() specifies the path to a %resource% device on disk that IDistiller will use instead of the usual ROM font device.

setParameter() equivalents are also added, FontDevicePath and ResourceDevicePath. In both cases the device on disk must be using the emulated filesystem as is supported with PDF Library.

MAKO-2423

Create a testpdflibcmd.exe equivalent for IDistiller()

PDFLib comes with a sample command-line application, testpdflibcmd, that provides a convenient method for exercising PDFLib without the need to write code.

Mako provides an equivalent, MakoDistillerCmd, that supports the same command-line options and many of the arguments that can be added to a control file (usually referred to as an args file). In most cases it can replace testlibpdfcmd in a script or batch file.

MakoDistillerCmd is supplied as sample code. Source code can be found on the developer pages referenced above. A ready-built version is included with the Mako SDK.

Prototype feature: IJPDS support

 MAKO-2332

IJPDS implementation - Create a skeleton parser

IJPDS (Inkjet Printer Data Stream) is a format developed by Kodak for input to their Versamark printing systems. In this release we have included a prototype of a new input, IIJPDSInput() to enable conversion of this format to PDF and other supported PDLs.

This is a new feature that is in the early stages of development. As such its testing has been confined to a small number of input files. It is included in Mako 5.2.0 to facilitate evaluation by interested Mako developers, who do so at their own risk. It will be developed into a mature feature in subsequent releases of Mako.

MAKO-1937

Dash is lost after converting text

Found during testing. Linjoin/linecaps properties not forwarded correctly. Now fixed.

MAKO-2100

RenderScreened unstable

Inconsistent hashing of screened images caused a unit test failure. Now fixed.

Other New or Improved Features

MAKO-2379

SWIG: Support Custom Transforms

Support for custom transforms in C# was absent from the implementation in Mako 5.1. It is now supported.

MAKO-2256

Crash caused by corrupt data stream in JPEG2000

Fixed in Mako by porting a fix from Mako Jaws RIP to gracefully handle an error in the encoding of a JPEG2000 image.

MAKO-2289

Exception during PDF to PDF processing of veraPDF test suite file (6-2-5-t03-fail-a.pdf)

Caused by insufficient checking of the data type. Now fixed.

MAKO-2377

Set internal renderer to run in 16-bit to improve accuracy of component values required for transparency blending

The need for this change was uncovered during routine testing, to improve the rendering of ColorDodge and ColorBurn blend modes.

MAKO-2107

Implement a better solution for handling CFF fonts with non-standard FontMatrices in PDF input and XPS/SVG output

In Mako’s PDF input, when a CFF font containing a non-standard CFF font matrix is encountered, it adjusts the font to have a standard CFF font matrix and adjusts the DOM to suit. This was to overcome what is now a very old Windows font system problem but causes problems in other contexts.

This work removes the font manipulation on input and deals with the issue, via a transform, before outputting to formats such as XPS and SVG. This transform is also available externally should it be required by a Mako developer.

MAKO-2298

Populate print ticket entries from PostScript setPageDevice declarations

When parsing PCL5 or PXL/XL file streams, Mako populates print tickets to persist job information such as numbers of copies, duplex printing etc. A fuller explanation can be found on this documentation page:

https://documentation.globalgraphics.com/support/mako/mako-core/documentation/topics/pjl-and-printtickets

Mako 5.2.0 introduces the same concept for PostScript. Currently it only supports an IDocumentAssembly-level ticket for the number of copies, derived from this PostScript generated by an HP PostScript printer driver:

%%BeginNonPPDFeature: NumCopies 3

This capability will be expanded in future releases of Mako.

Linked to the developer page is a code sample that can automatically recognise the language of a PJL-prefixed print job, based on the @PJL ENTER LANGUAGE=… statement and switch to the correct parser. It also demonstrates the use of Mako print tickets. This is that link:

https://gist.github.com/mako-sdk/d471cd43c882fbfe3a87c25a6977d2c6

MAKO-2480

PostScript parsing error

This issue was triggered by the presence of Adobe TBCP (tagged binary communications protocol) characters in the PostScript stream. Sample code was developed that intercepts these characters enabling the PostScript parser to complete normally. The code can be found here: https://gist.github.com/mako-sdk/d471cd43c882fbfe3a87c25a6977d2c6

MAKO-2448

Prevent IPSInput() from downsampling images

Automatic downsampling to 288dpi is disabled by default and can be controlled via an API.

MAKO-1979

Incorrect output for a shading case in the Ghent GWG tests with overprint simulation

A fix to the overprint simulation transform to ensure correct rendering of Ghent Working Group print examples.

Support requests fixed

MAKO-2175

(Mako Support Request #10371) Kerning Issue

The customer reported that text is moving very slightly after processing PDF to PDF with Mako. The problem was found to be the outputting of kerning parameters. Kerning parameters are expressed in PDF in thousandths of text units but Mako was rounding these to integral quantities.

This change allows an extra two floating point digits for:

• TJ kerning values (previously had 0)

• Tc values (previously allowed 4)

• Tw values (previously allowed 4)

Now fixed and extensive regression testing proves that the problem is solved.

MAKO-2469

(Mako Support Request #10372) Color difference issue

If an input PDF page contains a transparency page group, Mako does not emit a page group in an output PDF unless it detects that the page contains transparency. In this instance the input page has a CMYK page group, but no transparency for that page. Had the original page group been present, the renderer would have converted the content to CMYK before converting back to RGB. Without it, it simply paints RGB, causing the rendering difference.

Since the absence of the page group is the reason the results render differently, a new option is provided for PDF output (IPDFOutput::setForceEmitPageGroup()) that can be set to true to prevent color differences of this type from occurring. It can be set by either of these methods. Assuming:

IPDFOutputPtr output = IPDFOutput::create(jawsMako);

Then use

output->setForceEmitPageGroup(true)

or

output->setParameter("setForceEmitPageGroup", "true");

It’s safe to use at all times (and may be made the default rendering behavior in future Mako versions). The sample makoconverter allows this parameter to be set on the command line.

MAKO-2401

(Mako Support Request #10389) Mako color issue

A minor rendering issue was corrected by this fix.

MAKO-2375

(Mako Support Request #10391) Dotted path offset

This issue was triggered by an output optimisation intended to reduce the possibility of identical paths being written multiple times. In this case it had a side effect of changing the way a dashed line was written, whose appearance is dependent on start point and direction. Now fixed.

MAKO-2320

(Mako Support Request #10396) RE: Sigkill

This job was poorly constructed, with a number of patterns that each contained a ~30MB image that exhausted display list memory allocated for patterns. The introduction of an environment variable allows this limit to be changed:

MAKO_RENDER_PATTERN_DL_LIMIT_BYTES

Setting to 10MB solved the problem, improving processing time and reducing memory consumption.

MAKO-2322

(Mako Support Request #10402) Part of image missing

The job had a non-zero MediaBox that led to incorrect positioning of a pattern. Now fixed.

MAKO-2470

(Mako Support Request #10406) Ps undefined error

This issue was triggered by an indirect reference to a color space array which is not expected. Now fixed.

MAKO-2471

(Mako Support Request #10424) Missing image with signature issues

This issue was triggered by a PDF form (XObject) containing an image that is used multiple times. Subsequent instances incorrectly inherit a clipping path setting that renders it invisible when it should not be. Now fixed.

MAKO-2439

(Mako Support Request #10426) Mako evaluation issue

An incorrectly formed PCL/XL file triggered an arithmetic overflow. Bounds checking was added to enable the job to complete and produce output.

MAKO-2430

(Mako Support Request #10432) Add support for 16-bit anti-aliased output to IJawsRenderer::renderSeparations() method

Sixteen-bit, anti-aliased rendering is now available from this API, producing high-quality renditions even at low resolutions.

MAKO-2429

(Mako Support Request #10434) Issue with PCL to PDF conversion

This issue triggered an exception in Mako’s PCL5 input parser, “PCL5 Processing Error: Unexpected stable font…”. Now fixed.

MAKO-2494

(Mako Support Request #10454) PDF parsing issue

This issue was triggered by incorrect handling of a CFF (Compact Font Format) font in the PDF. Now fixed.

Bug fixes

MAKO-1865

8-bit rendering issues in Mako

While testing fixes to some 16-bit rendering issues some 8-bit rendering issues were uncovered. Now fixed.

MAKO-1864

16-bit rendering issues in Mako

Quality issues affecting 16-bit rendering were fixed.

MAKO-2334

PCL file 94.jb2 causes Makoconverter to silently quit

This problem was solved by unrelated work to improve PCL ROP (Raster Operations) performance.

MAKO-2378

An image object with an imagemask is treated as opaque, not transparent

An issue with a PowerPoint-originated file and seen only when rendering to RGB, is now fixed.

MAKO-2341

Spacing incorrect when setting locale to de-DE

The issue was caused because code to convert a string to a floating-point number was not taking the locale into account and in this case not interpreting a comma as a decimal separator. Now fixed.

MAKO-1447

PCL5 & PCL/XL improvements

The following are a list of customer-supplied PCL5 test files that caused problems in earlier versions of Mako. All were tested in this release and are producing the correct output.

Filename(s)

Exception

repro-case.prn, barcode.prn

Bad arguments error when processing

job0-41551.sqjob

Line spacing incorrect when processing

ESCAPEEA.prn

Additional page output when processing

DTparsing_interpret_.prn

Undefined error when processing

75.jb3

Incorrect output when processing

 2.jb2 and 74.jb2

Missing text when processing

job0-17126.sqjob

Grid lines are too dark when processing

job1-1536619375102807532.sqjob

Vertical lines in table missing or incorrect when processing

PCL5 test file 106.jb2

Objects incorrectly placed when processing