This is supposed to work. The one instance where I tried it, it didn't. Maybe it works in other instances. To move and/or scale the postscript code, add the following after every command "showpage" in your PostScript file:
x y translate sx sy scale
where
x - offset horizontal, positive moves to the right
y - offset vertical, positive moves up
sx - scale horizontal, greater than 1 means larger, negative flip left-right
sy - scale vertical, greater than 1 means larger, negative flip up-down
Reasonable values for A4 printout on US Letter are as follows (but it depends on margins):
0.0 -10.0 translate 1.000 0.950 scale
Here is a document which describes how to solve problems associated with printing PostScript files. The major problem is printing MS generated PS files. These files are actually EPSF files and this language does not handle multi-paged documents.
Currently in the works is configuring our printers to recognize EPSF files or specifying a printer such as snidely-epsf. Until then, you can use my printps2 print script. Just type:
printps2
PostScript code is produced by many programs on the market. Unfortunately, the authors of these didn't take the time to read the documentation on the Adobe Document Structuring Conventions (DSC) contained in the PostScript Language Reference Manual, 2nd Edition. Consequently, there are a number of common errors that occur in PostScript files, which cause grief when the PostScript is processed by a document manager such as GSview or Ghostview.
%%BoundingBox: uses integers.
Do not use floating point numbers.
%%BoundingBox: should be correct.
Giving a bogus bounding box isn't helpful.
EPS files should be 0 or 1 pages.
Windows 3.x offers the option "Print To" "Encapsulated PostScript
File". People think this is the way to produce PostScript multipage
files. WRONG! Instead it creates a multipage file with an EPS
header. This option should have been written to prevent output of any
pages after the first. The correct way to get a PostScript file is to
"Connect" the printer to "FILE:".
My preference is for single page EPS files with a BoundingBox that
is in the printable area of most printers. These EPS files can be
printed OR imported.
Use %%BeginDocument/%%EndDocument around imported files.
Imported documents should be encapsulated with %%BeginDocument /
%%EndDocument to allow document managers to skip over embedded DSC
comments. The Word 6 EPS import filter uses %MSEPS Preamble / %MSEPS
Trailer, when it would have been just as easy to use the correct
comments.
Put PostScript code where it belongs.
PostScript code should be in the prolog, setup, page or trailer
sections. It should not be between the setup and page sections
(Windows 95/NT). Page size changing commands should be in the setup
section, not the prolog or the page sections.
Page independence.
Unless instructed otherwise with the %%PageOrder: Special comment,
document managers expect that pages are independent and may be
reordered. The default configuration of the Windows 3.x PostScript
driver is to produce output with page dependence. This can be changed
by selecting "Options | Advanced | Conform to Adobe Document
Structuring Convention". If this item is not checked (the default),
then Windows 3.x produces PostScript output that incorrectly claims
DSC conformance. Windows 95 knows about %%PageOrder: Special. Hoorah!
Lines should be shorter than 254 characters
Microsoft Windows 3.x produces lines in a %%BeginData section that are
longer than 254 characters. If you want to be really safe, then lines
shorter than 80 characters so the files don't get mangled by mailers.
Use the correct DSC identifier.
OS/2 uses %!PS-Adobe- instead of %!PS-Adobe-X.X where X.X is the
version number. If the PostScript doesn't conform to the DSC, then a
simple %! should be used. Note that X.X is the version number of the
DSC (typically 2.0, 2.1 or 3.0), not the PostScript level (1 or 2).
Ctrl-D is not PostScript
Don't start a file with a Ctrl-D since PostScript files are usually
identified by the presence of %! as the first two characters. By
default, Windows 3.x prepends a Ctrl-D to PostScript files. This bug
can be disabled by adding CtrlD=0 to the appropriate section in
win.ini. See printers.wri for more details. Ctrl-D is a part of a
commonly used serial line protocol used for PostScript printers. The
Ctrl-D should really be added by the Print Manager after each
PostScript job is sent to a PostScript printer connected by a serial
line.