Re: [Groff] gropdf and pdfroff

[Keith Marshall]

On 30/07/11 00:31, Anton Shepelev wrote:
> Ralph Corderoy:
>> Is  it non-standard?  I thought the normal way was
>> to set up two passes,  or  more  strictly  a  loop
>> until  everything settles down into place, as this
>> is how TeX does it too IIRC.  Not that  TeX's  way
>> of doing anything necessarily makes it right.  ;-)
> 
> I  meant,  non-standard  for  *roff, as it was first
> designed to be a fast  one-pass  formatter.  In  TeX
> world, indeed, two passes are usual and an iterative
> algorithm (taking place within one pass) is used  to
> adjust paragraphs beautifully.

Whether you regard multiple pass [nt]roff to be standard practice, or
not, is irrelevant in the context of a discussion focussed, as the
subject indicates, on *pdfroff*.  Certainly, pdfroff uses troff as its
layout engine, but the usage is *always* multiple pass.  Thus, in the
pdfroff context, multiple pass *is* standard (definitively).

To elucidate further, pdfroff's primary intent is to implement a
streamlined approach to formatting of PDF documents making use of
Adobe's pdfmark features, as encapsulated in my pdfmark macro set.
Principal among these is the ability to implant active cross reference
links within the document, and to have these automatically resolved at
layout time.  While it is certainly possible to resolve backward
references in only a single pass, it is impossible in the case of
forward references; thus, to support reference resolution in either
direction, pdfroff *must* be multiple pass.

Now, to those who say they dislike pdfroff because it rearranges
documents in a manner they don't want, I suggest that you read the
manpage: the `--no-toc-relocation' option disables this feature.

I accept that the implementation of `--no-toc-relocation' is far from
ideal.  In reality, it is a Q&D kludge designed to co-operate with my
spdf.tmac wrapper for the ms macros, specifically for the purpose of
pulling tables of content from the end of the document, (where ms' .TC
macro places them), to the beginning, (where they are traditionally
expected in English language documents); it likely doesn't work well
with other macro packages, without customisation similar to that
accorded by spdf.tmac. [*]

That said, am I about to rush to "fix" this?  Nope.  It works fine for
me, just as it is.  As with all free software, you have the source.  If
you believe you can improve it, you are free to do so.  If you would
like to submit patches, I will consider them, but on my own, I simply
don't have the time to develop pdfroff into an all-singing, all-dancing
tool, which will be all things to all men. [*]

[*] One aspect of pdfroff, which I really would like to improve is its
TOC handling.  There have been various discussions on TOC handling, in
general, on this list, at various times in the past.  I have toyed with
a generic TOC handling mechanism, independent of any other specific
macro package, with which pdfroff might co-operate, but neither my need
for it, nor time available to develop it, have been sufficient for me to
get it "out of the starting blocks".

-- 
Regards,
Keith.