MIME type matching not working as expected

[Christoph Erdle]

On 15.12.10 20:43, Helge Blischke wrote:
> Christoph Erdle wrote:
>
>> On 15.12.10 20:16, Christoph Erdle wrote:
>>> On 15.12.10 19:06, Helge Blischke wrote:
>>>> Christoph Erdle wrote:
>>>>
>>>>> Hi Helge,
>>>>>
>>>>> On 15.12.10 17:55, Helge Blischke wrote:
>>>>>> Christoph Erdle wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> we are trying to implement a differentiation between different
>>>>>>> types of
>>>>>>> postscript documents. Some of our printers (Ricoh MP C2800) need to
>>>>>>> be accessed with user codes, which can be included on the client side
>>>>>>> directly inside the postscript document which get's sent to CUPS.
>>>>>>> Those
>>>>>>> documents have to be sent directly to the printers without further
>>>>>>> filtering through foomatic. The routing part work's nicely with
>>>>>>> manually
>>>>>>> set cupsFilter lines in the PPDs.
>>>>>>>
>>>>>>> What's not working is the detection of those documents using the MIME
>>>>>>> autotype feature.
>>>>>>>
>>>>>>> I included the following type definition in /etc/cups/local.types:
>>>>>>>
>>>>>>> application/postscript-prefiltered priority(200) + \
>>>>>>> contains(0,4096,"setuserinfo") + \
>>>>>>> (ai eps ps string(0,%!)
>>>>>>> string(0,<04>%!) \
>>>>>>> contains(0,128,<1B>%-12345X) + \
>>>>>>> (contains(0,4096,"LANGUAGE=POSTSCRIPT")
>>>>>>> \
>>>>>>> contains(0,4096,"LANGUAGE =
>>>>>>> Postscript") \
>>>>>>> contains(0,4096,"LANGUAGE =
>>>>>>> PostScript") \
>>>>>>> contains(0,4096,"LANGUAGE =
>>>>>>> POSTSCRIPT") \
>>>>>>> (contains(0,4096,<0a>%!) + \
>>>>>>> !contains(0,4096,"ENTER LANGUAGE"))))
>>>>>>>
>>>>>>> Except for the first two lines this is the definition of postscript
>>>>>>> extracted from /usr/share/cups/mime/mime.type. Those files containing
>>>>>>> the string setuserinfo in the postscript header shall be typed as
>>>>>>> application/postscript-prefiltered.
>>>>>>>
>>>>>>> But this definition does not work as expected. Default postscript
>>>>>>> docs sent to the printer are typed correctly as
>>>>>>> application/postscript. But when sending a document containing the
>>>>>>> setuserinfo string, those also get typed as application/postscript
>>>>>>> and not as application/postscript-prefiltered, as I had expected.
>>>>>>>
>>>>>>> What am I doing wrong in my attempt to differentiate between the two
>>>>>>> types of postscript docs? Any advice is appreciated.
>>>>>>>
>>>>>>> The following is the beginning of a PS file send from a client
>>>>>>> machine with set user code (setuserinfo), which is not typed
>>>>>>> correctly.
>>>>>>>
>>>>>>> %!PS-Adobe-3.0
>>>>>>> %APL_DSC_Encoding: UTF8
>>>>>>> %APLProducer: (Version 10.6.5 (Build 10H574) Quartz PS Context)
>>>>>>> %%Title: (mime.types - what am I missing - cups.general - Forums -
>>>>>>> CUPS)
>>>>>>> %%Creator: (Safari: cgpdftops CUPS filter)
>>>>>>> %%CreationDate: (Wednesday, December 15 2010 16:26:30 CET)
>>>>>>> %%For: (Christoph Erdle)
>>>>>>> %%DocumentData: Clean7Bit
>>>>>>> %%LanguageLevel: 3
>>>>>>> %%PageOrder: Ascend
>>>>>>> %RBINumCopies: 1
>>>>>>> %%Pages: (atend)
>>>>>>> %%BoundingBox: (atend)
>>>>>>> %%EndComments
>>>>>>> userdict/dscInfo 5 dict dup begin
>>>>>>> /Title(mime.types - what am I missing - cups.general - Forums -
>>>>>>> CUPS)def
>>>>>>> /Creator(Safari: cgpdftops CUPS filter)def
>>>>>>> /CreationDate(Wednesday, December 15 2010 16:26:30 CET)def
>>>>>>> /For(Christoph Erdle)def
>>>>>>> /Pages 1 def
>>>>>>> end put
>>>>>>> mark
>>>>>>> () (731266) (201012151726) {setuserinfo} stopped
>>>>>>> cleartomark
>>>>>>> %%BeginProlog
>>>>>>> %%BeginFile: lw8_errorhandler-2.0
>>>>>>> /currentpacking where
>>>>>>> { pop /oldpack currentpacking def /setpacking where
>>>>>>> {
>>>>>>> pop false setpacking
>>>>>>> }if
>>>>>>> }if
>>>>>>> /$brkpage 64 dict def $brkpage begin
>>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Christoph Erdle
>>>>>>
>>>>>> First, note that the mime type definitions are lexically sorted by
>>>>>> cups at startup time, so application/postscript is checked before
>>>>>> application/postscript-prefiltered.
>>>>>
>>>>> ok, I tried to rename the mime type to
>>>>> application/000-postscript-prefiltered, so it should be evaluated
>>>>> before application/postscript.
>>>>>
>>>>> Still all PS docs (with AND without setuserinfo) get autotyped to
>>>>> application/postscript according to CUPS error_log (log level debug2).
>>>>> So the additional restriction of "contains(0,4096,"setuserinfo")"does
>>>>> not seem to be evaluated correctly.
>>>>>
>>>>>> Second, I strongly recommend to put your userinfo stuff into the
>>>>>> prolog section or the setup section to avoid this stuff being
>>>>>> eliminated by the
>>>>>> pstops filter.
>>>>>
>>>>> I have no influence on the positioning of this setting, this is
>>>>> inserted by the RICOH provided PS drivers for e.g. Mac OS X. Also the
>>>>> openprinting.org PPDs for Ricoh MP C2800 seem to behave that way.
>>>>> Exactly that's the reason why I'm trying to do this mime type
>>>>> differentiation on the central CUPS server.
>>>>>
>>>>> Kind regards,
>>>>> Christoph
>>>
>>> Sorry to bother you with such, maybe for you, obvious questions. Im
>>> still in the beginning of understanding CUPS and the various ways it can
>>> be adapted to our environment.
>>>
>>>> What about a prefilter (provided you are using a cups version 1.3.x or
>>>> above) for this printer? It could a simple Perl script moving the
>>>> userinfo
>>>> stuff to the beginning of, e.g. the prolog section and need only be
>>>> specified by a *cupsPreFilter statement in the printer's PPD.
>>>
>>> Thanks for pointing that out, that seems to be an additional option
>>> besides completely preventing the processing through pstops on the
>>> central CUPS server if it was already processed on the client.
>>>
>>>>
>>>> If you could provide a sample file, I could hack such a script (I've
>>>> done similar things for e.g. OOo 2.x and 3.x).
>>>
>>> Thanks for the offer :-) I'll try a solution I'm thinking of at the
>>> moment tomorrow.
>>>
>>> But just for curiosity: Do you have any clue why the mime type way I
>>> have been trying seems not to be working, especially the more restricted
>>> condition for application/postscript-filtered does not get triggered
>>> when determining the type of the document? Am I doing something
>>> substantially wrong? I thought by taking an additional condition (the
>>> usercode thing) and using an boolean "AND" ( "+" in the mime config)
>>> with the CUPS provided postscript definition should do the trick.
>>
>> sorry, the above should of course be
>> application/000-postscript-prefiltered
>>
>> Christoph
>
> Ah, I see your system is a Mac os X 10.6.x, so you use CUPS 1.4.x. With CUPS
> 1.4, the mime stuff is no longer stored in /etc/cups, but in
> /usr/share/cups/mime (I assume the Apple folks did not deviate from this
> convention). Move your local.types and local.convs (if any) to that
> directory and try again.

oh, sorry, I'm sending from my client machine. The central CUPS server 
is running on Ubuntu 10.04, CUPS 1.4.3-1ubuntu1.3, the clients printing 
to it are, amongst others, OS X, Solaris 9/10, OpenSolaris (via CUPS-BSD 
run with xinetd). I have the mime definition stored on the server in 
/etc/cups/local.types, and according to the man pages and also the debug 
log after restarting cups it looks for mime definitions (*.types) in 
/usr/share/cups/mime and /etc/cups.
log excerpt:
  [15/Dec/2010:18:45:35 +0100] Loaded MIME database from 
"/usr/share/cups/mime" and "/etc/cups": 38 types, 73 filters...

Also if commenting out the postscript definition in 
/usr/share/cups/mime/mime.types it matched in my first try when defining 
a copy of application/postscript in /etc/cups/local.types . So the 
locations should be working correctly, but the rule seems to have some 
sort of error I'm obviously not getting. I also tries to use it without 
the priority setting, still no change in behaviour: all jobs are mapped 
to application/postscript, even if it includes the string setuserinfo in 
the first 4096 bytes. The types are now named 
application/000-postscript-prefiltered and application/postscript, so 
lexical order should be correct for the way I'd like to have it working.

Christoph