bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Keith Marshall
Subject: [bug #58946] [ms] adapt to use the facilities of pdfmark
Date: Mon, 26 Jul 2021 06:32:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0

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

[comment #2 comment #2:]
> >> In the groff system, XN is defined in spdf.tmac
> > 
> > Which, I would suggest, it should NOT be ....
> > 
> > Since it is provided purely as an example, it has no place in
> > ANY of the standard macro packages; it would be more appropriate
> > to relocate it to an "examples" repository, and, in hindsight
> > I should have defined it directly within pdfmark.ms
> 
> Keith, if this is the only task, I'll update this bug's Summary accordingly.
 (Probably the summary needs to be updated anyway, since your post implies the
bulk of the work for integrating ms and pdfmark is done, with merely some
housekeeping left to take care of.)

I never _really_ intended spdf.tmac as anything more than an example of — or
potentially, a foundation for — development of bindings for use of
pdfmark.tmac in conjunction with some other document formatting macro package
... s.tmac, in this particular case.  Just as POSIX extends ISO-C, with the
extensions normally being implemented through supplementary header files and
libraries, pdfmark.tmac extends s.tmac, (and potentially other macro packages
which offer similar functionality to s.tmac); spdf.tmac provides the
supplementary "glue" to bind pdfmark.tmac features to s.tmac, but nothing
within spdf.tmac really belongs as an integral part of s.tmac itself.

That said, 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.

So yes, spdf.tmac could _definitely_ benefit from some housekeeping, before
formal adoption as a binding between s.tmac and pdfmark.tmac; s.tmac itself
should require no associated modification.  (I left pdfmark.ms very much
incomplete, so that will require some further attention; I've also observed
some issues which may be best address within pdfmark.tmac, but these should
likely be addressed by way of separate tickets).

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]