I use pdfroff only because of 2 reasons. If you know how to do the same with groff I would even prefer to use groff instead:
1. ToC. I haven't managed to generate ToC with groff at the beginning of the document. I do not ask for a lot. Just print me the info about header pages (stdout or file) and I will easily generate ToC with Perl/Python script and Makefile target. I guess it is currently not possible? 2. PDF meta data. pdfroff has .pdfinfo, how to achieve the same with groff? Best regards, Michał Kruszewski Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, April 4th, 2023 at 6:13 PM, G. Branden Robinson <g.branden.robin...@gmail.com> wrote: > At 2023-04-04T13:48:39+0000, Michał Kruszewski wrote: > > > Thanks for you response Branden. > > I use ms. > > > Aha, thanks! I started trying to construct a reproducer using mm, then > noticed how terrible our description of the "TC" macro in the > groff_mm(7) man page is, so I've undertaken to improve it. > > A bonus for the forthcoming groff 1.23.0.rc4, perhaps... > > > Fortunately, the document with Makefile is available on github: > > https://github.com/Functional-Bus-Description-Language/Specification. > > You can easily compile the document by simply executing make. Version > > compiled with 1.22.4 is even available in .pdf format in the > > repository. > > > At a quick look I think the problems involve the use of pdfroff. > > If I try to format your document for PostScript using groff 1.22.4, I > get lots of problems as well. Worse ones, in fact. I see that the > header margin is reduced to zero, the cover page doesn't appear at all, > the typeface isn't restored in some places (it gets "stuck in Courier"), > and so on. > > Part of this, I suspect, can be chalked up to pdfroff performing some > initialization of the ms(7) macro package behind the scenes, relieving > the user of that responsibility. > > If I'm correct, then unfortunately this means that pdfroff may make an > ms(7) document seem valid when in fact it is not. Your input looks > carefully composed, so I am hopeful that there is a simple fix, but I > tried some work-arounds, sprinkling calls of internal ms(7) "@init" and > "par@init" macros around in various places, and those didn't > significantly improve the situation. (In one case I did get the header > margin back. But I'd hate to recommend those as anything more than > emergency workarounds; calling ms(7) internals from a document is to be > discouraged.) > > Furthermore, pdfroff author Keith Marshall is no longer maintaining it > as part of the groff distribution. He has a new site for it > https://osdn.net/users/keith/pf/groff‐pdfmark/wiki/FrontPage. It > > could be that that version does not exhibit these problems, but I don't > follow its development, as groff itself keeps my hands full. > > This was a fairly late-breaking change in groff 1.23.0's (very long) > release cycle, so we haven't decided yet if we want to simply withdraw > pdfroff (technically, the contrib/pdfmark directory in the sources) from > future versions of groff, or maintain our own version. (We might have a > volunteer for the latter but I haven't gotten an update from them > lately.) The plan had been to defer this decision until after 1.23.0's > final release, but if a lot of "pdfroff -mspdf"-using documents are > going to go haywire, we may need to make the decision sooner. Or at > least warn pdfroff users of this possibility in the release > announcement. > > > I have checked both PAGE=A4 and PAGE=letter and it looks like there is > > no difference. > > > Yes, I no longer think the page format has much to do with the problems > you're seeing. (It might constitute a minor additional issue on top of > the much worse ones that are evident.) > > I was about to start bisecting our repo so I could at least see where > pdfroff or groff ms changes started to make things go wrong, but > disappointingly, in spite of its claim for support of groff's "-a" > option in its man page, pdfroff does not in fact support it.[1] I was > going to use that to try to speed the evaluation process at each stage > of the bisection. Since there have been over 4,500 commits to the groff > Git repository since 1.22.4 was tagged, bisections can be lengthy. > > I'll have to think a bit about the best way to attack this problem. > > I'm open to suggestions from the mailing list. > > Regards, > Branden > > [1] observe: echo "hello, world" | pdfroff -a
