[cups.bugs] [HIGH] STR #2551: '*MainKey OptionKey: StringValue' constructions in PPDs not supported

[Till Kamppeter]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

The expression

*FoomaticRIPOption PrintoutMode: enum Composite B

is completely legitimate according to the Adobe specs:

http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf

According to page 3 and 4 it is a

*MainKey OptionKey: StringValue

construction. On page 23 it is stated that a StringValue is without quotes
and white space is allowed.

So this line fully complies with the Adobe specs and so applying ppdi and
afterwards ppdc must return the original line. The *.drv format must
support all the 7 basic statement structures defined on page 3 and 4 of
the Adobe specs.

What happens is that ppdi makes

Attribute "FoomaticRIPOption" "Model" "enum Composite B"

out of it in the *.drv file, and ppdc turns this one into

*FoomaticRIPOption PrintoutMode: "enum Composite B"

which is a '*MainKey OptionKey: "InvocationValue"' construction. The
problem here is that the *.drv format uses the same representation for
both '*MainKey OptionKey: StringValue' and '*MainKey OptionKey:
"InvocationValue"' and so information gets lost on the ppdi/ppdc round
trip. To fix this distinct expressions for all the 7 basic statement types
have to be introduced into the *.drv format. For example

Attribute "FoomaticRIPOption" "Model" enum Composite B

(no double quotes around the StringValue) could represent the '*MainKey
OptionKey: StringValue' construction.

As CUPS DDK should not be only a helper to make PPDs for CUPS raster
drivers but also to do general PPD manipulation, especially joining
manufacturer-supplied PostScript printer PPDs to multi-language PPDs it
should handle everything correctly which is allowed by Adobe.

Link: http://www.cups.org/str.php?L2551
Version: 1.2-current