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 question ;-).
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
<snip>
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.
---- Amon_Re Ochal Christophe Webmaster for: http://www.kefren.be http://www.metalfest.be http://amigadev.amigaworld.net