groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] poll: which macro packages are in common use / and why.


From: Keith Marshall
Subject: Re: [Groff] poll: which macro packages are in common use / and why.
Date: Sun, 26 Sep 2004 09:47:48 +0100

On Friday 24 September 2004 9:39 am, Werner LEMBERG wrote:
> > As Ted has noted, it is possible for the resolution of references in
> > pass two to cause small rearrangements in the document layout, which
> > can result in page numbers being off by one.  In my experience, this
> > can be avoided by running *three* passes, rather than two [...]
>
> TeX does exactly the same.  In some very rare circumstances it is
> possible that references are `jumping' between two pages; you then
> have to reformulate the paragraph to avoid that.

I've been fortunate enough, to have never encountered this :-)

> > One problem I have noted with this strategy -- and it's exacerbated
> > by the requirement to store a significant volume of mapping
> > co-ordinates for the bounding boxes of PDF link hot-spots -- is that
> > it is possible to overflow the available string space, causing groff
> > to abort with an 'input stack overflow error'.
>
> Hmm, groff has an unlimited amount of string space. ...

Surely not.  Certainly it may not *explicitly* set such a limit, but it uses 
dynamic memory allocation, when creating the string objects.  Thus, groff's 
string space allocation must be satisfied from the process heap memory, which 
*does* have a limited size.  When too many strings are defined, then the 
available heap memory will be exhausted, resulting in the condition I have 
described as 'string space overflow'.

> ... There is no
> `input stack overflow' error at all.  What does exist is `input stack
> limit exceeded', caused by too many nested macros (the limit is set to
> 1000 which is should be sufficient IMHO).  Can you provide a small
> example for further analysis?

I should have been more explicit in reporting the error condition.  Sorry.  
The actual message displayed was indeed 'input stack limit exceeded'.  
However, I do not think it was caused by excessive macro nesting.

I do not think I can demonstrate this with a *small* test case.  However, if
you examine pdfmark.ms, included in the preview tarball I posted earlier, you 
will notice a cross reference commented out at line 1726; uncommenting this 
will produce the 'input stack limit exceeded' error in the final formatting 
pass (at least it does on both my GNU/Linux and Win2K boxes, but YMMV).
This error is actually trapped much earlier in the document, at line 139, 
immediately after the definition of the .pdfmark-manual macro, suggesting 
that there may simply have been insufficient heap space available to 
accommodate any new input objects after this point.

The error does not show up in the earlier formatting passes, which are used 
to generate the temporary pdfmark.map file (containing .ds and .as requests, 
to map the cross references within the document).  It is only when this file 
is expanded, to include all the link hot-spot mapping co-ordinates, and is 
then sourced in the final pass, that the error occurs, leading me to the 
conclusion that string space has been exhausted (or has 'overflowed').

BTW, the temporary files used during formatting of pdfmark.ms may be captured 
for inspection, by issuing the command

  ./pdfmake pdfmark.ref pdfmark.map

(note that pdfmake is, in reality, a makefile made executable, by utilising 
the shebang mechanism).

It is also possible to supply additional groff options, for example

  ./pdfmake GROFF_FLAGS="-ww -<other-options>" pdfmark.pdf

Best regards,
Keith.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]