Sharing printers across a network is, on the face of it, pretty simple. This is particularly true when you're a single-platform organisation – so you have a bunch of Macs running through print queues that live on a Mac server, or you have a collection of Windows XP PCs talking through a Windows Server 2003 server's queuing system. As with most aspects of networking, homogeneous printing is straightforward because (a) it usually works; and (b) when it doesn't work, you get the book/PDF/Google out and look up the answer.

Most of your problems start when some helpful soul phones you up and says: "Hi, we've just bought a and we need it to be able to print". Multi-platform printing starts, in most organisations at any rate, with a large majority of one type of workstation and a tiny minority of another – and you usually have a legacy installation running the "majority" kit into which you have to shoe-horn the "minority" systems.

The first challenge is to find whether there's a driver for the new workstation that lets it understand the printer. This might be a vendor-supplied one, or in some cases (particularly if it's a Unix/Linux workstation) it'll be a third-party and/or Open Source one. In the latter case, there's every chance that you won't find one that matches the printer(s) absolutely – in which chance you'll have to go Googling for the answer. Nine times out of ten you find that owners of a Bloggs XYZ123 should have no problems with the XYZ321 driver, but it's an exercise you need to go through.

The options
The next challenge is making the workstation communicate with the printer. This is where the bulk of the hassle can come, because there are often several ways you could choose to go.

Imagine, for instance, that you have a fleet of Windows computers printing through queues a Windows server, and someone brings in a Mac to do print-publishing work on. You have three basic options:

  • Tell the Mac to use SMB (Windows) printing protocols to print to the Windows print queues.
  • Install an AppleTalk suite on the Windows server and tell it to present the queues to the Macs using AppleTalk.
  • See if the Mac can communicate directly across the LAN to the printer, without the need for queuing in the middle.

A similar set of options exists for most combinations of client workstation – you make the client understand the server, or you make the server understand the client, or you try to cut the server out completely.

How to decide
The first option is to decide whether the workstation can talk to the printer at all (e.g. whether there's any means of making the two parties talk to each other, and/or whether there's a driver). If you fall at this hurdle, give up on the networked printing idea and figure out a more onerous way (e.g. by FTPing files to another platform and printing from there).

Assuming that the two ends can communicate and understand each other, though, the next port of call for deciding what to do is to chuck out the options that will cost money (generally in the purchase of add-on compatibility software). Of course, if you don't find a suitable no-cost answer then you'll go back to considering paid-for options, but you have to start somewhere when whittling down your options.

Next, consider which options will require the least upheaval. For instance, if you're given the choice of installing an add-on to one server or installing an add-on to all your workstations, there's a lot to be said for the one-off installation in terms of staff time. Once you've decide some order of preference for the various options, do your research and see if anyone has had any hideous problems with your particular chosen setups: if so, you can either reassure yourself that there's a fix, or chuck the idea out because it may also not work for you.

Doing it
The final step, then, is to start at the top of the list of options and implement them. At each stage, make copious notes so that if you need to back out of the installation, you can – after all, just because it says it should work, this doesn't guarantee that it does. When you've installed it, test it, and if it doesn't work, do your best to debug it. If you can't make it work, back it out and try again. Nine times out of ten your preferred approach will work, but if it doesn't, and you can't fix it, go to the next one down the list.

For example, we recently fought with making some Windows PCs print to some HP LaserJet printers via SMB on an Apple Xserve running Mac OS X 10.3. Documents printed correctly, but no matter what we did, we always got an extra page with an error message on it, followed by another, blank page. We tried loads of fixes and Googled copiously, but to no avail, so we backed out and made the PCs use native LPR protocols to talk directly and 100 percent successfully - to the printers. It wasn't a perfect solution, as we had to fix the printers' IP addresses instead of letting them use DHCP, but it was the second simplest implementation and it worked correctly.

Write it down
The final step should, of course, be to document what you've done. One day you may have to add another new machine, and you may have had to follow some arcane configuration process to make the existing one work, so write up your notes and save yourself the effort next time.

And that's it. Enumerate the alternatives, compare their relative merits, then start at the top of the list and work down. Unless you have some particularly esoteric equipment, there will usually be an answer – albeit sometimes a very fiddly one – and only in a tiny minority of circumstances will you have to resign yourself to failure and tell the users: "Sorry, you'll just have to FTP it to that machine over there and print it by hand" …