CentraDoc 6.3 has useful enhancements, some high profile bug fixes, and a number of lower profile bug fixes. Significant enhancements to the RIP include driver patterns, wide pixels, and more transparency, overprint, and blendmode fixes.
Most of the issues are listed here by ticket number. If you have any questions about a specific ticket or issue, please contact Liberty Technology Systems.
#13 Driver Patterns
#414 The RIP once again supports wide pixels (16 bits per component)
#536 Support for the Boehm Garbage Collector :
#543 Upgraded Little CMS to 1.17 and integrated security fixes (#286)
#593 PvSDK functions for drawing only the requested PDF Layer:
LsHandle LS_API LS_HandleFromPdf(PdfPtr pdf); PdfPtr LS_API LS_PdfFromHandle(LsHandle h); int LS_API LS_InstallLayerFilter(LsHandle h, const char *layerName, int isThumbnail); int LS_API LS_RemoveLayerFilter(LsHandle h);
#606 Upgraded FreeType to 2.3.6
#616 Support for listing and extracting PDF Attachments
#241 Attempting to work out problems with rotated Japanese text. This includes an informative mapping of Adobe-Japan1 CIDs to help detect cases where Unicode values are not unique (gfx/japan1cid.c&h). The PDF dvpsi layer automatically switches fonts when needed. There is a heavy Windows bias in the implementation. This issue will need revisiting for consistency, and for handling similar issues for Korean and Chinese glyphs. Contact Liberty Systems for more information.
#510 Numerous fixes for the RIP transparency implementation
#513, #527, #539, #542 PostScript CIDFont and resource issues. Much improved support for CID fonts and CMaps in PostScript, including resolving a number of resource related problems, charpath for type 0 fonts, etc. PSDVTEXT for PostScript wide fonts now includes CIDs in proper byte order (to match PDF).
#572 Implement non-separable blend modes in RIP, and fixes for several other blend modes when rendering CMYK
#574 PostScript pattern cell clipping (was in PDF, new to PostScript); Since this can be a performance hit on some drivers, define NO_PATTERN_CELL_CLIP to turn it off.
#614 Note: PS_CONFIG pdfCropped should be set to 1 (crop box) for best results
#617 The psisys / psimon error return value was still confusing, and has been cleaned up.
Check the PS_CONFIG signalerr value after the function call to see if an error occurred.
#142 PDF Output PDF/A-1b compatibility for tooltips and links
#412 allowing more operators in PDF pattern limit (one of the pathological pattern traps)
#506 PDF DeviceN colorspace with alternate Lab space fixed
#507 Improved font name comparison for handling spaces and PS/MT name decorations. See also #501 (6.2.3)
#508 Odd PDF: Acrobat tolerates some bad CCITT input (monochrome image compression)
#509 CMap character set handle trailing -UTF-16
#511 PDF pattern issues (more pathological PDF files)
#512, #513 PostScript properly handle error aborting in light of internal 'stopped' constructs.
#514 Odd PDF: Don't choke on scientific notation in PDF input
#515 Odd PDF:
#516 PostScript DvChar init chr.n_pts to zero before driver call
#517 Odd PDF: if MediaBox inside CropBox, swap, for consistency
#525 bump up MAX_COLOR_COMPONENTS and MAX_SAMPLE_DIMENSIONS for DeviceN. Example PDF file has 10 color elements in DeviceN; PDF Reference says Adobe allows up to 32
#528 PDF Driver interface emulating PostScript graphic state and PostScript image row callbacks, various ways and means of stompage fixed.
#530 PDF pattern performance improvement by preclipping the target area
#531 Various build issues
#534 Odd PDF: Acrobat tolerates "-" as a number
#535 Odd PDF: Handle invalid /Annots object
#536 PostScript add ScaleMatrix to font dictionary on makefont, for compatibility with some PostScript files
#543 Better error handling for some corrupted PDF files
#544 Odd PDF: file with BaseFont as string instead of name as documented
#549 Odd PDF: Acrobat allows broken jbig2 input. The example file's images have a trailing long word and no end markers
#553 gxc->auto_page_translate / AutoPageTranslate=Y broken in #318 - PostScript comment parsing backwards
#554 PostScript driver needs to ignore charem signals if text rendering mode != fill. Set color inside a type 3 proc (using setcachedevice) isn't kosher
#555 PDF forms now generating appearances for some field types when needed
#557 Unknown annotation types are legal PDF input.
#558 PSDVTEXT and PSDVCHAREM text mode missing stroke width parameter; also: call stroke even if the color is the same as fill
#559 PDF some fixes for XRef streams
#561 Adobe Copyright says we're not supposted to modify the CMaps. Removed minor tweaks to Japan and Korean CMaps introduced to handle a few special arrow characters missing from the Windows fonts. This still requires fixing using the model for #241.
#563 Fix for PostScript Dingbats with gxc->want_unicode. Windows Monotype Sorts isn't a Unicode font (neither is Windows Symbol), so Unicode encoding doesn't work. Some possible trouble spots: The gxs->symbol semantics are somewhat slippery, and have changed. This could conceivably cause problems with some drivers, although it is unlikely.
#565 PDF fix for gxc->want_unicode and gxc->multichar which helps font substitution calibration
#566 PostScript @PJL proc, don't read ahead inside macro; fixes parse error.
#567 PDF correctly track both end-of-char and next-char for correct 1-at-a-time character placement
#568 PDF Pattern object management bomb fixed
#577 sprintf cleanup (#286) broke PDF Type 3 font output (Distiller) (for strings with octal escapes)
#578 From #447 Image Limits (6.2.3): take monochrome into account when checking image limits
#579 Pdf Write allow kDestUnknown in PdfOutline_AppendFull for a null bookmark
#581 PostScript output driver (psdvps2.c) attempt to use meaningful text encoding
#588 Function Type 2 bomb calculating range if no C1 supplied
#589 Odd PDF: allow for obnoxiously long number strings; the limit was 31 characters, here is what we were choking on: 63803055350928782000000000000000000000.000000 (Maybe there's a bug in the producer program? This value should be between 0 and 1...)
#591 PDF ini options to automatically replace PDF Highlight annotation appearance streams. Also a fix for annotation Quadpoints handling.
The old style uses a yellow rectangle, the new style yellow blended. Drivers that don't like the new style should use PdfHighlightUnder=Y to get the old style. Drivers that want the new style should set PdfHighlightOver=Y instead.
The behavior of the new style PdfHighlightOver=Y (use alpha or use blend mode), can be configured by defines near the top of pdfannot.c:
/* define ONE of these */ /*#define HIGHLIGHT_ALPHA (.4)*/ #define HIGHLIGHT_BLEND "/Multiply"
#593 PDF Adobe Illustrator layers behave more like part of the normal PDF optional content layers in the PdfLayer APIs. Also added PdfLayer_IsLocked (AI layer specific) flag query and is_locked to the PSDVLAYER driver parameter block.
#596 RIP direct monochrome image support added back in for performance. Converting monochrome images to full RGBA can use too much memory.
#597 Turn on emulation for small 1 pixel tall images; similar to the emulation for image masks (pathological input files).
#599 Missing error check on fflush (missed a disk full error)
#602 Odd PDF: embedded truetype font with no charmaps caused bomb
#605 PDF Write Type 3 FontBBox fix; Acrobat 8 Clipping problem if Alpha != 1
#607 RIP option for floating point image placement: define RIP_FLOAT_IMAGE_PLACEMENT - not the default yet (just in case)
#614 PDF float PSDVLINE line_width was still passed as an integer
#622 Odd PDF: Handle /Type /PagE name object as /Type /Page
The DvPatternPoly driver call is a mechanism to capture a pattern and claim responsibility for rendering polygons using that pattern. This can greatly increase performance and quality of pattern rendering.
Capturing and rendering is difficult, especially if the pattern matrix is arbitrary. The RIP can be used as a reference implementation.
Set gxc->want_patterns and the driver will get DvPatternPoly with a PSDVPATTERNPOLY when a pattern polygon is to be drawn. PSDVPATTERNPOLY contains a PSDVPOLY struct, along with a ClrPatPtr object representing the pattern. The Driver can fail the DvPatternPoly call (return !0;) and the normal pattern rendering will be invoked.
ClrPat methods specific to pattern capture:
ClrPat_GetPatternInfo(clrpat, clrpatinfo); ClrPat_ScalePatternInfo(clrpat, matrix); ClrPat_FillTemplate(clrpat, pth, winding);
There are two phases to DvPatternPoly implementation:
Capturing a pattern involves preparing a target for capturing the pattern, scaling the pattern, and invoking ClrPat_FillTemplate, which will cause the driver to be called with the operations drawing the pattern. ClrPat_Fill is the normal pattern rendering method; ClrPat_FillTemplate is like ClrPat_Fill except that is uses a different matrix and turns off clipping, so the pattern can be captured correctly.
It is up to the driver to prepare a buffer to capture the pattern and store it for later retrieval. Although storing the pattern between DvPatternPoly calls isn't required, it will increase the performance advantage. The RIP uses the Props mechanism (gco/notify.d). It stores the captured information in a GCO class object instance, and then attaches that object to the pattern implementation object returned by GetPatternInfo. Yes, this is cheating. Object Models can be very handy.
There are many subtleties in handling pattern matrices and rendering correctly. Some drivers may wish to skip skewed or arbitrarily rotated patterns and only implement normal or scaled patterns rotated on 90' bounds. This makes pixel rendering simpler.
Please contact Liberty Systems for assistance.