This page describes known problems regarding RoPS version 4.5. New users are encouraged to download version 5.
Version 4.5, 32-bit release for use under Win95, NT and Win32s is available here or from:
http://www.winsite.com/info/pc/winnt/txtutil/rops3245.zip
The 16-bit release can be downloaded from here or from:
http://www.winsite.com/info/pc/win3/util/rops1645.zip
You can set the default paper size by adding two variables to the rops.ini file. For instance to set the default paper size to American Letter, add these lines after the [framebuffer] label in rops.ini:
WidthMM=200
DepthMM=
266
(note: these variable names are case-sensitive.)
RoPS transfers its in-memory image (which you normally look at on the screen) directly to the printer at 'device resolution', so that one pixel in memory corresponds to one pixel on the printer. If, as is usually the case, the dots on the printer are much smaller than the dots on the screen, the printed image will come out smaller than it looked on screen. You can either zoom in the page a few times before printing, so that it looks big on the screen - it will come out big on the printer too - or you can set a permanent zoom factor by setting the LPI (lines per inch) value in the [framebuffer] section of rops.ini.
(Footnote: For the best result you should use an LPI value slightly smaller than the resolution of your printer. For instance, if your printer operates at 300 lines per inch, add a line saying
LPI=280
to the [framebuffer] section of the rops.ini file. (The value needs to be slightly smaller because most printers cannot print all the way to the edge of the paper. Using a value of 280 would make the printout appear at 280/300ths - 93% - of its actual size.) )
You can read and print the Java documents (http://java.sun.com/JDK-1.0/*) with RoPS version 4.2 or later, if you add the following (long) line of text to the [framebuffer] section of rops.ini (usually found in your c:\windows directory.) NOTE: although there are three lines of text below, they must be concatenated together and the backslash characters must be deleted.
javadocpatch=errordict /undefined 2 copy get { dup /colorimage eq \
{ 5 { pop } repeat 5 1 roll dup [1 0 0 3 0 0] exch concatmatrix 5 2 roll \
3 mul 5 2 roll image } 0 ifelse } dup 4 4 -1 roll put put 0
The patch creates a dummy 'colorimage' operator (using 'image') which, although it is not a complete emulation, is sufficient for the Java documentation.
(Footnote: to be precise, 'colorimage' is defined 'on demand', since some documents check for the existence of the colorimage operator and use alternative code if it is not available.)
(Footnote 2: this patch illustrates an interesting point about the 'framebuffer' section of rops.ini: the right-hand side of the '= ' sign is executable PostScript, the result of which is assigned to the variable whose name appears on the left-hand side.)
It means your document contains an in-line Adobe format font. RoPS versions prior to 4.5 don't know how to process these, and produce the above error message. Download version 4.5 !
It usually means that the PostScript file contains a control-D character. Versions of RoPS before 4.3 contained an error that prevented control-D being recognized properly. The fix is to change the line in ropsboot._ps that says:
/\004 {} def % ignore ^D in input file
to say
(\004) cvn {} def % ignore ^D in input file
Download version 4.3 or later ! Earlier versions of RoPS had a problem with long file names under Windows 95.
If RoPS can't find a required PostScript font, it will substitute 'Courier'. All PostScript printers do this. If you would like to substitute something else, you can edit the line in ropsboot._ps that says
/CourierFont FontDirectory /Courier get /TTName get def
to say (for example)
/CourierFont FontDirectory /Times-Roman get /TTName get def
If the 'findfont: can't find ...' messages annoy you, you can disable them by changing the lines in ropsboot._ps that say:
(findfont: can't find ) print dup = print (; using Courier) print flush
to say
%%% (findfont: can't find ) print dup = print %%% (; using Courier) print flush
(i.e. comment them out.)
Because its often not possible. PostScript is a first class computer language and the images it produces are a side effect of running a computer program. To re-evaluate a page RoPS would need do 'rewind' the program to a point just before it started work on the page. If a document is properly structured this can be done (that's the whole point of the structuring !) but most documents are not properly structured. For a similar reason, it's not possible for RoPS to have a progress bar.
There is a bug in all versions of RoPS since 4.0 wherein the Symbol font is not properly recognized. Change the line in ropsboot._ps that says
TTName (Symbol) eq {
to say
FontName (Symbol) eq {
Download version 4.3 or later ! Earlier versions of RoPS had a bug in the getinterval PostScript operator.
Download version 4.3 or later ! Earlier versions of RoPS had an arbitrary limit to the frame buffer size under Windows 95.
A minimally structured document has '%!' as its first two characters; it then contains a preamble that defines the operations that will be used within the pages, terminated by a '%%EndSetup' comment (on a line of its own.) The data to describe each page follows in turn, with a '%%Page: X X' comment (on a line of its own) at the head of each page. The last page is terminated with a '%%Trailer' comment (on a line of its own.) Running the code for a page must have no side effects; this usually means each page should start with a 'save' command and end with 'showpage restore'.
Because the document contains bitmapped characters intended for viewing at 300 dots-per-inch (dpi.) RoPS samples the bitmap down to about 100 dpi for on-screen viewing so you see only one-ninth of the dots and the resulting characters look scrappy.
Philosophical note: PostScript was designed as a device-independent printer control language with full support for scaleable outline fonts. Many TeX-derived documents are essentially 300 dpi bitmaps and no use is made of PostScript's typographic facilities. If you were to send the same document to a high-resolution PostScript printer running at (say) 2400 dpi, you would still get only the equivalent of 300 dpi output.
It would be easy for authors of TeX -> PostScript conversion utilities to arrange for the executable PostScript code to check whether a suitable outline font was already available in the printer before falling back to using a bitmap, but they don't seem to do this. There is very little RoPS can do in such a circumstance.
In version 4.5:
In version 4.41:
This document is Copyright 1996–1998, Roger Willcocks,
All Rights Reserved.
Last
edited 27 March 1998. Moved to rops.org 19
August 2000.