Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!unido!gmdzi!strobl From: strobl@gmdzi.UUCP (Wolfgang Strobl) Newsgroups: comp.sys.mac.misc Subject: Re: Windows/Mac flame war fuel Message-ID: <3054@gmdzi.UUCP> Date: 6 Jul 90 23:44:03 GMT References: <8974@goofy.Apple.COM> <2988@gmdzi.UUCP> <42650@apple.Apple.COM> <3042@gmdzi.UUCP> <42681@apple.Apple.COM> Organization: GMD, Sankt Augustin, F. R. Germany Lines: 154 daveo@Apple.COM (David M. O'Rourke) writes: >strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >>What do you call a specific printer, here? Even one and the same >>printer can have different capabilities at different times, >>for example if you install a tractor feeder on a needle printer or >>remove a font cartridge on an ink jet printer. > A tractor feed being installed/not-installed is unimportant. Most of No. It may result in a different paper size or require a different handling on the user's side. >of the print driver's are written for a Specific printer, or query the >printer as to it's font list. But you are thinking DOS only. Most of >the ink jet printers for the mac, including the Deskwriter, store the font's >on the Macintosh and not the printer. In addition the Macintosh rarely >sends just the character to the printer. Rather it typically sends a bitmap >to the printer that happens to look like text. So the only relivant info >for a particular printer type is it's maximum resolution, dpi. And then >the Macintosh creates a bit map at the resolution and sends the graphics to >the printer. Is this true for Postscript printers, too? What a a shame. ;-) I think we have a different philosophy here. On the Macintosh one prints to an abstract graphical output device, and the printers have to fit that model. This is nice, clean and expensive. Windows on the other hand tries to make all the capabilities available the printer out there have. Many of the supported printers where built or designed with CP/M or DOS or something similar in mind. This does not make them useless. Many of these printers can a) mix graphics data and character data and b) put a character string composed of the printer's hardware font on an arbitrary pixel position on the page. All what's needed is a system which can report metrics information back to the application program to ensure proper positoning and sizing of the different parts of the whole picture. >>Most PC clones offer both serial and parallel interfaces. Both can >>be used to connect a printer to it. People prefer to use the >>parallel port, because it is cheaper and simpler to use, as I explained >>in a separate message. Serial links are symmetric, parallel links aren't. > I'm not saying PC's don't have serial ports. What I said it the Serial >port is the prefered Mac connection, and given a serial port you have a lot >more capability for interaction with the printer. Since the serial port >is standard on the Macintosh the printer drivers can make assumptions about >what sort of info will be availible at run time that you can't always make >about a print driver for a DOS machine. Yes, this is an advantage, as most restrictions to a particular interface are. What about printing to a file or to a remote server. How do you query the printer in this case? >>What do you mean by "even with Windows, the PC DOS is still primarily a >>character based OS"? Is it a statement about Windows (then it is plain >>wrong), or is it a statement about PCDOS (then it's true, but not very >>meaningfull). > Windows is build on top of DOS, dos is a character based OS. It has no >standard graphic routines, and no standard graphics model. NOTE: A graphics >model goes beyond simple color specification and point ploting, it includes >standard font handleling, a graphics plane for ploting in, and OS supported >graphics functions for ovals, squares, shading and so forth. The PC is >a text based OS because in has no *standard* graphics model that cover's even >half of what QuickDraw is capabile of. And since MS Windows is based on DOS >there are still left-overs of a character based model in the printing and >screen handling routines that you won't get away from until you choose a new >OS for your base. In addition there has to be a standard way for handleing >non-raster based graphics and so-forth... Excuse me, but the logic in your first two sentences is not very conclusive. Windows is built on top of DOS and uses it's file system, only. DOS is a character based OS. What graphic routines it may or may not have doesn't matter - Windows does not use or emulate them, anyway. Windows version 3 can emulate some display hardware, which DOS applications expect to have access to, because there is not even a usable character based DOS support for it. There seem to exist PC emulators on the Mac. Would you blame the Mac to be a character based machine because of that? The graphics model of Window includes standard font handling, a graphics device context for ploting in, and there are OS supported graphics functions for ovals, squares, shading an so forth. There is even a SetPixel function in the OS, which is not used very often, because it does not fit well into the graphics model. The screen handling of Windows has nothing to do with DOS - it does not even use the BIOS-ROM. > The statement is only meaningless to people who can't think beyond their >favorite machine, and QuickDraw while it is good, doesn't meet a lot of the >criteria for a complete graphics model, but it does a better job than MS >Windows or DOS. I haven't said that it is meaningless to me, I have said that a statement about the character restrictions of DOS is meaningless in a discussion about the capabilities of Windows. I stay to my statement. I am sure that QuickDraw does a better job than Windows or DOS. Are you sure that it does a better job than MS Window *and* DOS? >>Anyway. The problem Windows has (and the Mac OS has not) is that it >>has to support a much broader range of printers, from the cheap >>9-needle-printer to the big Postscript RIP. In my opinion this support >>is an advantage. > It may be an advantage, but that means that all software to be fully >compatible has to be designed to a lower common demoninater than on the Mac. >The Macintosh requires a high capability printer than a DOS machine. This >isn't a bad thing. It means that Macintosh Software can assume a highly >level of functionallity in their output devices, and people won't accept >a lower quality standard. The Macintosh can support just as many printers >as the PC, if all of those printers where up to a Macintosh standard, but most >of the cheap PC printers will not do an adequite job of printing compared to >other Macintosh printers, and therefore can't compete. Sometimes on has to trade functionality for quality. >>Just one more question. How do you print into a file, if the >>printer is not physically available? It cannot be queried in this case. >>Don't tell me that the printer driver just stores the abstract >>graphics operations into a file instead of sending it to the printer. >>How can it know the specifics of the printer, if it is not available, >>and if there is no configuration at all? > You don't. The Macintosh print arch. requires the printer to be able to >communicate back to the computer. Not a limitation, it's a requirement that >allows the Mac to enjoy a higher level of basic printer functionality than >an equivilant DOS machine. If you want a spooler or print server your software >must behave like the printer it's emulating, there is no batch dump mode >where the Mac just assumes the printer is there and doesn't pay any attention. Rule 1: The architecture requires the printer to be able to communicate back to the computer. Rule 2: If this isn't the case, see Rule 1. I see a problem here. If all servers and print spoolers have to be able to emulate all the supported printers, you lose all the advantages of the dynamic binding of printer capabilities and get a maintenance problem. >>installing a different printer driver and telling it a few things >>about the new printer, once. As long as the printers have similar > Why should I have to tell it anything about the printer. That's the drivers >job, not the users. Partially. I agree, as long as there is a communication path, and the user does not care. But sometimes there is no path, or the user cares. Wolfgang Strobl #include