Op 16-jun-05, om 09:19 heeft Rose Humphrey het volgende geschreven:

On Jeu 16 juin 2005 1:56, stephane richard a écrit :

Kinda french?  Quebec?  Go ahead and go to France and ask them that

They talk kinda quaint and have a weird accent, but they speak French.
One up on the usual attitude betweens Brits and Yanks (we're talking the
unwashed masses here). Also they make good beer, which is more than the
French and Americans can do. Belgians present can take that smug look off
their faces and I'll have a Leffe, une fois.

Err, We don't have a smug look at all, and yes, our beers are the best in the world :D


Anyway, to get back to computer CUPS (rather than a foaming glass of
brew), a bit of research last night convinced me that CUPS, gimp print
and/or Foomatic are all of great interest, but the best system for
printing that also provides many drivers not available - or easily
identifiable - elsewhere is Turboprint.

I'm not so sure about Turboprint being the best thing, when it comes to flexibility, did you check out http://www.linuxprinting.org ? There is more then just gimp print & foomatic, there's also hpijs and several other additional drivers that work with the cups framework, not to mention ghostscript.

I also came across a fairly detailed explanation by a professional
printer driver writer explaining the problems in writing drivers other
than for Windows: basically, a lot of the processing is done by the OS
rather than the printer, as this makes for faster printing and cheaper
printers. However, this also means that the printer driver as supplied by
the manufacturer has to rely on API "hooks" in Windows.

The same applies to eg turboprint drivers (they rely on the turboprint API) and printing in general on the Amiga, you can find out more about the standard AOS api's in the "devices" part of the includes & autodocs

What was not adressed, as one person pointed out in comments, was the
existence of a similar system to the Windows API in CUPS. However, it
does seem as though the difficulty in getting drivers for anything other
than Windows is partly due to the difficulty of writing printer drivers,
ignorance of the existence/usage of tools equivalent to the Windows API
in other systems (MacOSX Darwin, anybody?), and an understandable refusal
to release technical information which comes under company IP. Even the
Microsoft service that exists only to ensure that printers work with
Windows doesn't get that information.

Actually, most drivers use a specific language (postscript, brscript (brother's variant) esc/2, PCL.... these are reasonable well documented, what usually is the hard part are the extras some printers have, like the HP PSC's with their combined scanner & fax ability.

While I'm still all for CUPS, this does give food for thought.

CUPS has the advantage of being maintained on multiple platforms, bringing in more developers that can write drivers, HP for instance, actively works on it's Open Source drivers for CUPS.

Turboprint is offcourse also intresting, and i don't see why CUPS would exclude Turboprint & vice versa.

One could write a postscript device that does nothing but pass the ps data to CUPS for proccessing/printing, making it work transparently with just about every application capable of using postscript drivers, the same goes for the standard printer.device, instead of having it rasterize to a driver & outputting to the printer directly, you could have it rasterize to a TIFF or simular file & let CUPS handle printing it.



Ochal Christophe

Webmaster for: