Reported by sags5495 at hotmail dot com. Relates to the bug 563287 and the bug 607425. > From: "SaGS" <sags5495@hotmail.com> > To: <gs-devel@ghostscript.com> > Sent: Thursday, January 15, 2004 9:55 AM > Subject: [gs-devel] Re: [gs-cvs] gs/lib > > > ----- Original Message ----- > From: "Ray Johnston" <ray@ghostscript.com> > To: <gs-cvs@ghostscript.com> > Sent: Tuesday, January 13, 2004 6:38 PM > Subject: [gs-cvs] gs/lib > > > > Update of /cvs/ghostscript/gs/lib > > In directory casper:/tmp/cvs-serv29622/lib > > > > Modified Files: > > gs_pdfwr.ps > > Log Message: > > Fix to prevent setdistillerparams from erasing the page device or reset > > the page device parameters. Fixes bugs 563287 and 607425. > > > > DETAILS: > > > > The .putdeviceparamsonly function defined in gs_setpd.ps is designed to > > set device properties without clearing or resetting the pagedevice. > > ... > > This change solves the problems in bugs 563287 and 607425, and also > distillerparams aren't affected by gsave/grestore anymore (which is OK; this > limitation is mentioned somewhere in the docs, and the mention needs to be > removed now). BUT it introduces another problem: they aren't affected by > save/restore and they should be. I tried the same idea, but got lost in the > various GS memory allocators. I think what's needed is either (1) handle > these > params at PS level too, and change restore to send the restored values to > pdfwrite (with problems, since another device may be the current device) or > (2) make the driver save/restore-friendly (= check .savelevel/ l_new/ etc > and > act appropriately). I personally consider method (2) better, because of > better > performance and because it is more object-oriented, even if it means that > more knowledge on the interpreter's memory management "leaks" at the > device/library level.
Are there any files that depend of 'restore' restoring distillerparams. Of our test suite, there are limited files that even use setdistillerparams and they all do so in the prefix section before anything is produced/drawn. Until we have a 'real world' example, this will be put at a low priority.
No, I do not have a "real world" file that depends on "restore" restoring distiller parameters. But, instead of looking for an INDIVIDUAL file, think what happens with a "PDF print server": (1) An exitserver job establishes defaults that subsequent jobs are supposed to rely upon; (2) A particular job needs some parameters set differently, and calls setdistillerparams to change these; (3) The changes survive the job-level "restore", and become defaults for the next jobs. (4) These "next" jobs will have unintended results, and, worse, one job's result depends on what jobs happen to have been processed before it. (Of course, if each job sets ALL distiller params, and does not depend on any defaults, results are predictable). Bug #687280 that I just added includes a test file for this bug too (not a "real world" one, but one created specifically for testing). (PS: Sorry for responding so late, I have problems with my Internet connection.)
OK so there is little real documentation on the setdistillerparams operator, and what there is doesn't make it clear whether this should honour save and restore. The nearest I can find is one of the Distiller Parameters reference where it says 'PostScript language programs that use these operators must not assume that any particular key is present in the dictionary returned by currentdistillerparams, or that setdistillerparams has any particular side effects.' behaviour with save and restore could reasonably be described as a particular side effect. That said, Adobe Acrobat Distiller *does* honour save and restore. Clearly Distiller works in a different fashion to pdfwrite, presumably it consults the current distillerparams dictionary whenever it needs a parameter. Doing this in pdfwrite isn't impossible, but I think it would be horrendously slow and I can't see any other reasonable way to deal with the problem presented here. Now given that its been 9 years since this was reported, and the other 'real' problems relating to this have been fixed, I think its time to be honest and admit we're never going to address this. At least not unless a commercial customer complains a lot. So I'm closing this as 'wontfix', not because its not a bug but because I prefer to be open and admit it.