Bug 688475

Created attachment 1898 [details]
Demonstration file, output from ps2ps2

Created attachment 1900 [details]
Modified sample file

Most likely currentblackgeneration on the Xerox printer returns a local object
even in the global mode. So we have to create a global copy of the composite
objects. In any case, this is a good idea because the returned object
can be volatile. Please try the modified file.

One more observation. The sample files work on Distiller 3 but crash (SEGV)
Distiller 5 on Windows NT.

Thanks for the attempt, but I am still getting an error. It is now far less
helpful, though; the output says

ERROR:
invalidaccess
OFFENDING COMMAND:
]
STACK:
--nostringval--
--nostringval--
--nostringval--
--nostringval--
-mark-
-mark-
-mark-

Created attachment 1907 [details]
modified file, 2nd attempt

Please try this version of the file.

Thanks for trying.  Got a third, different error:

ERROR:
invalidaccess
OFFENDING COMMAND:
currenthalftone
STACK:
/HT
/InitialExtGState

Created attachment 1908 [details]
3rd attempt

We are getting through... but this is an error on the printer side.
Apparently, the printer cannot return the current halftone in the global
context.
Please try this version.

Further along, but still erroring:

ERROR:
invalidaccess
OFFENDING COMMAND:
currentpagedevice
STACK:
792
612
--nostringval--
5

Created attachment 1910 [details]
4th attempt

Apparentlly, currentpagedevice operator cannot be executed in the global
context either. Let's try this version.

Another invalidaccess. If you want to give up and mark this "won't fix", I
completely understand.

ERROR:
invalidaccess
OFFENDING COMMAND:
copy
STACK:
--nostringval--
--nostringval--
--nostringval--
12
true
-mark-
-mark-
-mark-

Created attachment 1912 [details]
hack2.ps.gz  compressed file, 5th attempt

This is the sample file with a commented header (and all the earlier fixes).
The last error indicates a problem copying the font to a global dictionary.
It looks like the font itself is global but some of the keys are local.
This cannot happen in PostScript but somehow it does.
Please decompress and try the sample file. It should generate
better error messages.

OK, this time I got a bit more involved... First, you said you included all
previous fixes, but the first error I got was invalidaccess/currenthalftone, so
I looked and your currenthalftone fix was missing. I edited the file to put it
back in.  At this point I think my text editor (vim) mucked with the line
endings and destroyed the PDF pointers; the next error was something about U~
being undefined. I tried again, this time being more careful of line endings.
Now I got this error:

%%[ Error handled by opdfread.ps : undefined; OffendingComand: aaaa ]%%
%%[ STACK:
/Private
--nostringval--
--nostringval--
true
--nostringval--
12
true
-mark-
-mark-
-mark-
%%]%

I looked in the postscript and found "aaaa", right in the middle of a routine
redefining copy. I figure you put it in there on purpose to get some information
out. But just to try it, I changed it to "(aaaa)" and got this:

%%[ Error handled by opdfread.ps : typecheck; OffendingComand: copy ]%%
%%[ STACK:
aaaa
/FontMatrix
aaaa
/FontBBox
aaaa
/$SELF$
aaaa
/Private
--nostringval--
--nostringval--
true
--nostringval--
12
true
-mark-
-mark-
-mark-
%%]%

Hope this helps nail it down ... it seems to me that the 12 is from the font
size setting within the PDF, so maybe it's caught inside /SetFont?

There's an easy fix! Please take the original file and concatenate it with
the following header.

%!
/setglobal /pop load def

We don't use any memory optimizations right now and running the file in
the local mode should work for now.

We still would like to make the original design work for the planned
extensions. Please try to appli this patch to your last version

--- hack2.ps	2006-01-06 20:41:52.000000000 -0500
+++ hack3.ps	2006-01-06 20:53:51.000000000 -0500
@@ -244,7 +244,7 @@
 /copy_dict {
   currentglobal exch
   dup gcheck setglobal
-  dup length dict copy
+  dup length dict systemdict /copy get exec
   exch setglobal
 } bind def
 
Thank you for your patience.

Adding here some quotes from my and Alex's discussion :

> It looks like a font is a local object on the Xerox printer.

I'm not clear what do you mean exactly.
First it creates a font dictionary, then involves 'definefont'.
Do you mean that 'definefont' fails when the allocation mode is global ?
Why ? Does the dictionary store some local values ?

> The file opdfread.ps defines all the structures in the global memory
> but it doesn't use "save" operator anywhere. There's "restore"
> but it seems to be never used. So what's the point?

The point is a further improvement with a memory cleanup
on end of a contents stream.

The current implementation sets the global allocation mode
while reconstructing the PDF document structure, including
all PDF resources. The local allocation mode is set
when running a contents stream. However if a contents stream
operator requires a change in resource tree, it sets the
global allocation mode temporary.

With your patch the current implementation may work,
but it complicates further development.

Note that the current implementation has a problem
with patterns. It implements PDFR_Patterns
in local memory to store patterns, because makepattern returns a local
object.
(I'm not sure whether it's a Postscript feature, or the HP printer feature).

I'm aware changing anything in opdfread because
it requires to repeat testing on the reference printer,
which is a waste of a thousand of paper sheets and
a lot of man*hours. Therefore I'd like to have a better
understanding what exactly happens with Xerox.

There are several ways to resolve this bug :
1. If Xerox is not a legacy PSLL3, close as invalid,
since its not a customer bug. If a customer appears,
will request a payment for a special implementation.
2. Fix local values of the font dictionary,
which appear on Xerox, maybe inserting a
product depending branches of code.
3. Dynamically check whether 'definefont' requires
a local allocation mode, and implement something
similar to PDFR_Patterns in that case.
4. Create a printer dependent versions of opdfread
(don't like this due to harder maintenance).
5. Maybe something else which I can't imagine now.

In any case I would not set any global constraints,
such as "all works in local memory only".

Let me know if you need more hours than
the "discipline" allows.

> There's "restore"
> but it seems to be never used

I would appreciate if you remove the "ehsave" stuff.
It appears a rudiment.

Leo.

I'm not positive what PSLL3 means, but if it means PostScript Language Level 3,
then no, this is defintely NOT a PS Level 3 device. It is a PS Level 2 device. I
thought the purpose of this driver was to output PS Level 2?

Anyhow, you are correct that in local mode (with setglobal defined away) it does
work fine. For my purposes that will be plenty good enough.  

Later I will try the other patch you mentioned.

Sorry the following statement is a misprint :

>  1. If Xerox is not a legacy PSLL3, close as invalid,

It should read like this :

1. If Xerox is not a legacy PSLL2, close as invalid,

*** Bug 688718 has been marked as a duplicate of this bug. ***

Please check whether the current version (8.71) resolves the reported issues.
Many bugs have been fixed since v. 8.53 including a few bugs in ps2write device.
Xerox 92C is large and difficult to find device.
Feel free to reopen this bug report if the problem is not yet resolved.