# [OzTeX] Problem with DVIPS and the production of HyperPostscript output

Andrew Trevorrow andrew at trevorrow.com
Sun Feb 13 03:04:29 CET 2005

```> I've got a 152-page document being processed by OzTeX 5.1 and using the hyperref package (i.e., \usepackage{hyperref}).  My dvi file looks great - all the links that are supposed to be active *are* active: table of contents/figures/tables, footnote numbers, section/page references, bibliographic citations, and all of my \href commands.  If I call DVIPS *without* the -z option and send the resulting Postscript file through Distiller, I get a 152-page PDF document - without any active links, as expected.  BUT, when I *do* provide the -z option (to produce HyperPostscript) and again run it through Distiller, I get a PDF file that contains only the last 6 pages of my original document - but the links *are* active!
>
> The cause of the problem is clearly the Postscript file, since in the first case (without the -z option), the Postscript file is 87Mb, while in the second case, it's only 2.3Mb.  The curious thing about the processing by DVIPS is that it is (seemingly) identical in both cases (i.e., with and without the -z option).  It generates the same "[1] [2] [3<Figures/fig1.eps>] [4<Figures/fig2.eps>] ... [151] [152]" output each time and takes the same amount of processing time.  In looking at the two different Postscript files, I notice that the big one that includes all 152 pages has "DVIPSSectionPage" commands for each page, while the small, 6-page one has only six "DVIPSSectionPage" commands, corresponding to the last 6 pages in the document.
>
> So, my question is, why would the -z option to DVIPS be leaving out the first 146 pages of my document when producing HyperPostscript output?

It looks like the -z option doesn't work correctly if dvips has partitioned
the .ps output into a number of sections (the appearance of DVIPSSectionPage
indicates this is the case).  The output will be in sections if you used
the -S option, or if dvips thinks the output is too complicated and will
exceed your printer's available memory.  The latter is of course pointless
if you are converting the .ps to .pdf so I've decided to rebuild dvips with
a much larger constant that should avoid your output being sectioned.
It should also avoid dvips error messages like "Page n may be too complex
to print" that can occur if you include large/complicated eps files.