![[+-]](/images/plus.gif)
Welcome![[+-]](/images/minus.gif)
Printing & Plotting
Color Printing: Why So Complex?
To use laser printers and plotters you need to have the correct printer drivers and PPDs installed on your computer. To use the color printers, you must understand the GSD's queuing and spooling system. In order to better support our users, the GSD Computer Resources Group (CRG) has assembled a set of drivers and postscript printer descriptions that work. We have found, over the years, that when users understand the fundamentals of how printing works, they are better able to overcome minor obstacles than when they are simply told what buttons to push. Please read the description of the architecture of printing on this page before you begin installing drivers and before you begin using the GSD printing system -- you'll find this overview very helpful.
About Printing at the GSD
How Printing Works at the GSD
In the beginning, there was a software program, and a printer. When the user selected 'Print' from the File menu of the program, the program knew how to communicate with the printer, and it would send the appropriate commands, and the printer would print.
At first, applications spoke directly to printers
Now, there are thousands of different programs, and lots of different sorts of printers. There is no cruel overlord that requires all printers to use the same printing language so various worthy languages have evolved. Faced with this problem, smart software architects decided that instead of requiring that every software program produce every sort of printer language, there should be separate little helper programs called printer drivers to translate from generic software commands to specific printer languages. So now when a user selects "Print" from the File menu, and selects an appropriate printer driver, the application then speaks to the driver, and the driver sends the appropriate commands to the printer. The most popular printer command language today is Adobe PostScript. All of our GSD printers speak PostScript except for the large format Hewlett Packard Plotters which speak Hewlett Packard Raster Transfer Language (RTL). This architecture works very well, provided people understand about drivers.
Now, printer drivers translate between applications and different
printer languages.
But then, printers started to sprout various exciting features: some take large sheets, some print in color, some don't, etcetera. The people who designed Adobe PostScript said: "Users are going to get confused with all of these options! We need a way to customize the PostScript driver's print dialog according to the features of a particular printer." So they invented PostScript Printer Descriptions (PPDs). Now when the user selects "Print" from the File menu, and selects the driver for a particular printer, the driver gets information about printer features from the appropriate PPD, and the user can adjust the Printer Properties dialog to choose among the paper trays, color options and paper sizes for that specific printer.
PostScript Printer Descriptions (PPDs) inform the PostScript driver
of printer-specific features
Then networks came into the picture, and many users wanted to share printers. Sometimes two people would try to print to the same printer at the same time, and one print would not come out. This unpredictable behavior made users very unhappy. So once again the engineers came and said, we will make new programs called spoolers. Users will send their jobs to the spooler which will save the individual jobs as files of print commands, and send one job to the printer at a time. This is the state of modern printing today and the way that the laser printers at the GSD work.
Spoolers handle multiple jobs, sending one at a time to shared printers.
The Special GSD Spooling System for Color Printers
...This story picks up from where the story of printer drivers (above) leaves off...
Then the network grew to hundreds of students, and there were a few very special printers. And some of these students would want to print lots of things and some would want to use special paper and some would wait to the last minute before their reviews and need to print right away! For this sort of environment, the ordinary automated print spooler was not adequate. The biggest problem with the spooler is that the users can't predict or control whose print job is going to come out next. Therefore, one never knows when to put in one's special media, and one user who has 50 posters to print for a movie next week may tie up the color printer while another user needing to print out a rendering for a review that started 5 minutes ago waited --not a pretty picture, under the spooler system there is no way for these users to control the queue!
So, Wade Hokoda, a very smart employee of the Computer Resources Group, designed a simple and elegant spooling system where users control whose job would come out next so one that accomodations for a user to predict and place special media in one plotter, and users to negotiate who should go first on the other plotter could be managed.
Users send print files to plottmp and control the print queue while
standing next to the printer.
The system is very similar to the spooling print system described above, the only difference is that the color printers are not connected directly to the spooler. Users choose the appropriate drivers and PPDs (where applicable) in their print dialog but instead of targeting a specific spooler for a printer, the user requests that the driver send the printer commands to a File on their local hard disk. When the file is finished, the user puts it onto a network drive called "plottmp." Then walks up to any of the color printers' corresponding plot server stations (usually situated adjacent to the color printer itself - with the name of the color printer or plotter that it serves on its screen), the user then types "plot" on the plotserver, and chooses files placed earlier in plottmp directory that are needing to be printed or plotted. By the way, the user would know to not use punctuation, nor spaces in the filename, and would know to select filenames that wouldn't exceed 8 characters in length.)
Critical Review of the Legend of How and Why
Printing Works
by Paul Cote, MCP
As with most popular legends, the story of the GSD printing system contains many metaphorical truths which are useful in day-to-day situations. The legend, in its transfer from generation to generation serves to wipe out superstitions and fears which are harmful and unproductive. In this respect, several aspects of the story bear further examination:
Truth #1: The most common reason for failed print jobs comes in the interface between applications, drivers and ppds.
This very dangerous terrain is dominated by the sinister spectre of document information having been set within the application being in conflict with information that is set in the driver setup. Here is a list of common application/driver conflicts that result in unpredictable printing behavior:
Common conflicts between application and driver print settings:
Application Settings (page setup, etc.) Printer Driver Settings (in printer properties dialog) Document Page Size Printer Page Size Document Orientation Landscape / Portrait AutoCAD pen settings (set in ACAD print dialog or with HPConfig Printer Monochrome/Color settings
At an even more grotesque and yet common level, applications such as pagemaker and quark will ask you to select a PPD in addition to selecting a printer. (actually, where they say 'printer' they mean 'spooler') The default PPD offered is usually completely inappropriate (except in the case of letter-sized, artwork in black and white.) If the user fails to change the PPD, Quark and Pagemaker will happily make a black and white print of a letter-sized portion of the document.
Therefore Pagemaker and Quark users MUST understand what PPDs are, and read the print dialogs carefully, in order to select the correct PPD in the place where Quark or Pagemaker expects to find it (this location can be found using the system's "Find" command.)
All of this odd behavior in Quark and Pagemaker stems from the fact that these programs use their own postscript drivers, therefore, all of the icon, button and menu knowledge you've learned using standard printer drivers is useless in these programs. But now that you have been initiated in the esoteric understanding of printing architecture, your deeper understanding will permit you to transcend these superficial earthly tribulations.
Truth #2: The user-controlled spooling system (print to file, copy to plottmp, and send from plotstation) is not to blame for most unsatisfactory prints.
In fact, this system is no different from network spooling systems used in most other environments. In each case, print commands are saved to a file -- either by the spooler or by the user -- in either case, the print commands created by the interaction between your application and your driver (perhaps modified by the PPD that you chose) are sent to the printer. If you set the job up correctly, it will print correctly. If not, well....
Truth #3: Though lots of people have been working on solutions, printing is still a very frustrating area of computer use. The only successful approach to printing is to EXPECT PROBLEMS, start early, and allow plenty of time for printing. Learn to print early, and each time you begin creating documents in a new application, begin with modest, fast and inexpensive printing experiments before you invest lots of time in production.
The reason for this is that printing depends on interactions between different programs (applications and drivers) AND between different sorts of hardware (printers, some of which are desired especially because of exotic features.) All of these interactive elements are designed by different people with different objectives, and there is really nothing except humanity's inherent desire to cooperate that makes it work.