MIME type matching not working as expected

Helge Blischke h.blischke at acm.org
Wed Dec 15 12:52:26 PST 2010


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.

Helge





More information about the cups mailing list