Could I somehow upload the pcl file and mark it private? I don't want other
users to have access to it.

Files can be uploaded using "Create Attachment", then after the file is
uploaded, the 'Edit" link for the attachment can be used to check the 'Private'
box. Only Artifex Software staff or consultants under contract (which has an
NDA clause) will have access.

As supported customers, you can also simply send the file via email.

Created attachment 4741 [details]
Zncb05.zip

I need the exact command line as run from the AIX system and any changes made to
the makefile (i.e. adding devices) to work on this problem.

Note there are more than 20,000 pages in the attached file.

Answer to comment #5: 
I know that the file is very large, but same file is 
transformed ok on the same AIX 5.3 machine when GhostPCL 1.53 is built in the 
debug mode, so I assume it's nothing wrong with the AIX machine. 
Also sending this file to GhostPCL 1.50 built in both release and debug mode,
it is successfully transformed.

Answer to comment #4:

The command we call is:
pcl6 -dNOPAUSE -r300 -sDEVICE=tiffg4 -sOutputFile=Zncb05.pcl.tiff Zncb05.pcl

And the changes to makefile are:
DEVICES_DEVS?=$(DD)ljet4.dev $(DD)djet500.dev $(DD)cljet5pr.dev $(DD)
cljet5c.dev\
   $(DD)bitcmyk.dev $(DD)bitrgb.dev $(DD)bitrgbtags.dev \
   $(DD)pcxmono.dev $(DD)pcxgray.dev $(DD)pcxcmyk.dev $(DD)pswrite.dev $(DD)
pdfwrite.dev\
   $(DD)pxlmono.dev $(DD)pxlcolor.dev\
   $(DD)bmpmono.dev $(DD)bmpsep8.dev \
   $(DD)pbmraw.dev $(DD)pgmraw.dev $(DD)ppmraw.dev \
   $(DD)png16m.dev $(DD)pngmono.dev $(DD)jpeg.dev \
   $(DD)wtscmyk.dev $(DD)wtsimdi.dev $(DD)imdi.dev \
   $(DD)romfs$(COMPILE_INITS).dev \
 $(DD)tiffcrle.dev $(DD)tiffg3.dev $(DD)tiffg32d.dev $(DD)tiffg4.dev \
 $(DD)tifflzw.dev $(DD)tiffpack.dev \
 $(DD)tiff12nc.dev $(DD)tiff24nc.dev

I can't reproduce this on linux or Mac OS X and don't have access to an AIX
system, reading IBM's AIX documentation, 2.0 Gigabytes is the maximum file size,
see:

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.itame3.doc_5.1/am51_perftune35.htm

so perhaps you should find a different way of storing the data in the first
place.  Individual pages can be saved with, for example, -sOuputFile=foo.%d
where the page number will be fill the %d placeholder.  I'll assign this back to
support, if more information becomes available I'll work on it again.

Last year we migrated the GhostPCL code from AIX 5.1 to AIX 5.3 and 
we had some problems while doing this. We encountered three types
of problems:
- a segmentation fault for one large pcl file
- an overlapping text issue for many pcl files
- a problem with some graphical objects

Here are the changes we did:

1. In file ..\gs\src\gsmatrix.c, in function gs_distance_transform_inverse 
replace:
double det = pmat->xx * pmat->yy - pmat->xy * pmat->yx;
with
double det = (double)pmat->xx * (double)pmat->yy - (double)pmat->xy * 
(double)pmat->yx;

2. In file ..\gs\src\gstype42.c, in function append_simple replace:
uint np = npoints;
with
int np = npoints;

3. In file ..\ufst\rts\dep\cgif.c, in function CGIFwidth replace:
UW16    chId;
with
UL32    chId;

We know for sure that the overlapping text issue was solved by the third change,
but we don't remember certainly which change (1 or 2) fixed the segmentation
fault problem.

Now, we did the same three changes in GhostPCL 1.53 code and the problem
initially reported in this defect was solved.

Our question is: do you agree to include these changes in your mainstream?

Thanks

Change 1 shouldn't be a problem, I've forwarded proposed the engineer in charge of the matrix math 
functions for confirmation.

Change 2 is more of an issue, the variable npoints is an unsigned value, so assigning it to a signed int 
might be a problem.  I've contacted the responsible engineer to see what he thinks.

Change 3 appears reasonable as well, since chId is later assigned to be first_chId and that's declared as an 
UL32.

As suspected change #2 is causing us some confusion.  Changing np from a uint to an int shouldn't 
change the behavior of the code and  would violate the TrueType spec which says that value is unsigned. 

Can you verify that change #2 actually produces a difference in the output and provide us with a sample 
file?

We remembered what we did last year.
1) Solved some Genoa test cases. T310.BIN is one of them. I can provide you 
with the file if needed
2) Solved the segmentation fault for which I initially opened this defect. So 
the test case for this is the attachment of this defect - Zncb05.pcl. When 
doing this fix, we obtain good output. Without the fix we got segmentation 
fault and of course 0 bytes output.
3) Solved the overlapping text issue. If there is a need I can also provide 
test cases

We believe change #2 in comment #9 masks an underlying problem which is being
addressed in 690541.  We will recheck this bug when that is fixed.

Regarding #3 in Comment #9:  This change isn't in our code, so even if we agreed to the patch the next 
update from the vendor would undo that change.  We suggest you contact the vendor directly.

Please retest the T310 segmentation fault with this patch below, revision 9798,
(without your patch) on your system(s), thank you.  

This bug is being fixed because it came up for other customers.  I still haven't
heard from Miles that there is any change in customer priority so the other open
bugs are not likely to be addressed soon.

Index: pxgstate.c
===================================================================
--- pxgstate.c	(revision 9794)
+++ pxgstate.c	(working copy)
@@ -615,12 +615,22 @@
 const byte apxSetCharShear[] = {
   pxaCharShear, 0, 0
 };
+
+ /* experiments indicate the character shearing operands are
+    clamped after range checking though it is not documented in
+    the HP manual. */
+
+#define SHEAR_LIMIT 16383.0
+
 int
 pxSetCharShear(px_args_t *par, px_state_t *pxs)
 {	real x_shear = real_value(par->pv[0], 0);
 	real y_shear = real_value(par->pv[0], 1);
 	px_gstate_t *pxgs = pxs->pxgs;
 
+        x_shear = x_shear > SHEAR_LIMIT ? SHEAR_LIMIT : x_shear;
+        y_shear = y_shear > SHEAR_LIMIT ? SHEAR_LIMIT : y_shear;
+
 	if ( x_shear != pxgs->char_shear.x || y_shear != pxgs->char_shear.y ||
 	     pxgs->char_transforms[0] != pxct_shear
 	   )

I am closing this for now, it seems we've done what we can do without access to
an AIX machine.

Changing customer bugs that have been resolved more than a year ago to closed.