Oct 9, 2008 by Till Kamppeter:
This is already intended to be fixed by Mike Sweet, according to the forum posting mentioned below, but I post it also here to not get forgotten.
See the discussion on the cups.bugs newsgroup/mailing list around STR #2964, especially this posting from Mike Sweet:
http://www.cups.org/newsgroups.php?s5380+gcups.bugs+v5387+T0
This makes pstops working perfectly with PostScript input where an application (or the CUPS PostScript driver for Windows) has inserted PostScript code of PPD option settings, as default settings get inserted before these insertions and so the settings applied by the insertions are not reset to the defaults by the settings inserted by pstops.
pstops inserted the default settings in the beginning of each section in CUPS 1.1.x. So this is a regression.
For handling of IncludeFeature commands I suggest, in contrary to Mike's posting, to insert the code exactly at the place where the IncludeFeature command is (or do the PostScript/PPD/DSC specification tell something different?).
Oct 9, 2008 by Michael Sweet:
This change is already in 1.3.x and trunk
As for inserting IncludeFeature where it is found in the PostScript file, that won't work - applications that don't know how to handle OrderDependency data are most likely to use IncludeFeature, and if you send PostScript commands in the wrong order bad things happen on many PostScript printers.
Unfortunately, the DSC doesn't address order dependencies at all, which makes IncludeFeature non-functional for some options that are only supportable at the document level.
To summarize what we currently output:
1. Default options from PPD
2. Begin/EndFeature code from PS file
3. IncludeFeature code plus default options, as needed, from PPD