[cups.development] XHTML Print format

[Kurt Pfeifle]

Jon Peatfield wrote:
> On Mon, 15 Oct 2007, Michael R Sweet wrote:
> 
>>> Not sure, but I think the answer is the texttops filter in the
>>> mime.convs file, right?
>>> /etc/cups/mime.convs file:
>>> "text/html               application/postscript  33      texttops"
>>
>> That's the basic mapping - if you did your own filter or added the
>> XHTML MIME type, just create vendor.types and vendor.convs files
>> that point to your new filter and use a lower cost so that your
>> filter is run instead of texttops.
> 
> I'd like to think that XHTML would have a different mime type but maybe
> not.

You can define a new mime type (alongside the rule to make auto-typing
the file to recognize it as such) in your to-be-created vendor.types file.

> Writing a simple wrapper round some external code so that it
> takes/processes the arguments that a CUPS filter gets isn't particularly
> hard.

Indeed. The hard part is to find the suitable "external code".  :-)

> We do this for text/plain with our filter calling a2ps for the actual
> conversion - in an effort to look more like our old (lpd-based) printing
> setup and so not to scare users when we switched to CUPS.
> 
> Apart from our text filter trying to do *very* evil things with duplex
> settings 

You don't need to do that.

If you set up the *.types and *.convs file correctly, your a2ps
will declare its output as application/postscript, and hence
the pstops filter will run next and take care of your duplexing
(and other) needs. (pstops consumes application/postscript and
spits out application/vnd.cups-postscript).

> the only place we had any problems is that the docs claimed
> that the printer name is passed in as argv[0]. 

You can ignore that in your filters. (AFAIU,  it's only the
*backends* that will have set the printer name as argv[0].)

> We don't get that but
> maybe it gets broken because our filter is a perl-script.  We do get
> passed PRINTER in the environment though so no loss there.
> 
> We also wrapper pstops to get it to doctor/clean the options received
> from some clients e.g. MacOSX, Windows and try to avoid some assumptions
> about paper-sizes - when doing page rotations.

Very unusual, this....

> Of course I'm still using CUPS-1.1.17 (from Redhat)

OMG.

CUPS really had releases with low version numbers like that?  :-)

> for this so maybe
> things are different in a more current release.

They surely are.

> 
>  -- Jon
> 

-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany