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. _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
