[cups.development] XHTML Print format
k1pfeifle at gmx.net
Mon Oct 15 15:56:50 PDT 2007
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
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
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
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.
You can ignore that in your filters. (AFAIU, it's only the
*backends* that will have set the printer name as argv.)
> 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)
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
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH ..................... Hedelfinger Strasse 58
A RICOH Company ........................... D-70327 Stuttgart/Germany
More information about the cups-devel