[ Previous Article | Next Article | Index of Articles]
This article first appeared in the May 2000 issue of the Louisville Computer News. It was written by Lee Larson.
Readers of this column send me a lot of interesting e-mail, usually with a question attached. Most of the questions are easy to answer, such as "Can I run Mac OS 9 on my old Power Computing clone?" (Yes, if you have enough RAM.), or, "Are the new G4 chips really as fast as Apple says?" (Most of the time.). Some don't need answering--"Macs suck! Why don't you use Windows?" (Sometimes I must, but I don't enjoy it.) The best ones are the hard ones, because I learn a lot in digging out the answers, and that often resupplies my rapidly dwindling storehouse of ideas about which to write.
This month, several challenging questions appeared.
The first question is "We have an HP laser printer set up for TCP/IP printing, but the Mac doesn't work with it. Can I print to it?"
One of the deepest and darkest secrets in recent releases of the Mac OS seems to be the Desktop Printer Utility. On my installation of Mac OS 9, it's buried three folders deep in the Apple Extras folder the Installer put on my boot drive. The Desktop Printer Utility allows you to create desktop printers for some types of PostScript printers that don't appear in the Chooser, such as USB laser printers and TCP/IP network printers.
In the dialog for the Desktop Printer Utility, the TCP/IP printers are called LPR printers. That's because lpr is a standard name under Unix for the command to print to printer queue.
To add an IP-based network printer to your desktop, all you need to know is the IP number of the printer. It's also a good idea to get a printer description file for the printer, so you can take advantage of any special features, such as extra paper trays. Nearly every day, I use IP-based printing from a Mac to a LaserWriter 8500, and big jobs print noticably faster than regular Appletalk printing on the same printer.
But, it seems there's a reason Apple hides IP-based printing deep down in the basement of the Mac OS installation. With many Unix-type print queues, and some IP-based printers, it fails to work at first, and it can be a real adventure to get it working.
The real question often turns out to be whether or not the print queue you're talking to can support binary data. Many can't, but the default for the LaserWriter printer driver is to send it anyway. The easiest solution to this problem is to get a PPD file for your printer that tells the driver to translate binary data to ASCII. But, such PPD files aren't always available.
I first ran into this problem when I was trying to print to an Epson Stylus inkjet printer connected to the parallel port of my Linux box. Printing from Linux to the Epson was piped through GhostScript, a free PostScript clone, so the inkjet appeared to programs on the Linux machine as though it was a color PostScript printer. It worked great from Linux!
I set up an IP print queue, and more often than not, print jobs from the Mac just disappeared into the mysterious bowels of Linux. After a lot of fussing and digging on the Internet, I finally learned that the printing daemon (lpd) on my Linux machine didn't like binary data from the Mac. My solution was to switch printing systems on the Linux machine to a new system called lprng. (ng=new generation, as every Star Trek fan probably guessed.) My Mac now thinks the Epson Stylus inkjet is a color PostScript laser printer, and it sort of works some of the time. (The rest of the problems seem to come from GhostScript.)
The same problem also shows up all the time with people setting up IP print queues on Windows NT. The Microsoft Knowledge Base article Q158903 concerns this problem (support.microsoft.com/support/kb/), and recommends that text (ASCII) encoding be used when printing to NT queues. It's not clear whether this has been corrected in Windows 2000.
The problem has been resurfacing over the past few months on Internet Mac support sites, because it's been an issue with USB-connected PostScript printers and some newer HP printers with Jet Direct network cards set up for IP and not Appletalk printing. Neither can support binary data. (The Jet Direct cards do support binary data over Appletalk.)
There's no good excuse for the HP's not to support binary data, but it is understandable with the USB printers. The USB connection is just a high speed serial connection, and, like all serial connections, it uses certain control characters to tell devices to do things like stop and go. Binary data might contain these same characters as part of the PostScript file, and this confuses the printer--not to mention the poor keyboard and mouse, which are also living on the same USB.
For the intrepid, who are not afraid, or foolish enough, to use ResEdit, there's an undocumented and unsupported way to fix the problem. The LaserWriter 8 printer driver can actually be configured to encode binary PostScript as good old ASCII.
Using ResEdit, open the PRFS -8192 resource of the LaserWriter driver. You'll see a list of default behaviors for the driver that can be turned on or off. Near the top is the option "Never send binary data." Turn it off, and the LaserWriter driver will start encoding all binary PostScript in ASCII format.
Be sure to do this only with a copy of the LaserWriter driver. It's probably a good idea to rename the one on which you did surgery to something like "LaserWriter (hacked)" so you can tell them apart. I've had no trouble keeping both in the Extensions folder They show up in the Chooser with different names, but it's possible some programs might be confused with both of them there, so beware!
The second question was the following. "I work as a network administrator for a company whose policy is not to support Macs. The problem is our graphic designer uses a Mac and has to transfer files across the pond to the designers using Macs at our U.S. head office. I have learned the basics and have set up SFM on a file server locally for print, file transfer and backup purposes but I can't get her Mac to see another server across the WAN (FR 128k) that has SFM installed. When I try to add this server in the control panel using the IP adddress it seems to time out and comes back with Server not found. Is this because of a slow connection, or am I missing something?"
This is the good old AppleShare versus AppleShare/IP mixup. All newer Macs can support AFP file sharing using both the older AppleTalk, or via TCP/IP. Windows NT Services for Macintosh (SFM) only supports file sharing through the older classic AppleTalk.
Since your company's short-sighted policy is "not to support Macs," I suspect classic AppleTalk packets are not being routed between the two sections of your WAN. This means the machines can't talk to each other. If your NT machine could speak AFP over TCP/IP, then you'd be able to communicate.
There are a couple of solutions.
Windows NT can be retrofitted with AFP over TCP/IP. At least two products add AFP/IP services to NT, including MacServerIP from Team ASA, Inc. and ExtremeZ-IP from Intergraph Computer Systems. Both replace the standard NT Services for Macintosh.
Windows 2000 FSM does support AFP over TCP/IP.
Even when you have the option of using either classic AppleTalk or TCP/IP, there's usually an advantage to using TCP/IP. Classic AppleTalk was designed to transfer files over the original slow AppleTalk wiring, and was limited to a speed of 230 kb/s. This is lethargic by today's standards, where the slowest networks are 40 times as fast. The packet sizes were kept small, probably to avoid collisions on the slow network, and perhaps because the original hardware would be challenged by more throughput. Every packet adds a little bit of overhead, so large files--requiring many packets--suffer.
AFP/IP, on the other hand, can use larger packet sizes, so it's more efficient with large files. It's also based on TCP/IP--the language of the Internet. An AFP/IP server on the Internet can be used from anywhere in the world. Since Mac OS 9 does AFP/IP file serving, I regularly use it to drag home those files I've forgotten in my office.
At the May 23 meeting of the LCS, Harry Jacobson-Beyer will demonstrate the Mac OS. Members and guests will be asked to participate and demonstrate to the group hints and tips they use with the OS. Attendees will be able to ask questions about the operating system. In addition there will be a members-helping-members session, at which Mac questions can be asked.
The Louisville Computer Society meets from 7:00-9:00 P.M. at Pitt Academy, 4605 Poplar Level Road, at the intersection of Poplar Level Road and Gilmore Lane. Everyone is welcome to attend. For more information, on the web go to www.aye.net/~lcs, or e-mail lcs@aye.net.
[ Previous Article | Next Article | Index of Articles]
/home2/lee/www/cgi-bin/textcounterdata/ [TextCounter Fatal Error: Could Not Write to File __lee_macwritings_LCN0005_shtml]