[cups.general] .types parsing rules and syntax

[Michael R Sweet]

On Apr 1, 2009, at 8:18 AM, Nik Svoboda wrote:
>
>   From experiences with creating custom types rules for the 1.3.X  
> line of CUPS, I believe I do not fully understand how the syntax and  
> parsing works.
>
> 1) First as a note: From searching this list, I realize now that the  
> ' ascending ordering' mentioned in the documentation is alphabetical  
> order, not order read by the daemon. The mime.types file mentions  
> this as, "Type names are sorted in ascending order, so if two types  
> use the same rules to resolve a type (e.g. doc extension for two  
> types), the returned type will be the first type in the sorted  
> list." IMO, this should be mentioned using the term 'alphabetically  
> ascending order.'
>

You are the first person to bring this up in 11 years; file a bug  
against the documentation:

     http://www.cups.org/str.php

> 2) Why does the following crash the daemon at startup...:

It shouldn't, please file a bug:

     http://www.cups.org/str.php

>   The difference is the use of && instead of + as the AND operator.  
> The use of && is also never documented officially on the cups site  
> or in the files that i couls find. I noticed it from an IBM white  
> paper on their cups setup.

&& is not supported.

> 3) Following up, what is the actual difference between && and + as  
> the AND operator?
>

&& is not a supported operator and will be interpreted as an extension.

> 4) How is NOT (!) interpreted?

NOT applies only to the next expression.

> I have noticed that any sections of NOT (!) rules must be in one  
> contained expression and must be before the positive rules as in 2).  
> For instance, the following will not seem to work as intended:
> *****************
> !contains(0,128,"Cheese") + \
> !contains(0,128,"this is not postscript") + \
> contains(0,128,"rules matching postscript")
> *****************
> contains(0,128,"rules matching postscript") + \
> !contains(0,128,"this is not postscript")
> *****************
>   However, the following will work:
> +++++++++++++++++
> !(contains(0,128,"Cheese") \
> contains(0,128,"this is not postscript")) && \
> contains(0,128,"rules matching postscript")
> +++++++++++++++++
> !contains(0,128,"this is not postscript") + \
> contains(0,128,"rules matching postscript")
> +++++++++++++++++

Please file a bug and include sample files.

> 5) Extra whitespace is not always interpreted correctly. For  
> instance, this will be treated as an OR statement (whitespace shown  
> as underscores):
> *****************
> application/specialpostscript___contains(0,1024,"a postscript rule")_ 
> +_\____
> ________________________________(ai_eps_ps_string(0,%!)_string(0,<04> 
> %!)_\
> *****************
>  And this will correctly be treated as an AND statement:
> +++++++++++++++++
> application/specialpostscript___contains(0,1024,"a postscript rule")_ 
> +_\
> ________________________________(ai_eps_ps_string(0,%!)_string(0,<04> 
> %!)_\
> +++++++++++++++++
>   Does anyone else see this problem?

Nobody has reported them.  Please file bugs.

____________________________________
Michael R Sweet, Senior Printing System Engineer