[cups.bugs] [LOW] STR #1907: Problem printing GMT PostScript

Michael Sweet mike at easysw.com
Tue Aug 15 07:29:43 PDT 2006


Helge Blischke wrote:
> Michael Sweet wrote:
>> Helge Blischke wrote:
>>
>>> Michael Sweet wrote:
>>>
>>>> [STR Closed w/o Resolution]
>>>>
>>>> This file does not conform to the Adobe Document Structuring 
>>>> Conventions,
>>>> yet claims to be conformant.
>>>>
>>>> The main issues are:
>>>>
>>>>     1. There are two %%EndProlog comments in the file
>>>>     2. The #copies variable is set outside the Begin/EndSetup block and
>>>> does not use Begin/EndFeature, making it impossible to override the 
>>>> number
>>>> of copies.
>>>>     3. The scale command in the Begin/EndSetup block is illegal in that
>>>> context - it must appear in the Begin/EndPageSetup since it affects the
>>>> graphics state.
>>>
>>> That is not true. The DSC spec (5001.DSC_Spec_v3.0.pdf) states 
>>> concerning
>>> the setup section:
>>>     • The document setup section is denoted by the %%Begin(End)Setup
>>>     comments. The document setup should consist of procedure calls for
>>>     invoking media selections (for example, setting page size), running
>>>     initialization routines for procsets, downloading a font or other 
>>> resource,
>>>     or setting some aspect of the graphics state. This section should 
>>> appear
>>>     after the %%EndProlog comment, but before the first %%Page: comment.
>>> and, later on, dealing with page independence:
>>>     Pages should not have any inter-dependencies. Each page may rely on
>>>     certain PostScript language operations defined in the document 
>>> prolog or in
>>>     the document setup section, ...
>>>
>>> Thus, the scale command in the setup section is perfecly legal 
>>> (though the cited
>>> document warns on possible pitfalls by relying in graphics state 
>>> settings in the
>>> document setup section later on.
>>
>>
>> Scaling in the DocumentSetup section breaks page independence, such
>> that it is then necessary to treat EVERY page as its own document...
>>
> No, not at all. The prolog and setup section define and specify what
> applies to ALL pages in the job, and in this environment the pages ARE
> independent of each other, if the guidelines as stated in the cited paper
> are obeyed. Any deviation from the "overall setup" of the job within a
> page requires bracketing with gsave and grestore (if only the graphics
> state is concerned) or even with save and restore.

Any printer that has an option with "PageSetup" as the order
dependency section will break a document that changes the graphics
state in the document setup section.  In order to print documents
that change the graphics state outside of a page description on such
a printer, you have to send every page as a separate document which
prevents use of common finishing options like two-sided printing.

Given the wording on Page 24 of the DSC concerning page independence,
specifically the sentence beginning with "It is also risky to reimpose
or rely on a state defined in the document setup section", it is
pretty clear that setting the graphics state in the document setup
section will lead to undefined behavior on some printers, which is
exactly what the reporter is experiencing.

The short of it for any developer providing a PostScript file to CUPS
is this: you MUST NOT change the graphics state outside the page
description if you want your file to print consistently on all
printers.  I have a work-in-progress help file in CUPS trunk that
will discuss this point in great detail...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com




More information about the cups mailing list