On Tue, 25 Aug 1998, you wrote:
>This may suprise you, but Windows printer drivers are basically just
>that - filters. The vast majority of Windows programs don't know
>anything about specific printers, but instead `print' in a standard
>format for Windows programs. Windows then takes this output, and runs
>it through the appropriate `driver/filter', and then the output of
>this is ultimately sent to the printer.
Of course. However, since the "filter" is made by the people who
designed the printer, it's invariably going to be much better than a
generic printer filter.
>Unix has no such standard printing format so each program that prints
>needs to know how to talk to each printer. Postscript is the defacto
>standard, of course. Of course, your printing setup can have various
>filters set up to print certain things correctly (for example, it can
>send postscript directly to your printer, text is converted to
>postscript and printed, dvi is converted to postscript and printed,
>etc.) but the support for non postscript printers is definately
>lacking. You can hack in ghostscript to convert postscript to your
>printer's native format, but this isn't likely to work as well as
>Window's setup.
You're basically splitting hairs over semantics here. What you
describe in the above paragraph is the result of having a specific
printer driver in windows but not one in unix.
>As for trying to print to an HP from Windows without a driver, there's
>no reason why you couldn't run a postscript file through ghostscript
>and push the output into lpt1: ... no Windows driver loaded (besides
>the one for the parallel port, of course), yet it would print ...
>Also, you can print straight text (as long as lines are terminated
>with ^J's and ^M's) directly to an HP printer ... again, no Windows
>drivers involved.
Sure it would print. And it would look like rubbish just like it does
in Unix if not worse.
Note that printing the way you are describing is NOT the correct way to
do something in a multitasking environment. Just put the thing in the
queue and let the driver handle it -- unless you want the system to hang
if anything else that's running looks at the lpt port. Thus any point
you are trying to make here is purely academic, unless you run DOS.
>>The print quality is very much dependent upon having a specific
>>driver
for the printer or not.
>
>That is basically what I said.
No it isn't. You're trying to discount what I'm saying about having a
specific driver. Maybe you're just not sure what you're saying....
>If the authors of Netscape wanted to make a deskjet output format and
>did it right, it could give you the same print quality that you've
>gotten used to from Windows. The same goes for any Unix application
>... the problem is that it needs to be done for each application.
It's not really netscape's job to do that. In a multitasking
environment, the daemon that handles printer control needs to do this.
This is why it works so much better in windows when the daemon (driver)
is written for that printer specifically.
Sure, you can have anything that accesses the printer do so directly.
Then we'd be back to where we were in the 1980's and had programs like
wordperfect bundled with hundreds of different printer drivers. Also
note that allowing this kind of hardware access would invariably break a
multitasking OS.
Of course if you have to print from unix or linux and it has to look
perfect, there are better choices than those inexpensive HP deskjets.
Some printers will work marvellously with the unix filters, the
higher-end deskjets even will too. Some printers though really do
need a bit of help on the software side -- and sometimes unfortunately
this help only comes from their windows driver.
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
