There are lots of solutions:
- JetDirect - print server listens on a TCP socket, clients treat the socket the way they would a serial port with the same printer model attached. No job management or anything, but very simple to implement.
- AppleTalk PAP - printer requests data from client as it needs it, client polls printer for status. Printer status and job management are done in a standardised way for all printers. But it depends on obsolete protocols.
- lpr/lpd - the UNIX equivalent to AppleTalk PAP. Runs over TCP/IP, provides standardised printer status and job management, easy to proxy/multiplex, supported out-of-the-box on most modern operating systems.
- Windows Printing - kind of like AppleTalk PAP but using NetBIOS instead of AppleTalk. All the printer status and job management functionality, but a bit cumbersome to use. Works well on OSX and Windows clients.
- IPP - a "modern" HTTP-based printing protocol. Should do anything the other solutions can do, but better. Used by CUPS, and supported on Windows since Win2k. Also used by iOS for printing.
As for standardised printer control languages, there's HP PCL (printer can be relatively dumb), HP-GL (vector protocol really intended for plotters), SPL (Samsung's equivalent to HP PCL), PostScript (requires fairly heavy runtime to render), and PDF (declarative page description language). A print server should be able to handle at least one of them.
The way it used to work was there were "workgroup printers" with a built-in NIC and print server. They'd usually be able to interpret PCL or PostScript so anyone could print to them with a driver for one of these languages. But they were expensive.
So you could connect a printer to a computer and get the computer to act as the print server and share it on the network. If you had a driver for the printer on this computer, you could make it translate PCL or PostScript to the printer's (probably proprietary) native language so clients still wouldn't need a special driver, only the print server would.
But using a computer as a print server looks overly complex, so you got dumb print server boxes. You can't install fancy print drivers on these boxes, so they just proxy a TCP port to the serial/parallel port the printer is connected to (JetDirect). Each client needs drivers for the specific printer(s), and it prints as though it had the printer attached locally to a serial port.
NetUSB is the next step in this devolutionary chain. It's like the dumb print server adapted to USB rather than serial/parallel. The client machines have a driver for the specific printer(s) and the USB I/O is redirected over the network.