Re: [Groff] pdfroff broken?

[Keith MARSHALL]

Werner Lemberg wrote:
> Thanks.  I have one more request.  Currently, I see the following
> during a `make' for pdfmark.pdf, and I would like to find out the
> reason for it:
>
>  grops:<standard input>:594: lines in X exec command must not be
>                              more than 255 characters long
>  [more similar lines snipped]

Yeah.  I saw that too, but only after I merged this:
|Wed Mar 8 21:54:11 2006 UTC (13 hours, 34 minutes ago) by wl 
|Branch: MAIN 
|CVS Tags: HEAD 
|Changes since 1.5: +1 -1 lines 
|Diff to previous 1.5 
|
|Fix URLs for Adobe's documentation files.
|
|--- pdfmark.ms  2006/02/25 05:49:15     1.5
|+++ pdfmark.ms  2006/03/08 21:54:11
|@@ -150,7 +150,7 @@
| .\" preceding it with "--", to avoid "invalid character in name" type
| .\" error messages from groff (caused by the use of "\~").
| .\"
|-.pdfhref W -D http://partners.adobe.com/asn/acrobat/docs/pdfmark.pdf \
|+.pdfhref W -D 
http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/pdf_creation_apis_and_specs/pdfmarkReference.pdf
 
\
|     -P \(lq -A \(rq\\$1 -- pdfmark\~Reference\~Manual
| ..
| .pdfmark-manual ,

> [I compile groff outside of the source directory in
>  `/usr/local/home/cjk/groff/groff.compiled' which probably causes
>  overlong lines in \X.  Or maybe this is simply a bug.]

I do this too, (with different path names of course).  This isn't
the cause of the overlong \X lines;  the actual cause is that the
.pdfmark macro emits the entire pdfmark code for each link in a
single \X line, and that obscenely long URL exposes a limitation
of this design.

I'd noticed this previously, when putting an excessive amount of
text into a .pdfnote, but I hadn't anticipated that it would affect
a .pdfhref, and had put off seeking a solution until I was ready
to develop the .pdfnote interface further.  Looks like I may need
to escalate my priority for this;  I guess the solution will be to
adapt the .pdfmark implementation, such that it distributes its
output over multiple \X lines.

> Can you add an option to the script, say, -V, to emit the called
> commands sequences instead of executing them?  This allows me to
> walk through all commands step by step.]

Hmm.  I don't think it's possible to completely suppress execution
of all commands;  the intermediate files would at least need to be
compiled, as they are used to control the multipass processing
sequence.  -V would conflict with groff's own use of that option,
but there's already the --show-progress option -- perhaps we could
adapt that, say as --show-progress=verbose, or add a --trace option,
to achieve this effect?

Regards,
Keith.