Computer Laboratory


The Computer Lab has a number of public printers of different types. Most are colour laser printers, but we also have several B&W laser printers. We have an HP DesignJet colour A0 plotter (gum), and two combination colour printer/scanner/copiers (mulberry and holly). Some of the printers have stapler attachments. Some can print on A3. We also have a laminator capable of laminating posters up to A0 size.

All printing on lab-owned printers is free of charge.

All problems with T&R printers should be reported to the mailing list [Javascript required] – this includes toner out, paper jams, strange error messages and stuck queues.

Connecting to printers

How you connect to printers depends on which OS you are using, and how your computer is connected to the lab network. Whatever your OS, the print server is available from the wired network that we use for personal computers, and also the internal wireless network, Internal-CL, and from eduroam. It is not available from the wgb wireless network.

from Unix machines

This should be straightforward - you do not have to pre-load printers, they should all be available for use whether you have a wired or wireless connection.

Make sure you have a file called /etc/cups/client.conf it should contain the line


(If you have to change the contents of the file you will then need to restart cups, most likely using the command cl-asuser service cups restart). This should be all that is necessary to make the printers available - the only problem then is figuring out which one you wish to use.

On lab maintained Unix machines running CUPS there is a script installed to help with the rather confusing CUPS printing options. It will either be installed as "lpr" or as "". As an example of the difference, to print a file on the printer palm with staples using the script: -Ppalm -staple filename

Without it:

lpr -Ppalm -o Option17=DF73 -o OutputBin=Main -o KMStapleMode=Rear1 filename

from machines running Windows 7 or 8

There are three methods of preloading printers available for Windows machines:

from Macs

There are two methods of preloading printers available for Macs:

List of printers and their locations

Miscellaneous points

  • It is also possible to send documents to the CL printroom for the Docutech Printer.
  • The plotter gum can be used to produce colour posters from A3 up to size A0.
  • The printers sycamore, mulberry and holly can print A3 in colour (as well as A4)
  • Most of the LaserJets print double-sided by default, under Unix use the -single option to lpr to print single sided.
  • The printers palm, willow and poplar have an extra-large paper-tray and are thus recommended for larger jobs. They also have stapler attachments.
  • You cannot print Windows-specific formats (eg .doc, .ppt) directly from the Unix command line, print from a utility (eg soffice) instead.
  • Most of the colour LaserJets are capable of printing on transparencies, although they will not have transparencies loaded nowadays.
  • We do not stock or support letter sized paper

Printing posters

Currently access to gum, our poster printer, is restricted due to the cost of consumables (we don't want people accidentally printing code listings on A0 paper !) and because it requires some simple operational skills. If you wish to produce a poster then please email [Javascript required] with details of the size of poster required. You should send us a URL we can use to upload the poster rather than including it in the email. If you are likely to want to print posters frequently and/or have proven that you know how to load paper then you can be added to the access control list for the printer.

Further details on the use of this printer and the laminator are at gum.

Business cards

The lab does not support individual printing of business cards. We do not keep card stock in Stores. Only one or two of our printers have a straight enough print path to cope with the thickness.

CS print room will do business cards.

Reception are able to order them for staff, so might also be able to offer advice.

Common printing problems

Hardware problems with the printers should be reported to [Javascript required]. If you have any document problems which are not addressed by the cases below then please contact [Javascript required]

Why does my file not print?

A number of possibilities:

  • The most common reason is that you've (inadvertently perhaps) sent it to the wrong printer. This can be easy done in many utilities as it is quite common to select the wrong printer from the pull down menu. Under Linux it is usually due to having your PRINTER environment variable set in the wrong place. Most people set it in the file .profile as that has always been the place Unix/Linux users have been advised to set it. Unfortunately many popular window managers nowadays (such as kde or gnome) start up before reading the .profile file. Consequently anything started by your window manager (for example as a menu item) doesn't know about the value you have assigned to PRINTER. It will consequently attempt to use the lab default printer, which is called aaa-dustbin. aaa-dustbin isn't a real printer, just a printer queue, and so anything sent to aaa-dustbin stays in the queue until it is deleted or redirected. The correct place to set the PRINTER environment variable is in a file called .xprofile in your home directory, as this will be read before your window manager starts up. Don't forget that you will also need an export PRINTER line for the PRINTER assignment to take effect.
  • The file isn't what you think it is. Commonly, you have a file which you think is PostScript but which contains some information at the beginning of the file which means that it is technically not a PostScript file. This is commonly the case with "PostScript" generated by utilities on Windows machines – they put PJL code before the start of the file, or in some cases a large number of null characters. It is also possible that PostScript sent via email may have extra characters prepended by the mail process. These characters may or may not show up if you use more (or less or cat) to view the file – the only sure way to see them is to use an editor such as emacs. A PostScript file should start with the characters %! on the first line. Anything else may cause the file not to be recognised as PostScript, which may result in gobbledegook, or may result in the file being rejected. Ghostview is much more forgiving of such problems that the printer system, so it may preview the file quite happily.
  • The file isn't supposed to print. For example, the file is a PostScript file which does not contain a showpage operator (or copypage, or something else which is defined to be equivalent). This usually means that it is a single page that was intended to be included in some other document (ie it's EPS, not PS). Ghostview (or rather the underlying ghostscript) renders pages as it goes along and therefore doesn't care whether there is a terminating showpage operator or not. Printers, on the other hand, render the PostScript to a virtual page, which is then printed onto paper only when a showpage operator is seen. Thus, without showpage, the printer happily renders the page in memory and then throws it away because it hasn't been told to print it.
  • The file is corrupt. If the file doesn't print and cannot be previewed (eg by ghostview if it is a PostScript file) then the likely cause is that the file has been corrupted. If it has been received via email then it is possible that one of the Mail Agents along the way has altered the file in some way, for example by breaking long lines in inappropriate places. Previewers like ghostview or ghostscript will fail part way through the file with incomprehensible errors. In the case of the line breaking problem described it is relatively simple to edit the file to join the lines back together – the problem is in determining that this is the problem, and where the splits have been made. The error messages will be some help, for example if they say something like
    Error: /undefined in glleft
    then you can search the file for the text string "glleft", and you may notice that the string literal "guilsinglleft" has been split in the middle, and the second half is on a new line which results in it being treated as an unidentified operator. Ask for assistance if you do not wish to attempt this detective work yourself.

