# Error viewing dvi file: Postscript specials could not be rendered

How to rectify this error while viewing .dvi file,

*******
Error: /undefined in H.S
Operand stack:
Execution stack:
%interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1930   1   3   %oparray_pop   1929   1   3   %oparray_pop   1913   1   3   %oparray_pop   1803   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
--dict:1176/1684(ro)(G)--   --dict:0/20(G)--   --dict:80/200(L)--   --dict:95/300(L)--   --dict:17/200(L)--
Current allocation mode is local
MiKTeX GPL Ghostscript 9.05: Unrecoverable error, exit code 1

*************


my tex file

-
Did you include -src-specials while running latex like latex -src-specials samplefile.tex which incorporates source specials into the samplefile.dvi file ? –  texenthusiast Aug 28 '13 at 4:19
You should add a MWE; your TeX file is far from minimal :) –  Svend Tveskæg Aug 28 '13 at 5:50
Please pare down your example. A 9000 line document is not a MWE. –  A.Ellett Aug 28 '13 at 5:57
Also, gsm-l is not a class I have. Please use a more standard class for your MWE. –  A.Ellett Aug 28 '13 at 5:58
It looks to me the same error as in tex.stackexchange.com/q/100260/27635. My answer there tells you how to solve the problem. –  karlkoeller Aug 28 '13 at 7:38

This problem occurs sometimes when compiling a tex file with latex and using a dvi viewer like YAP.

Not sure what exactly causes the problem. In my case, I used MikTex 2.9 to compile a tex file and yap.exe that came along with the MikTex distribution to view the dvi file.

After some browsing on the web, I found that this error might occur if you have included the package hyperref. There are other possibilities as well, which I don't fully understand.

Accordingly, there are two solutions that I found on the web:

1. Change the rendering method from Pk to Dvips. Open Yap: From the menu, select View --> Render Method --> Dvips.

Although this solves the problem, the dvips rendering method is extremely slow and can cut productivity. To see this, just try compiling a 30 page tex file and scrolling down the resulting dvi file. For more details on rendering methods in yap, see http://blog.miktex.org/post/2011/02/Yap-24-render-method.aspx.

2. The second solution works if you have included the package hyperref. Then use the hypertex-driver with hyperref, i.e., \usepackage[hypertex]{hyperref}. Note that you will have to remove this driver option if you want to process the dvi with dvips.

Sometimes, even though you may not have explicitly included the hyperref package, it is possible that it might be contained as part of the class file. To make sure, open the document class file you are loading and if hyperref package is loaded, change it to include the hypertex option.

NOTE: The hypertex option will cause all hyperlinks in the document to be underlined. If you do not want this, then retain it while developing the tex file, so that you can continue using Yap with Pk rendering, and later remove it in the final version.

-

This is encountered very frequently at the AMS in production. (And gsm-l is an AMS document class, based on amsbook.cls.)

There is no really good solution for viewing such output with a .dvi viewer; we don't know of a single one that invariably handles all PostScript "special" code.

The solution used as AMS when this occurs is to convert the .dvi file to pdf and view that with a reliable pdf viewer.

The reference (Problems rendering BeamerTex Postscript specials in WinEdt 6.0) given in a comment by karlkoeller provides a specific implementation of this solution. If the system used by the OP is the same as that in the referenced question, the present question can be considered a duplicate. Other installations have different tools.

-

This looks like the sort of error you get when you include pstricks material in your document and either:

(1) you typed some pstricks commands incorrectly, or

(2) you're not compiling appropriately for a document which includes post-script commands. Try using the

latex -> dvips -> ps2pdf


route if you're not already. (Though I'm inclined to think that you've probably mistyped some code that refers to post scripts.)

I might be able to help you more if you include a MWE illustrate code that duplicates this error.

UPDATE

Well, I dove into your not so minimal-MWE.

1. I changed the class to the book class
2. I made sure I was loading amsthm and amsmath
3. Since I have none of your eps files, I substituted \includegraphics{example-image-a} for all of them.

Once I'd done this. The document compiles fine regardless of whether I use pdflatex or latex->dvips->ps2pdf.

I would suggest that you examine the images you're importing. One of them is perhaps a bit wonky. Otherwise, you might want to talk to others who use the same documentclass. It's possible that there's something in the documentclass itself which is expecting postscripts or something to generate the error you're getting.

Also, I might suggest that you load the enumitem package or something comparable. I notice that in several places you write:

\item[1)]


and so forth. You should leave the numbering to LaTeX. If you load the enumitem package, then you can write something along the lines of

\begin{enumerate}[label=\arabic*)]
\item $C(Q)$ is an associative $\mathbb{K}$-algebra with 1;
\item $J:V\rightarrow C(Q)$ is a linear map and.....


which is much more flexible and easier to manage if you decide to move things around.

To get the effect of \item[a)] you can use

\begin{enumerate}[label=\alph*)]


Additionally, I notice you use $$...$$ for displayed math. This is generally depricated. It would be better to replace this with $...$.

-
ill add my tex file link Ellett, guide me to clear this error –  ravi Aug 28 '13 at 5:34
im now checking on image files –  ravi Aug 28 '13 at 6:13
I would suggest you first change the class and add teh two packages amsthm and amsmath before hunting through all your images. Because.... if by doing that there is no more error, then you can eliminate the images as a likely source of your problem. It then most likely lies in the class that you're using: which I assume you have little choice about. –  A.Ellett Aug 28 '13 at 6:16
@A.Ellett -- changing the class file won't make and difference in this case. the cause of the problem is definitely some postscript code that exceeds what is able to be interpreted by most .dvi` viewers. the solution (used at ams in production) is to convert the output to pdf for viewing. –  barbara beeton Aug 28 '13 at 13:21
@barbarabeeton Good to know. I neither did I realize this was an ams package. –  A.Ellett Aug 28 '13 at 13:35