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.