PDF files (or Evince considered harmful)

Most PDF files will print quite happily from both Windows or Linux. However, some which display correctly will fail to print, or will produce printout with some fonts replaced by black areas. You can usually (but not always) get around the problem by printing the file in a different way. In general, the Linux utilities which have the most success in printing PDF files are okular or Acroread. Following that then printing from the command line, using lpr under Linux, is usually ok. The evince utility, which is the default PDF viewer under most Linux distributions (sometimes known as "Document Viewer"), is the one which has the most problems. The problem is usually memory related; the output file produced by the utility and sent to the printer is too complex in terms of nested data structures or font usage for the printer to cope with, it is not a function of the size of the file in bytes or number of pages. If both okular and Acroread fail then you can try saving the output to file, which will create a PostScript file. You can then "clean it up" using ps2ps, which takes your file as input and outputs a version which conforms with the PostScript Document Structuring Conventions, then you should be able to print that output.

Printing on US Letter paper

The lab does not keep stocks of North American Letter paper (216 × 279 mm). It is available from some commercial printers in Cambridge but only if you use their printing facilities to print onto it.

A PostScript file which does print but which cannot be previewed with ghostview

The file has most probably been produced by Word, or some other Office software. The problem is that Word (etc), and the interpreters in printers take a more liberal view of the PostScript Document Structuring conventions than ghostview does. Strictly there shouldn't be any PostScript code after the end of the Setup section and before the next section. As ghostview meticulously processes each section separately, if there is anything after the end-of-section-marker then ghostview just ignores it, and this can lead to the file terminating with some very obscure error messages. Unfortunately Word documents frequently do put something after the end of the Setup. Printers also process the whole file sequentially (they have to cope with old PostScript which isn't structured, so they can't take a structured approach), and so don't mind if things are out of order, ghostscript likewise. The fix is either to persuade Microsoft to do the right thing, hack ghostview to do the wrong thing, or to manually alter the PostScript files. Fortunately this last option is usually easy. Find the lines that look something like:

        NTPSOct94 begin
        %%Page: 1 1

Put anything after the %%EndSetup back before it, thus:

        NTPSOct94 begin
        %%Page: 1 1

How to print pages xy from a PostScript file?

Depends. Most PostScript files produced by up-to-date applications will conform to the Document Structuring Conventions. This means that the file contains comments which allow other applications (eg ghostview) to break the file into separate pages. E.g. with ghostview: If the file conforms to the DSC, ghostview will print the page numbers in a box to the left of the text. The Page menu contains an option to mark selected pages, the File menu contains options which allow marked pages to be saved or printed. If the file does not conform to the DSC then the only option is to manually edit the file to add the comments or to remove the pages that are not wanted – not a job for the PostScript amateur.

