Summary: | limitcheck in pdfmark during generation of postscript | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | andrew collier <collierab> |
Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | collierab |
Priority: | P4 | ||
Version: | 8.64 | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- | |
Attachments: |
ps file that breaks
outline.png the full table of contents broken document structure |
Description
andrew collier
2009-04-18 03:23:30 UTC
Created attachment 4941 [details]
ps file that breaks
Created attachment 4942 [details]
outline.png
Your Outline tree is enormously complicated and branches to a significant
depth. pdfwrite has a maximum depth for the outline tree of 31, your tree
exceeds 40.
This is a compile-time setting, you can rebuild Ghostscript and modify the
definition of MAX_OUTLINE_DEPTH in /gs/base/gdevpdfx.h where it is currently
defined as 32 (maximum is definition -1).
I don't wish to seem critical, but is it possible that the outline here is
incorrectly constructed ?
I notice that 'Time-Independent Maxwell's Equations' is a node under
'Problems', which is a node under 'Vectors and Tensors'. Should Maxwell's
equations not be a node at the same level as Vectors and Tensors ?
I see this happen repeatedly in the course of the outline tree, for example see
also 'The Wien Law'->Temperature->Waveguides->->Problems->'Special Relativity'.
Perhaps this is intentional, its hard to tell with only the first page to look
at :-) I've attached a PNG of my Acrobat display of this outline to help you
determine whether this is correct.
If you really do want an outline tree of this depth please let me know and I
will increase the maximum in future versions.
hi ken, thanks for your response. i see what you mean with the nesting of those sections. but my table of contents looks fine... please see the attachment. so, although in your viewer it appears that special relativity is nested under problems, in the ps file it is in a separate chapter. this is VERY weird and i am not sure whether the problem is with gs or latex. any further ideas? cheers, andrew. Created attachment 4943 [details]
the full table of contents
The PS file may have unintended outline structure but Distiller 5 can process the file just fine. Probably, the compile time limit should be increased or removed completely. okay, i increased the compile time limit, rebuilt the code... and now the pdf is generated without any errors. however there is still a problem with the document structure. have a look at the screendump from xpdf: later chapters all get grouped in under the last section of the first chapter. since it looks like there is something fishy in the postscript, i guess that the problem here is maybe not with ps2pdf but with dvips? Created attachment 4944 [details]
broken document structure
Hi Andrew, The printed table of contents is not the same as the outline tree displayed in a PDF. The outline tree is built using PDF-specific 'pdfmark' operators which have no effect on printed output, they only affect the production of PDF files. The outline tree in my attachment was actually produced with Acrobat Distiller 9, though the GS output is the same (as per your later attachment). I think the mismatch between what you want and what you get is a LaTex problem, it needs to generate the pdfmarks commands specially, and I guess its doing it wrong. Possibly its something to do with dvips as you say, I'm not very familiar with either. You would have to take this up with the TeX/LaTeX developers I can't help on that one. Alex, although Acrobat can create an outline of this depth, its not what's wanted, and to be honest is less than useful. Of course it would be nice to remove the limitation, but that'll involve quite a bit of coding. At the moment, the outline tree is built in a static array. I'll add an enhancement request to convert it to a dynamic list instead, but with a low priority. For now I'm marking this as INVALID. Andrew, I'm sorry I can't help you with the generation of the PostScript, all I can say is that Ghostscript is doing what's expected of it, the structure generated by the pdfmark operators is incorrect I'm afraid, which comes form the generating application. |