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.
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 (w-107-CB3-0FD, Note: machines need to be registered for this network) 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 "lpr.cl". As an example of the difference, to print a file on the printer palm with staples using the script:
lpr.cl -Ppalm -staple filename
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:
- Direct connection using IPP. This is suitable for Windows 7 or 8 machines with a wired or an unwired connection
- Using Bonjour. This is suitable for Windows 7 or 8 laptops.
- Indirect connection via a Windows server. This is a legacy service, which we would like to phase out, so it is not recommended. However, printers already set up in advance may well use this method.
There are two methods of preloading printers available for Macs:
- Using Bonjour. This is suitable for machines with a wired connection (and is the simplest method).
- Direct connection using IPP. This is suitable for machines with a wired or an unwired connection
List of printers and their locations
- See https://dbwebserver.ad.cl.cam.ac.uk/SCG/Printing/Printing.aspx (lab password required)
- Or https://cups-serv.cl.cam.ac.uk:631/
- 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
Further details on the use of this printer and the laminator are at gum.
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
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 glleftthen 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:
%%EndSetup NTPSOct94 begin %%Page: 1 1
Put anything after the %%EndSetup back before it, thus:
NTPSOct94 begin %%EndSetup %%Page: 1 1
How to print pages x–y 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:
- Create the print file as PDF on your local filing system.
- Use an FTP client to log into csi-docutech.csi.cam.ac.uk as ANONYMOUS (case insensitive). When asked for a password supply your email address. Your current working directory at login will be "/".
- Set your transfer mode to BINARY and "put" the file into the remote directory.
- Disconnect from the server.
If you haven't sent a hard copy order form, your file will be deleted after a few days.
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:
- 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).
- 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).
- 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.