other (me) formats for groff pdf engine

[lodwicz]

Hello!

How feasible is to provide support for other macro packages for groff? It seems to me that feeding the engine with a --pdf-engine-opt=-me should do the trick, but I do not know if this behaviour is documented...

Cheers!

[jgm]

Well, that's just the pdf engine. Pandoc would also have to produce me macros instead of ms. That would require another pandoc writer module. I'm not sure it's worth it: from what I understand, me is thinly documented and has not been maintained for a long time.

[lodwicz]

Well, that's just the pdf engine. Pandoc would also have to produce me macros instead of ms. That would require another pandoc writer module. I'm not sure it's worth it: from what I understand, me is thinly documented and has not been maintained for a long time.

I did write a writer for a Plain TeX package, which I mean to release, but it is easy to fool pdfLaTeX to swallow it via the %&pdftex directive at the top of the generated file and process it as Plain TeX.

In groff there is no similar directive in the source code, but groff seems to override later directives over earlier ones, though I'm not positive if that behaviour is properly documented or I just found it out by accident. Then, as pandoc appends --pdf-engine-opt directives to the command line processor, this might be enough to process other formats, assuming that appropriate custom writer and default files are provided.

However, as you say, perhaps it is not convenient to multiply built in output formats unnecessarily. Thus, I may try to run a test and report back the results, to document this possibility for a further release.

Is that acceptable?

[jgm]

Sure, feel free to do whatever experiments you like! I can't guarantee anything about accepting code into pandoc, though ... it's not clear to me that including a me writer would be worth while. (Any addition increases compile time, source footprint, and maintenance burden.)

[lodwicz]

Sure, feel free to do whatever experiments you like! I can't guarantee anything about accepting code into pandoc, though ... it's not clear to me that including a me writer would be worth while. (Any addition increases compile time, source footprint, and maintenance burden.)

Indeed, now I see your point: not even Plain TeX is listed, and there may be no need to be so, though a hack may do the job for some engines for some particular preferences/needs: in any event, with a suitable writer/template the output may be processed through a custom pipe, and that should be enough, for instance, in my case. Fair enough!

Now, as an aside, I just realized that the man format is not supported as suitable for PDF output, though the infrastructure seems to be already there. Any particular reason for that restriction?

[jgm]

We could probably enable man output to PDF; feel free to suggest the right options for that.