Re: [Groff] status of pdfmark macros

[Keith MARSHALL]

>> On my systems, the 'pdfmake' script provides this capability -- this
>> is why I chose the unusual name, for what is essentially a makefile!
> 
> Exactly this is the problem.  A shell script should really be that --
> not a she-banged Makefile.  We can't expect that `make' is available
> on the target platform, while `sh' definitely is.

Would that this were true!  On a standard Win32 system this isn't the
case, so a user installing a prebuilt binary implementation of groff,
such as Kees Zeelenberg's GnuWin32 package, will also need to install
some other package which provides 'sh', otherwise none of the shell
scripts provided by groff are usable :-(  (Of course, this applies to
'nroff' and 'neqn', amongst others, in addition to any new 'pdfmark'
script we might provide).

> IMHO the following must be done:
> 
> ...
> 
> I'm sure that I've missed something.  Hopefully, you have some time to
> work on those items.

I knew there was still a fair bit of work to be done, to integrate this
stuff properly.  At present, I don't have as much time to work on it as
I would like, but I will plough on as time permits -- unless, of course,
anyone else would like to take up the challenge, and assist!

I do agree that the conversion of my existing makefile to a shell script
would be a more elegant, and portable, ultimate goal.  Maybe it would be
worthwhile to provide a hybrid interim solution, while the final script
is worked up -- what do you think?

One option I did consider, and haven't dismissed entirely, is to add a
'-Tpdf' device selector to 'groff' itself, with pre- and postprocessors
similar in concept to those of grohtml.  The postprocessor could be a
simple wrapper around 'grops', with its output piped through 'gs', and
perhaps with some mechanism for reordering the 'gtroff' output, e.g. for
relocating of TOCs.  The preprocessor would necessarily be more complex,
handling the resolution of references, as currently handled by my makefile
implementation.  Perhaps something to consider, for a future release, if
you think it worth the effort of implementation?

Other areas where I think further effort is required include:

  -  completing the pdfmark.pdf documentation for the core
     pdfmark.tmac macro package, and its ms, etc. bindings;

  -  tying up some loose ends within pdfmark.tmac itself;

  -  tidying up the provided spdf.tmac binding package for ms
     (there is a fair bit of unnecessary cruft in there, left
     behind from experimental development, and even simply
     some quick hacks, for PDF documents I was working on, at
     an early stage in the development cycle);

  -  providing additional binding packages for mm, me, etc.
     (perhaps some of the mm, me, etc. experts out there would
     like to help with this?)

Given that I do have quite heavy constraints on my time, at the moment,
how would you like me to prioritise my efforts?

Best regards,
Keith.