Bug 691472 - PDF 1.7 FTS: /unregistered in --showpage--
Summary: PDF 1.7 FTS: /unregistered in --showpage--
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: PC Linux
: P1 normal
Assignee: Michael Vrhel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-18 15:54 UTC by Alex Cherepanov
Modified: 2011-09-18 21:46 UTC (History)
0 users

See Also:
Customer: 532
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Cherepanov 2010-07-18 15:54:26 UTC
File fts_23_2303_a4.pdf fails with

Error: /unregistered in --showpage--
Operand stack:
   1   true
Comment 1 Ray Johnston 2010-07-18 18:26:35 UTC
This file takes a _long_ time to get to the OutputPage start time 925 sec
on my 3GHz i5 with 1333 MHz DDR3 ram (running Win 7 64-bit build). This is a
REALLY long time considering that it only writes a small clist:

   % Start time = 0.227, memory allocated = 2975432, used = 2781902
   [:]width=4967, band_width=4967, band_height=128, nbands=55
   % Outputpage start time = 925.239, memory allocated = 5633960, used = 5402829
   [:]clist_end_page at cfile=1730785, bfile=2808

The exact command line I am using is:

gswin32c -Z: -r600 -dMaxBitmap=10000 -dBandHeight=128 -q -sDEVICE=png16m -o x.png fts_23_2304_a4.pdf

Then when rendering the band beginning at line 2304, I get a segfault in
gx_default_copy_color with a bad 'data' pointer. Note also that the 'dx' value
is also suspect = 0x64646248 (which would be ASCII "ddbH").

This looks like it might be a clist problem which could end up with returning
the 'unregistered in showpage' if the clist playback gets an error. A 32-bit
build may get the 'unregistered' error.
Comment 2 Ray Johnston 2010-07-19 16:41:42 UTC
Hmm... gs8.71 and the customer's version (mostly 8.71) complete this without
a problem and also run in a reasonable time (Outputpage start in .64 sec,
rendering completed in 4.4 sec)

Command line options: -Z: -sDEVICE=png16m -o 2304.png -r600 -dBandHeight=128
Comment 3 Alex Cherepanov 2010-07-24 01:36:20 UTC
This bug first appears in the following revision:

r9666 | mvrhel | 2009-04-20 15:16:24 -0400 (Mon, 20 Apr 2009) | 128 lines
This is a merge of the smask_work branch into the trunk.  The merge fixes issues
related to missing soft masks, improperly rendered soft masks and transparency...
Comment 5 Michael Vrhel 2010-08-24 05:46:47 UTC
Narrowed this down to the fact that we are doing a mask fill with pattern from the clist but we are using the wrong procs to do the tile fill since the pattern has transparency.  This should be easy to fix since the tile and the mask are packed in the clist.  Just need to get things set up properly at clist read time based upon the fact that we are doing a mask fill.  I will have something for this soon.
Comment 6 Michael Vrhel 2010-08-24 22:11:47 UTC
I have this fixed now.  There is a bigger picture here of making sure all the mask fills with patterns that have transparency work correctly.  When I verify that all the cases are handled I will test and commit.
Comment 7 Michael Vrhel 2010-09-09 15:42:42 UTC
Fixed with rev 11700
Comment 8 Marcos H. Woehrmann 2011-09-18 21:46:31 UTC
Changing customer bugs that have been resolved more than a year ago to closed.