Created Date: Mar 24, 2021 18:25
Last Modifed Date: Mar 24, 2021 18:25
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);
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.
Default. Each RIP generates its own page.
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.
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.
<path to resources folder>
Sets the directory where remote resources are located, ie resources referenced by the IJPDS but external to it.
Expose Shift-JIS to UTF8 conversion method
The ShiftJISStringToU8String() method will convert a Shift‑JIS encoded string to UTF8. Exposing code already present in Mako, it allows a developer to make such a conversion without the use of an external library.
The reason for providing this feature is that while the PDF specification recommends UTF8 for strings, it does not prohibit alternative encoding. For example, a spot color name encoded in Shift‑JIS will require conversion.
In this example,
Add support for multipage TIFF for input
An optional third parameter,
Support issues fixed
(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 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:
(Mako Support Request #10453) Issue with Postscript file referencing external resources
This improvement implements a new read-only
(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
(Mako Support Request #10480) Kyocera PRESCRIBE chunk break PJL parser
The solution is to ignore Kyocera PRESCRIBE instructions (those bracketed with
(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:
Mako already provides the first and last, but the middle requirements are not achievable with the current API (
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 Support Request #10489, #10496, #10507) Image disappears, part of page disappears
The PDF spec requires that the
The implemented solution ensures that soft masks attached to images do not acquire automatically generated indexed color spaces.
(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 Support Request #10497) Rendering error in transparency
The solution required improving handling of knockout groups, especially where color conversion is required.
(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
(Mako Support Request #10500) Rip Error
The solution was to fix an issue with font merging.
(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 Support Request #10506) Japanese characters are missing
The solution required changes to CID font handling code. Now fixed.
(Mako Support Request #10514) SIGSEGV exit in mako 5.2.1
The exhibit file has a badly formed font. Specifically, the
(Mako Support Request #10515) Antialiasing
*** NB This is a breaking change. ***
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 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
(Mako Support Request #10518) Rendering PS errors
The solution implemented fixes an exception due to incorrect word spacing.
(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 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 Support Request #10527) Error rendering 16bpp
When rendering a
(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.
(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.
(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
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.
Regression due to reused forms
Improved form (PDF XObject) reuse caused a regression in rendering behavior. Now fixed.
Mako Version 5.2.2 is built for the following platforms:
- Linux (for Debian-based distributions, eg Ubuntu, Mint)
- Linux (for Debian Stretch)
- Linux (for MUSL distributions, eg Alpine Linux)
- Windows (static and non-static libs, VS 2019 (V142) x64 only)
- Windows (static and non-static, VS2015 (V140), x86 and x64)