Bug 689980 - pxl driver doesn't obey to the OutputFile device attribute
Summary: pxl driver doesn't obey to the OutputFile device attribute
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PXL Driver (show other bugs)
Version: 8.62
Hardware: PC Linux
: P4 major
Assignee: Henry Stiles
Depends on:
Reported: 2008-07-25 12:12 UTC by Giampaolo Tomassoni
Modified: 2012-09-26 09:23 UTC (History)
3 users (show)

See Also:
Word Size: ---

Case test file showing the problem (427 bytes, text/plain)
2008-07-25 12:13 UTC, Giampaolo Tomassoni

Note You need to log in before you can comment on or make changes to this bug.
Description Giampaolo Tomassoni 2008-07-25 12:12:41 UTC
The pxlmono (and probably pxlcolor) driver ignores any further specification 
of the output file (in example through an << /OutputFile (something) >> 
setpagedevice) after it had generated the first pxl page.

This seems not conforming to the Adobe PS specifications. This may be related 
to bug#689230.
Comment 1 Giampaolo Tomassoni 2008-07-25 12:13:55 UTC
Created attachment 4239 [details]
Case test file showing the problem
Comment 2 Hin-Tak Leung 2009-01-20 17:38:12 UTC
Is it with or without -dSAFER?
Comment 3 Giampaolo Tomassoni 2009-01-21 01:03:17 UTC
I don't use -dSAFER, then I would say without it.
Comment 4 Hin-Tak Leung 2009-11-30 01:18:02 UTC
It is true that most setpagedevice commands have no effect on the pxl driver
once BeginPage has started.
Comment 5 Marcos H. Woehrmann 2012-09-04 22:02:42 UTC
Assigning to Henry who owns the pal devices.
Comment 6 Henry Stiles 2012-09-26 07:04:15 UTC
Yes without special provision no vector devices (gdevvec.h) will support this kind of behavior, I don't see any use for it in PXL and it would be quite difficult to implement.  If the file is changed all the active resources would have to be brought over to the new file.  Similarly pxlcolor and pxlmono do not support the popular ghostscript %d page number option for basically the same reason.  See the put_params comment in gdevvec.c:

    switch (code = param_read_string(plist, (param_name = "OutputFile"), &ofns)) {
        case 0:
             * Vector devices typically write header information at the
             * beginning of the file: changing the file name after writing
             * any pages should be an error.
            if (ofns.size > fname_size)
                ecode = gs_error_limitcheck;

Anyway I copied Ken in as it might be a curious file to try out with pdfwrite - a vector device which has recently been modified to do interesting things at page boundaries, but this is not a bug.

 I don't believe OutputFile is part of the Adobe Spec is it?
Comment 7 Ken Sharp 2012-09-26 07:51:01 UTC
I must have missed this one when first reported....

Henry is correct that OutputFile is not a standard key in the page device dictionary, so it behaviour is entirely at our discretion. 

As to our ignoring a change in value being contrary to the specification, the PLRM (3rd Edition) is quite clear:

"The operand to setpagedevice is a request dictionary whose entries specify
desired settings or values for one or more page device parameters.


Note that the entries in the request dictionary
are merely requests for certain parameter settings; depending on the capabilities
of a given page device, these requests may or may not be honored"

So all entries in the page device dictionary are entirely device dependent and it is entirely legal to ignore a request. 

In fact its even reasonable to process a request up to a certain point, and ignore subsequent ones. As an example consider Binding, it might well be possible for a device to bind either on the right or the left, but once you've started binding on one side, you can't realistically change to the other without starting a new job.

With pdfwrite this file results in a single page blank PDF file. Presumably the content is directed elsewhere, I have no idea where its going and am not keen on spending time trying to find out.
Comment 8 Ken Sharp 2012-09-26 07:59:26 UTC
I did just check this, and discovered that, *because* we are changing device from pdfwrite to pxlmono and then back to pdfwrite (save and restore in the job), the PCL files are created as expected, in the current working directory.

So if you really want this kind of behaviour that's one way to achieve it but note that this *only* work because we are switching devices with each setpagedevice.

If you set the device to pdfwrite in the PostScript it does appear to cope with this, and writes (PDF) files with the correct names.
Comment 9 Giampaolo Tomassoni 2012-09-26 09:23:44 UTC
Ok. I've found the relevant "note" from the Adobe specs and I too have to agree this vector devices behaviour is not in contrast with them.

Anyway, one would expect (rigtly or not) that the setdevice dictionary entries defined for a specific device would apply at the same time.

Can't the behaviour outlined by Ken in "switching" from one device type to another and then back to the first be somehow "emulated" in much more efficent manner by vector devices when a non-page-wide setpagedevice attribute gets changed?