Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'*MainKey OptionKey: StringValue' constructions in PPDs not supported #2551

Closed
michaelrsweet opened this issue Oct 6, 2007 · 1 comment
Closed
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

@michaelrsweet michaelrsweet commented Oct 6, 2007

Version: 1.1-feature
CUPS.org User: till.kamppeter

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.

@michaelrsweet

This comment has been minimized.

Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Oct 6, 2007

CUPS.org User: mike

Will not support this, ever.

Just fix Foomatic to support quoted strings, as required by the PPD spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.