CentraDoc 6.1 contains a variety of fixes and enhancements since the 6.0 release.
Here are the highlights:
This document is current as of the 6.1.4 Release
IMPORTANT
One consequence of the Pth/Path unification is that PS_PTHTYP (the t_pts field in PSDVCLIP, PSDVLINE and PSDVPOLY) can now contain a Close directive. This could cause problems in drivers that don't handle it explicitly. Close can be treated as a Draw command, although Close for Polylines should control how the lines are joined.
The include file psplat.h has gone away; there are no more compile-time configuration defines. This eliminates any "motion" in the PS_CONFIG definitions at compile-time, which could cause arbitrary bombs.
It is still possible to cause arbitrary bombs by mixing DEBUG and NDEBUG compiled objects in the same link. This may be addressed in future releases.
Several fields have been dropped; some that were no longer in use, and the PSPATFILL mechanism has been completely replaced and mostly migrated out to client-specific code.
These fields are the replacement for the PSPATFILL mechanism:
ImageTrapProc img_trap; /* return 0 = don't trap, !0 = trap */ void *img_trap_parm; /* arbitrary parameter 1 */
These fields add support for page-based rotation and scaling. They are used by the PvSDK interface to support orientation parameters, and by the auto_page_translate mechanism:
float transx; float transy; int rotation; /* 90 degree increments counterclockwise */ float pagetransx; /* auto_page_translate */ float pagetransy; int pagetranslated; /* flag */
It is best to use convenience calls instead of accessing these fields directly:
void psisetupxform(PS_CONFIG *psc,
float scalex, float scaley,
int rotation,
int width, int height,
int xdpi, int ydpi);
void psitranslate(PS_CONFIG *psc, float dx, float dy);
The PsHt object has been re-introduced to the gxs after being dropped. This is solely for the use of the driver (cast to PsHtPtr, see psht.d):
void * halftone_object; /* Pointer to the halftone PSI object */
These fields have also been added, though it is unlikely the driver will need to look at them:
int text_mode; /* optional: PDFREF 5.2.5 */ int has_transfer; /* do we have transfer procs/tables? */ unsigned char transtab[4][256]; /* Current transfer tables */
These fields enable new driver signals:
int want_comments; /* sends DvComments */ int want_finetext; /* send DvBegin/EndFineText */ int want_pdfmark; /* send DvPdfMark for pdfmark pseudo-op */ int want_runfile; /* send DvBeginRunFile & DvEndRunFile w/FileName */ int want_gstate; /* send DvGState init, save, restore */
DvComment sends Postscript comments via PSDVCOMMENT struct, which contains a char pointer with explicit length.
DvBegin/EndFineText are signals to mark start and end of the PDF TJ operator. PSDVFINETEXT contains the fine text parameter information.
DvPdfMark sends the Postscript pdfmark operator to the driver passing a PS_OBJECT containing the array of parameters from the operand stack.
DvBeginRunFile and DvEndRunFile are executed at run or exec file time. The intent is to allow the driver to capture "forms-based" postscript subfiles. The DvBeginRunFile can return 0 to block execution of the subfile. Since the behavior of a subfile will depend a lot on context, it's not clear yet how useful these calls will be. The file name is passed as a parameter. Note that the initial file run is also included in the DvBeginRunFile and DvEndRunFile calls.
DvGState sends signals at graphics state maintenance times: kGStateInit, kGStateSave, and kGStateRestore. PDF distiller drivers may need these signals to maintain transparency contexts correctly. The PSDVGSTATESIG parameter contains the state signal.
The want_textmode flag specifies that the driver handles text_mode in PSDVTEXT. Test rendering mode values come from the Pdf Reference. The supported modes are:
0 == Fill 1 == Stroke 2 == Fill then stroke 3 == Hidden
The clip based modes are not currently supported. Text mode can come from PDF files (Tr) as well as PS files (charpath stroke):
int want_textmode; /* supports text rendering mode */
The smart_line_width field disabled the line emulation based on how the current transformation matrix affects line width artifacts. The affects of transformations on wide lines can be subtle:
int smart_line_width; /* don't emulate stroke based on
transformed line_width x/y ratio */
This sets the default value for overprint mode in the graphics state:
int default_overprintmode; /* inital gxs->overprintmode */
In order to support floating point, the relevant driver parameter structs have a PthPtr added. The Pth object contains the floating point data for the current path for line and stroke operations. Also, the clipping stack is passed as a stack of Pth objects. See pth.d for the Pth interface.
Other fields have been added to supplement existing integer fields, instead of replacing them, for compatibility. For example, PSDVLINE still contains INT4 width, but float line_width has been added. PSDVTEXT has fpt and fendpt to supplement pt and endpt.
Due to some confusion over the adjust parameters in PSDVTEXT, supplemental parameters d_adjust_xy and d_char_adjust_xy have been added. These contain values in device space, instead of character space, which make them much easier to deal with.
PSDVFONT has additional fields, origmtx and scalemtx. These are intended to help detect and deal with the occasional off-by-1000 matrix problems. Even though the drivers generally deal with a font matrix of .001, some Postscript constructs assume or set the font matrix to be 1.0, which can cause surprising results. The psdvwin windows driver has an example sanity check in the FtSet handling.
The in_gradient field has been added to the PSDVPOLY to clarify the shading state. This is a duplicate of the grad_fill value in gxs, but drivers should avoid looking at PSI internal variables (psc/gxs/gxc) as much as possible.
PSDVCHAREM has an additional unicode value to clarify the character being emulated, if the unicode value (instead of CID) is known.
The PDF convention of fnt->embedded_font = (PS_DICT *)1 has been removed. This was ugly and error prone. If the driver needs to know if the font is embedded, the correct test for PDF is to call FNT_IsEmbedded(fnt->fntptr), if fnt->fntptr != 0.