[bug #58946] [ms] adapt to use the facilities of pdfmark

[Keith Marshall]

Follow-up Comment #5, bug #58946 (project groff):

[comment #4 comment #4:]
> Just one point of clarification:
> 
> [comment #3 comment #3:]
> > I merely cobbled the current incarnation of spdf.tmac
> > together, while writing pdfmark.ms; it became a conveinent
> > "dumping ground" for supplementary convenience macros, which I
> > used within pdfmark.ms, and in hindsight, would have been better
> > implemented as document-local macros.  XN is one such, (and one
> > which exhibits implementation failings, which I never managed to
> > successfully resolve); there are others, which could similarly
> > be considered for factoring out, as document-local macros.
> 
> Document-level within pdfmark.ms, you mean?
Yes.

> Are the macros you speak of (XN, et al) not general-purpose
> enough to include in pdfmark.tmac?
Definitely *not* in pdfmark.tmac; that's substantially complete, as it stands,
but it is what groff_tmac(5) dubs a "supplemental", or "auxiliary" macro set;
it shouldn't be polluted by anything which is specific to any one of the
"major", or "full-service" macro packages, of which "ms" is just one example.

Similarly, s.tmac shouldn't be made dependent on a stand-alone auxiliary macro
set, on which it has no existing dependency; I contend that a binding package,
such as spdf.tmac is the logical place to implement the interface.

Some of the stuff I shoved into spdf.tmac is nothing more than "syntactic
sugar" — shorthand for features which pdfmark.tmac already supports
adequately, with just a shorter "ms" style name.  Those, I would suggest,
don't really deserve an existence beyond document-local scope — if we
consider pdfmark.ms as an example, then that's where they belong.

That said, XN is one of the macros I dumped into spdf.tmac, which may be a
candidate for remaining there — but not as it stands at present.  It
exhibits flaws, which would need to be addressed; however, it does attempt to
address an extant limitation of "ms" itself: NH, and SH, simply instruct roff
to format the text which follows, up to the next following paragraph macro
call, as a section heading.  There is no inherent provision to use any of that
text, as the basis for a TOC entry, or as a PDF document outline entry, so the
author is left repeating content, for the three contexts; XN, when used
immediately after NH, attempts to address that limitation, by reproducing its
arguments in each of those contexts, (including the section number generated
by NH, in the TOC and PDF document outline contexts, a variant would be
required, for use after SH).

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58946>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/