Head & tail

Problem:

Inability to view or print is caused by the existence of unwanted lines at the head of the file, or unwanted characters at the beginning of the first line, and unwanted lines appended at the end of the file.

Often the lines at the head and tail of the file correspond to escape sequences which are sent to the printer to explicitly force it into and out of PostScript printing mode.

Solution:

The first line of the file must begin with %!PS-Adobe-...

Strip off any lines above this, or any characters before it on the first line.

The file should end with %%EOF (or %%Trailer with perhaps valid lines in the trailer block).

Strip off any lines after this.

CorelDRAW EPS head & tail

Problem:

Will not view using Ghostview or Ghostscript. Will not print.

The problem is caused during the creation of the EPS file by CorelDRAW. Unwanted characters are inserted at the beginning of the first line and unwanted lines are appended at the end of the file.
(See below for instructions on how to avoid this problem.)

Solution:

Strip all unwanted characters off the first line of the file from the start of the file until %!PS-Adobe-... is reached.

Strip all unwanted lines off the tail of the file, starting after the line %%EOF until the end.

CAUTION: many of these lines are extremely long binary strings (may be 1 MB long) and editors tend to freeze if an attempt is made to go to the end of the file and start deleting backwards. Find the %%EOF line, move to the next line and then start deleting by word or line. Normally there are only about 5-50 lines of data to delete.

Real solution:

When saving to EPS format in CorelDRAW, using File Export, ensure that in the EPS Export window:

Export text as:
  is set to Text and the Include fonts box IS checked
NOT
  set to Curves.

Image header:
  The Include header box IS NOT checked.
(If checked, this produces the unwanted code at the head and tail of the file.)

Scan

Problem:

All attempts to edit submitted EPS file fail, or no electronic version of the figure exists.

Solution:

Scan, using Adobe Photoshop or similar package, and save as an EPS file.

EOF

Problem:

%%EOF line followed by CTRL D character. Caused by the software package used to create the EPS file or using the -F1 option in dvips.

Solution:

Delete the CTRL D character at the end of the file.

Suppress printer setup

Problem:

Explicit printer setup commands are contained in the
%%BeginSetup ... %%EndSetup
and/or
%%BeginPageSetup ... %%EndPageSetup
sections of the PostScript file which cause viewing and printing problems.

Solution:

Find the
%%BeginSetup ... %%EndSetup
and
%%BeginPageSetup ... %%EndPageSetup
sections of the file.

Look for sets of lines like:

%%BeginFeature: *OPTION
... (SETUP)
%%EndFeature

where *OPTION can be:

*PageSize US Letter
*Resolution 300dpi
*InputSlot AutoSelect Tray
*ManualFeed
*Duplex
etc.

Either delete or comment out each line corresponding to
... (SETUP)
(Comment out a line by placing a single % at the start of the line.)
Blank lines may be left as no printer setup is specified.

Suppress whiteout

Problem:

Almost all problems are due to the use of the Microsoft Windows PostScript Driver PSCRIPT.DRV.

The PostScript macro rf (often multiply defined in the various PostScript dictionaries in the file) is defined to execute a rectfill (rectangular fill) of the defined area (full US Letter or A4 page) in the defined colour (white).

Even if the bounding box values for the image are correct, when the scaled image is laid down on the page it still retains a white border corresponding to a whiteout area of a full US Letter or A4 page scaled down by the figure scaling factor. This whiteout area obliterates any underlying text or images which have already been defined in the PostScript file (text or images defined later in the file can overprint this whiteout area).

Solution:

Find the
%%BeginPageSetup ... %%EndPageSetup
section of the file and then the line

userdict begin /pagesave save def end mysetup concat colspRefresh : 1.000 1.000 1.000 sco 0 0 XXXX YYYY rf ;

where XXXX YYYY =

2550 3300 (300 dpi, US Letter, 8.5" x 11", portrait)
3300 2550 (300 dpi, US Letter, 8.5" x 11", landscape)
5100 6600 (600 dpi, US Letter, 8.5" x 11", portrait)
6600 5100 (600 dpi, US Letter, 8.5" x 11", landscape)
2480 3508 (300 dpi, A4, 210 mm x 297 mm, portrait)
etc.

Edit the line by replacing both XXXX and YYYY with 0.
(For safety, copy and comment out the original line first.)

Now the rf rectangular fill command is filling a zero area rectangle with white.

Re-run LaTeX2e and dvips to check that the whiteout problem has been solved. If it remains, check to see if code performing a white clip fill also exists in the file, as outlined below.

Or, calculate the correct bounding box values and use the clip= option with the \epsfig command or the clip option with the \includegraphics command when using LaTeX2e.