What does Can't select requested paper size for Frame print job! mean?

Imported PostScript documents which were originally produced with the "Frame" publishing system sometimes fail to print, producing instead the message: Can't select requested paper size for Frame print job! This is because the publishing system has hard-wired the size of US letter paper into the PostScript, making it fail on printers without access to letter-size paper (ie almost all printers outside the US).

To fix: find the line which calls the procedure FMDOCUMENT. It will look something like this:
1 1 0 0 612 792 0 1 23 FMDOCUMENT
The fifth and sixth integers are the requested paper size in PostScript points (1/72 inch). If you change the line to read
1 1 0 0 595 842 0 1 23 FMDOCUMENT
it will select A4 paper.

A PostScript file that prints the PostScript as text rather than interpreting it as PostScript

The most common cause for this is that the file begins with the character Control-D. It can be seen if the file is viewed in emacs (as ^D) but will not be seen if the file is cat'ed. Control-D is the flow control character used by the printers, and its presence causes the first part of the file to be flushed by the printer. The rest of the file is read in and treated as a separate file by the printer – but as it doesn't start with the PostScript header comments it is interpreted and printed as text. On some printers Control-D is a reset and sending one before a file is a way of making sure that the printer settings haven't been left over from a previous file. Some Word Processing packages thus helpfully add a gratuitous Control-D at the start of the file. lpr should filter out these unnecessary Control-D's but doesn't. To fix: edit the file and remove the Control-D.

Support for utf8 characters in text files

The default text processor under CUPS is a utility called texttops, which is extremely basic but it does support utf8. If you print the file from the Unix command line with the lpr command then by default it will be sent to a script which uses the a2ps utility instead of texttops - this is in order to produce a nicer banner and to supply a host of other useful options (such as line numbers, setting the number of lines per page, setting margins, arranging in columns, getting landscape right). Unfortunately a2ps doesn't support utf8, and from the look of web comments it never will. Because of this the -u option has been added to the lpr command, which will direct the file via the texttops command instead of via a2ps. Thus lpr -u will give you utf8, but will stop the options supplied by a2ps (-i, -l, -t, -c, -n, -J) from working, and will give a different banner.

The Computing Service Print Room


Members of T&R may still upload documents to the Print Room via FTP, but the mechanism has changed since the days of the Docutech, and the "printer" that's now used prefers Acrobat PDF format to PostScript.

You should still use the "normal" ordering route, but the printing request form allows you to specify the name of a file on the FTP directory in the Print Room.

To submit a file for printing:

  1. Create the print file as PDF on your local filing system.
  2. Use an FTP client to log into as ANONYMOUS (case insensitive). When asked for a password supply your email address. Your current working directory at login will be "/".
  3. Set your transfer mode to BINARY and "put" the file into the remote directory.
  4. Disconnect from the server.

If you haven't sent a hard copy order form, your file will be deleted after a few days.

T&R-specific addendum

PDF for the print room needs no special treatment: it should be prepared in the same sort of way you would prepare any PDF whose quality you care about.

If you are processing (La)TeX, you have several options:

  1. Process using tex or latex, convert the resulting file to Postscript, and thence to PDF using the script ps2pdf (which is available on Lab Linux machines).
  2. Process using tex or latex, convert the resulting file to Postscript, and thence to PDF using Adobe Acrobat Distiller (which is available on some Lab Windows machines).
  3. Process using pdftex or pdflatex, with \pdfoutput=1; the output is usable PDF.

All these mechanisms are valid, but no two of them produce the same size file – there are many different compression options for PDF, and no two processors exercise them in the same way.

Details and problems to avoid

Acrobat PDF is a simplified implementation of the PostScript page model. The thing it most lacks, by comparison with PostScript, is programming capability; this supposedly means that PDF readers are quicker and simpler than PostScript readers. The other major constraint is that the principal PDF reader (Adobe acroread, before version 7) makes an awful hash of bitmap fonts; so the "traditional" TeX way of printing is not appropriate.

The lack of Programmability is usually dealt with in the distillation process (though it impinges on some aspects of the use of pdfTeX: consult the documentation of that program).

However, if we are to produce PDF by distillation, we need to be careful about the fonts we include in our PostScript output (this is something that pdfTeX gets right automatically). The best way to ensure that the correct fonts are loaded is to process the files as follows:

  latex myfile
  pdflatex myfile

If you have any problem with uploading, pass a message to Bruce in the print room, via Computing Service Reception on 34600.