I have had bug reports about crashes when you change pages too fast. I have been able to reproduce the problem but I had to hold the PageDown key down to trigger the bug. I think I know what's going on but I'm still thinking about the best way to fix the problem. Since the bug only manifests itself under extreme circumstances and since I've only had one bug report about this, I'm not going to try and rush a fix out. In the mean time, you can avoid the problem by not holding the PageDown or PageUp keys down, use the page list instead. My apologies if this causes anyone grief.
mgv has no modal dialogs (even the overwrite confirmation dialog in File/Save... is modeless); modal dialogs are evil. This really means that dialogs don't stop you from doing other things in the application: you don't have to back out of a dialog to change something and bring the dialog back--you just go and change things without leaving your current dialog. For people that have lived too long under the tyranny of modal dialogs this may be confusing.
The anti-aliasing support in newer versions of Ghostscript (version 3.33 GNU and higher) is a mixed blessing. For text documents, especially those produced by dvips from TeX DVI documents, the readability advantages are wonderful and easily overshadow the performance penalties (which aren't that noticeable with text anyway); however, anti-aliasing delivers a noticeable performance penalty on graphics and can actually make the images look worse, anti-aliasing can also seriously degrade any document which uses a lot of colors when viewed on an eight-bit display. If you find this happening to you, try using the antialiasEPS resource (or the -aliaseps and -noaliaseps switches) to change the anti-aliasing of EPS files.
If the document does not begin with %!PS-Adobe-, it does not
claim conformance to the document structuring convention; the functionality
of mgv is severely limited when dealing with non-DSC conformant
documents--about all you can do is move to the next page.
Also, zooming in a non-DSC document will always display the first page.
Since I haven't implemented a PDF parser, PDF files are effectively
treated as non-DSC documents so that mgv is quite limited when viewing
PDF files (xpdf or Adobe's Acroread are much better for PDF files).
Some PostScript documents produced by the MS-Windows PostScript drivers will cause erroneous warnings about a lack of virtual memory. When trying to view such documents, you will only get a page telling you that you don't have enough memory in your printer and some steps (which will probably be useless if you don't have the original document) to correct the problem. A simple hack to fix this problem is to find a line that looks like
30000 VM?
and remove it.
The following perl filter should fix such documents:
perl -pe 's/^(\d+\s+VM\?\r?)$/% \1/'
Thanks to Bart Robinson (lomew@cs.utah.edu) in comp.lang.postscript
for this advice.
Windows printer drivers for PostScript also tend to produce incorrect DSC comments.
The Windows PostScript driver builds the NTPSOct94 dictionary which
contains various functions; the required NTPSOct94 begin command appears
between the %%EndSetup comment and the first
%%Page comment so that neither mgv or Ghostview will pass
NTPSOct94 begin to Ghostscript. The simplest solution is to change
%%EndSetup
NTPSOct94 begin
%%Page: 1 1
to
NTPSOct94 begin
%%EndSetup
%%Page: 1 1
in the offending document (this is will leave your PostScript file less
broken rather than fixed).
A better solution--which the NT PostScript driver should probably be
doing--is to remove the offending "NTPSOct94 begin"
command and add "NTPSOct94 begin" at the beginning of
each page and add an "end" at the end of each page.
The following perl script should perform this transformation on its standard
input and print the fixed file to its standard output:
#!/usr/local/bin/perl
$first_page = 1;
$bogus = "";
while($line = <STDIN>) {
##
## Skip NT's brain damage (at least a little teeny tiny
## part of it)
##
if($line =~ /^NTPSOct9[45] begin/) {
$bogus = $line;
next;
}
##
## Insert appropriate begin/end pairs
##
if($first_page && $line =~ /%%Page:/) {
print $line, $bogus;
$first_page = 0;
}
elsif($line =~ /%%Page:/) {
print "end\n", $line, $bogus;
}
elsif($line =~ /%%Trailer/) {
print "end\n$line";
# next line is the "end" that we want to kill
$line = <STDIN>;
}
else {
print $line;
}
}
exit(0);
The same problem occurs with the NTPSOct95 version of the PostScript driver
but the above script should deal with that one too.
The current DSC parser doesn't like Mac files (which use a single carriage return as end-of-line); if you want to view such files, change the carriage returns to line feeds with something like this:
perl -pe 's/\r/\n/g' < mac-file > unix-file
and try again. I could attempt to fix the DSC parser but I'd rather not
touch it until I have time to build a cleaner one.
Files with a PageOrder of Special will confuse the DSC parser--pages will be lost or out of order. If you have to deal with such files, you'll have to use another viewer until I can rewrite the DSC parser.
The application defaults file specifies a significant portion of mgv's behavior; hence, an incorrect application defaults file can cause many problems. If mgv warns you about an incorrect version number, you should fix it--setting the applicationVersion will not fix the problem, it will only make the warning go away.
The correct version of the application defaults file should be installed
in the same place as the documentation (look for a file called MGv)
so you can fix the problem by running mgv like this:
XENVIRONMENT=/path/to/mgv/library/files/MGv mgv
until the local administrator can fix the problem by removing the old
application defaults file. This problem should only be encountered by
people that started with mgv version 1.x.
I have had reports of problems with non-default visuals under Irix 5.3 when the root window has depth eight. Everything works fine with Irix 6.2/6.4 and other systems. Private colormaps do work with Irix 5.3 so all is not lost. As near as I can tell, this is a bug somewhere in SGI's Motif libraries and I don't know how to work around the problem.
If you find any bugs in mgv please send a bug report to mu@trends.net
which includes the following information:
I will try and respond to all bug reports quickly (where quickly is a function of how detailed the report is and how easy it is for me to reproduce) but don't be surprised if it takes me a few days to respond.