Remove white fill

Problem:

Clip area defined and filled with white before laying down a particular part of the image, obliterating any underlying text or images which have already been defined in the PostScript file. The clip area is often too large, especially if a frame has been removed, a heading changed, captions moved, or the position of image elements changed.

Solution:

Normally the offending code will be found at the start of the PostScript code which draws the particular part of the image.

Look for code such as:

xxxx yyyy N M XXXX YYYY rr : 1.000 1.000 1.000 sco O ;

which starts a newpath and moves to xxxx yyyy before defining a relative clip area of dimensions XXXX YYYY and performing a white fill. Edit the line by changing both XXXX and YYYY to 0.

Or look for code such as:

: 0 0 XXXX YYYY rc

which defines a rectangular relative clip area of dimensions XXXX YYYY and performs a white fill. Edit the line by changing both XXXX and YYYY to 0.

Or look for code which defines a newpath, moves to a point, defines a box by a series of four lines, and then performs a white fill using the F macro. In this case, comment out or delete these particular lines of code.

In each case, XXXX and YYYY are large numbers corresponding to the overall size of the image. There may be many instances of such strings of code in the file because many software packages clip and white fill areas before laying down each element. However, the offending set of code is normally at the head of the PostScript code defining the image.

If these attempts fail, calculate the correct bounding box values and use the clip= option with the \epsfig command or the clip option with the \includegraphics command when using LaTeX2e.

Imperfections
Imperfections on a scanned image need removing.

Scanned image

Problem:

The file has been created by scanning an image or by conversion from another file format using a package such as XV. The image has unwanted features such as a frame, imperfections, or whitespace.

Solution:

If the original bitmap file (JPEG, GIF, TIFF, etc.) is available, whitespace may be cropped using XV or a similar package.

If removing whitespace, edit the preamble defining the number of pixels in the horizontal and vertical directions, and then either remove the unwanted lines of hex code at the top and/or bottom of the image, or edit every line of hex code to remove pixels on the left or right.

If removing unwanted lines or imperfections, edit the corresponding hex code for each scan line.

(NOTE: This procedure requires a detailed knowledge of the hex code syntax, which differs depending upon which software package was used to produce the image.)

Warning:

If the scanned image has unwanted whitespace around it, beware of merely using ps2epsi to find the correct bounding box values, editing the .eps file to insert the correct bounding box values, and then rescaling the image in the document. The white pixels forming the unwanted whitespace border will also be scaled and may overwrite any neighbouring text or images that have already been defined in the PostScript file. Therefore the steps outlined above should be followed in order to remove any unwanted whitespace from the image.

If editing of the hex code is impractical, calculate the correct bounding box values and use the clip= option with the \epsfig command or the clip option with the \includegraphics command when using LaTeX2e.

Remove spurious item

Problem:

A vector graphics figure contains spurious dots or lines.

Solution:

Comment out the relevant code.

Remove frame

Problem:

The image has been produced with an unwanted frame box drawn around it.

Solution:

In the case of a scanned image file, the hex code of each affected scan line has to be edited, as described above.

For a vector graphics EPS file, the PostScript code defining the frame box lines has to be found and deleted, commented out, or modified. The code is normally near the head or tail of the PostScript code which defines the image.

Occasionally the frame box is drawn twice, so two sets of code have to be modified.

Change heading

Problem:

The figure includes an unwanted heading which is duplicated in the figure caption, or an incorrect heading, or other unwanted or incorrect text.

Solution:

Find the relevant PostScript code (normally easy to find by searching for the actual words or fragments of the words) and either comment out (sometimes fails) or replace by null fields.

If the text needs changing, modify the relevant code. However, positioning problems may result if major modifications are made.

Some software packages do not use PostScript fonts for text, but draw a series of lines instead. These are far more difficult to edit, but sometimes the correct sections of code can be found and removed.

Change captions

Problem:

The captions on graphs are incorrectly labelled or are in the wrong position.

Solution:

As for headings, find the relevant code and alter the wording or positioning.

To alter the position of a part of the image, use the x y translate command before the relevant section of code, followed by a compensating translation in the opposite sense before the remainder of the code in the figure.

Change position

Problem:

Part(s) of an image are incorrectly positioned, either in the original figure or as a result of removing or adding text or other features.

Solution:

Reposition parts of an image using the x y translate command before the relevant section of code, followed by a compensating translation in the opposite sense before the remainder of the code in the figure.

Change linewidths

Problem:

Some or all linewidths are too thick or too thin in the figure.

Solution:

Find the n setlinewidth command (or the corresponding macro command) for the relevant part of the image and alter the value of n. Some software packages assign global linewidths, others explicitly assign values for each set of line elements.

Change colours

Problem:

Colours need to be changed in the figure for some reason. In particular, pale colours such as yellow or cyan reproduce poorly when printed on monochrome laser printers. Lines, arrows and labelling should not use pale colours.

Solution:

Either change the colour completely or darken it by changing its RGB values to lower indices. For the standard primary colours change indices of 1 to 0.8.

Find and edit the r g b setrgbcolor values for the relevant parts of the image. Some software packages define global macros for a palette of colours, in which case only one set of rgb values has to be changed to alter all such instances of the colour in the image. Other software packages explicitly assign values for each set of line elements.

Sharpen JPG

Problem:

The clarity of a scanned image is poor and needs to be sharpened or blurred.

Solution:

Use a package such as XV or Adobe Photoshop to modify the appearance of the image.

LaTeX & dvips

Problem:

In many instances, PostScript files masquerading as EPS files can be used successfully in LaTeX2e documents, either unaltered or by using one of the fixes described in this table.

However, PostScript files that have been created by writing LaTeX code to place an image on a page, then running LaTeX2e and dvips to create a PostScript file, have the problem that they have incorrect bounding box values in the heading and embedded code specifying a full US Letter or A4 page size. Therefore the images will not scale properly. The irony is that a (perhaps) perfectly good EPS file had to be used to create an unusable PostScript file.

Solution:

If the original EPS figure file cannot be obtained, edit the PostScript file by stripping out all of the code after the %%BoundingBox: line in the heading until %%Page: 1 1 is reached.

Use the llx lly urx ury values in the @beginspecial command as the possibly correct bounding box values and edit the %%BoundingBox: line in the heading.

Then delete the code starting at %%Page: 1 1 until after the %%BeginDocument: line.

The PostScript code defining the image follows.

At the tail of the file, comment out the lines created by LaTeX2e and dvips and leave the %%Trailer and %%EOF lines and relevant code in the Trailer block.

View the file using Ghostview or Ghostscript to see if it works, and run ps2epsi to confirm the bounding box values.

ps2epsi

Problem:

Bounding box values wrong, image does not scale to column width correctly. Often too much white space around figure.

Solution:

Run the ps2epsi package to determine the correct bounding box values from the resulting .epsi file which is created (see the %%BoundingBox: line at the head of the file). Comment out the incorrect %%BoundingBox: line in the .eps file and insert the correct one (edit the .eps file rather than using the .epsi file because the .epsi file is larger due to the fact that it also includes a preview of the image).

Sometimes the ps2epsi package runs but produces an error message; the resulting .epsi file is not viewable. However, in many cases the bounding box values have been computed correctly and can be copied from the head of the file.

If ps2epsi fails completely, the bounding box must be determined via Trial and error.

ps2epsi also fails to calculate the urx coordinate correctly if an image created in landscape orientation was saved in portrait orientation. In this case urx=612 (8.5" in points) for US letter paper mode or urx=595 (210 mm in points) for A4 paper mode. Use Trial and error to find the correct coordinate value.

Warning:

After using ps2epsi and editing the .eps file, re-run LaTeX2e and dvips and then use Ghostview or Ghostscript to check that the image has scaled properly. In addition, ensure that neighbouring text or images have not been clipped by an extended whitespace around the image. See the instructions for how to suppress whiteout.

Trial & error

Problem:

ps2epsi or other solutions fail to determine the correct bounding box values.

Solution:

Using Ghostview the llx, lly, urx, ury values can be determined by moving the cursor to the outermost left, bottom, right and top pixels of the image respectively and reading the relevant coordinate from the coordinate display box.

Edit the .eps file by inserting the new values in the %%BoundingBox: line, then view the resulting file using Ghostview or Ghostscript. If the bounding box is correct, the Ghostview or Ghostscript window will scale to exactly enclose the image. Edit the estimated values to correct for any whitespace or clipping.

A good estimate can be gained by printing the .eps file, drawing a box around the image which just touches the outermost top, bottom, left and right pixels of the image, and then computing the coordinates of the lower left and upper righthand corners of the box to determine the llx, lly, urx, ury values in points (72 pt = 1 inch). The origin of the coordinate system is the lower lefthand corner of the paper.

Strip preview code

Problem:

The file contains image preview code inserted by the software package used to create the image when saving as an EPS file. The ps2epsi package also creates an image preview. While image previews are required by some wordprocessing packages such as MS Word, LaTeX2e and Ghostview ignore them and they take up unnecessary disk space and increase the download time to page viewers such as Ghostview.

Solution:

Strip out the unwanted code.