Follow-up Comment #12, bug #66653 (group groff): On Saturday, 30 August 2025 10:46:28 BST you wrote: > Follow-up Comment #9, bug #66653 (group groff): > > Hi Deri, > > A few days ago I started digging into this at last. > > At 2025-01-10T12:13:28-0500, Deri James wrote: >> Date: Fri 10 Jan 2025 05:13:24 PM UTC By: Deri James <deri> >> First I will explain what I am trying to accomplish, before describing >> the issue. >> >> With the demise of pdfmark.pdf and mspdf.tmac I realised that creating >> a replacement would be a lot easier if we did a similar job Branden >> did for man but this time for ms. Branden is correct that Keith's >> original pdf work is more unixy than roffish, using commands on a >> single line and various flags, and his mspdf.tmac provides new >> commands which are wrappers around existing ms commands with added pdf >> extensions. So instead of:- >> >> .NH 1 >> Introduction >> >> It supports:- >> >> .NH 1 >> .XN Introduction >> >> Apart from having to learn new commands it is also less flexible. Ms >> allows:- >> >> .NH 1 >> Introduction to >> .I groff >> >> Which would have to be converted to inline font changes to work with >> .XN. > > Right. I've long been uneasy with this departure from what is idiomatic > for ms(7) (and to some extent mm(7)) documents. > >> It also means that existing ms documents can't magically start using >> pdf features without considerable editing. The gold standard >> "solution" would be if the output was pdf then pdf features are >> automatically included, the same as Branden did with man. > > It won't surprise you that that's what I think. Getting man page > authors to adopt new habits is just shy of futile; where possible, I > think the path to success lies in making existing features "just work". > > Sometimes that's a lot easier said than done; my quest to resolve this > problem has forced me to learn a lot about deep formatter internals, > including stuff that's never really been documented. It also produced a > few struggles between us to make sense of what's really going on in > those mysterious internals. > >> As a proof of concept I attempted to make .NH produce a document >> outline as well as headings. I used ms.ms as a test document, > > That's an ambitious guinea pig, since ms.ms exercises most of the > package's own features. On the bright side, if we can tame this beast, > I expect most user documents to fall to our sword as well. > >> using the command >> "test-groff -Tpdf -ms -M. -mpdfms -pet -ww ../doc/ms.ms > msdj.pdf", >> the result is attached. > > Looks excellent! The only thing I expected that I didn't get was > hotspots in the document's table of contents at the end. However, since > there's a lovely navigation bar (in a sufficiently brainful PDF viewer, > meaning NOT DROPBOX), that's an inconsequential defect.
Hi Branden,
I continued to work on pdfms.tmac but leaving this one in aspic as an example
of asciify crashing the formatter. The pdf files in comment #8 were all
produced with the latest version of pdfms.tmac, even pdfmark.ms works without
using pdfroff and the mspdf.tmac.
I am attaching the latest version, use it like this:-
pdfmom --roff -T pdf -petk -ms -mpdfms doc/ms.ms | okular -
You should notice a clickable TOC at the end of the pdf for ms.ms, if you add
a judicious ".RP (no)" to the document you should see a title page and the TOC
following (auto relocation).
I wrote the new tmac in mitigation for losing pdfmark, pdfroff and spdf,
simply as a proof of concept. For 1.25 I think it would be tidier to integrate
the techniques into s.tmac itself with a flag (OPMODE) which can be used to
turn off pdf features, and you are better at writing macro files than I am, my
choice of names veer towards "stunted"!!
> Support for hotspotted external URLs might be more important.
>
> That in turn might mean adding `UR` and `UE` macros to ms(7). As I've
> noted elsewhere, I am not a fan of "www.tmac"'s approach.
I agree.
>> Seems to like pic.ms too.
>
> I know from hard experience that that document is good at breaking
> grohtml; may gropdf fare better.
[...]
>> Any good ideas, or better approaches, would be appreciated.
>
> I think you're on a good directional track. We just need to dig some
> boulders out of the formatter's roadway so your changes can pass easily.
Just the dummy_node issue left, see previous email today.
> Regards,
> Branden
>
>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66653>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
