Starting with r10324 GhostPDL generates PDF files that are not readable by Ghostscript nor Acrobat from the following input files: ./tests_private/pcl/pcl5efts/fts.1540 ./tests_private/pcl/pcl5cfts/fts.1870 ./tests_private/xl/pcl6cet3.0/C705.bin Example command line: ./main/obj/pcl6 -sDEVICE=pdfwrite -sOutputFile=test.pdf -dNOPAUSE ./fts.1540 Acrobat produces the message: T here was an error opening this document. The file is damaged and could not be repaired. Ghostscript output: GPL Ghostscript SVN PRE-RELEASE 9.00 (2010-07-31) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. **** Error: Cannot find a %%EOF marker anywhere in the file. **** Warning: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. Error: /undefined in --run-- Operand stack: 5 0 1 --dict:5/5(ro)(G)-- (obj) Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push --nostringval-- %loop_continue --nostringval-- Dictionary stack: --dict:1155/1684(ro)(G)-- --dict:1/20(G)-- --dict:82/200(L)-- --dict:82/200(L)-- --dict:108/127(ro)(G)-- --dict:290/300(ro)(G)-- --dict:20/25(L)-- Current allocation mode is local
Created attachment 6587 [details] rf_stroke.pcl pattern stroke color produces bad pdf pcl6 -sDEVICE=pdfwrite -sOutputFile=stroke.pdf rf_stroke.pcl
Created attachment 6588 [details] rf_fill.pcl This file is nearly the same as attachment 6587 [details] except it uses a fill instead of a stroke and it works correctly!
(In reply to comment #2) > This file is nearly the same as attachment 6587 [details] except it uses a fill instead > of a stroke and it works correctly! When we get to the end of job with the stroke file the curr_device has a reference count of 2, which means we don't count down the pdfwrite device to 0 and free it, so we don't write out the final contents and xref. The fill file has a reference count of 1, so its OK. Its yet another reference counting problem, I guess I haven't tracked strokes down with this problem yet, I think most of the examples so far have been pattern fills.
(In reply to comment #2) > Created an attachment (id=6588) [details] > rf_fill.pcl > > This file is nearly the same as attachment 6587 [details] except it uses a fill instead > of a stroke and it works correctly! It also has a different PaintType. In gxpcmap.c, gx_pattern_load, pinst->template.PaintType is 1 for the fill and 2 for the stroke. According to the comments in pattern_accum_open PaintType 1 == colored and PaintType 2 == uncolored. However, making that 1 in the debugger doesn't solve the reference counting problem.
(In reply to comment #4) > (In reply to comment #2) > > Created an attachment (id=6588) [details] [details] > > rf_fill.pcl > > > > This file is nearly the same as attachment 6587 [details] [details] except it uses a fill instead > > of a stroke and it works correctly! > > It also has a different PaintType. In gxpcmap.c, gx_pattern_load, > pinst->template.PaintType is 1 for the fill and 2 for the stroke. According to > the comments in pattern_accum_open PaintType 1 == colored and PaintType 2 == > uncolored. > > However, making that 1 in the debugger doesn't solve the reference counting > problem. Sorry to bother you with this one ken, definitely was my bug - fixed in revision 11591.