MIME type matching not working as expected

Christoph Erdle erdle at in.tum.de
Thu Dec 16 02:09:38 PST 2010


On 15.12.10 21:52, Helge Blischke wrote:
> Christoph Erdle wrote:
>
>> 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
>
> OK then, besides your workaround, perhaps you should file a bug at
> www.cups.org.

Thanks for your help.

I found a working solution with mangling the MIME types instead of using 
a prefilter. The original attempt works as expected if i leave out the 
priority option. So for documentation purposes (if others struggle with 
such problems) here's my current definition:

application/000-prefiltered   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"))))

Kind regards,
Christoph




More information about the cups mailing list