[bug #62918] Wrong GhostScript version reported during build

[Deri James]

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

> > I will be adding a new program, pdfmake,
> 
> Please don't.
> 
> Adding yet another program for each afterthought forgotten in the original
UI 
> design ruins an API by adding more and more complexity and accumulating more

> and more technical debt.

I agree, the original API for producing pdfs was set by pdfmark, gropdf
follows
this.

> There is only one job: generating a PDF file from roff(7) input, so there 
> should only be one user-visible program doing that. 

I agree again, only gropdf directly produces a pdf.

> But we already have 
> three: groff -T pdf (which itself is a wrapper around troff(1) and 
> gropdf(1)!), pdfmom(1), and pdfroff(1), which really is a shame.

Not quite, pdfroff is using multiple runs of groff -T ps and ghostscript
to produce a pdf.

pdfmom is using multiple runs of groff -z and gropdf to produce a pdf.

The reason why there are multiple runs is to collect any forward references
in the file. If you have no forward references in your file, groff -T pdf is 
sufficient, or groff -T ps | ps2pdf -.

> Considering that groff(1) already is a wrapper, the best design would
clearly 
> be to make groff -T pdf do the right thing and get rid of the wrappers 
> wrapping wrappers.

Absolutely. My dream. However, in order to do this, troff would have to do 
multiple passes, the same as tex does, so that any forward references can be 
reconciled before being passed to the output driver. I don't think many would

be in favour of this direction even if it had the advantage of getting rid of

all wrappers.

> But even if such a cleanup of the design and implementation would cause too

> much work right now, adding yet another wrapper around wrappers around 
> wrappers sounds like an absolutely terrible idea to me.  The minimum amount
of 
> design work to be done when adding a new feature is to make sure that it
does 
> not ruin the quality of the already dubiously designed user interface even 
> further, 

If you want troff to do multiple passes, it would be a lot of work. If you 
like the single pass nature of troff (as I do), then a wrapper which does the

multiple passes is a necessity.

Now, why are there two wrappers (pdfroff and pdfmom)? They have significantly

different code paths to produce a pdf, one chose a deeper integration with ms

and one with mom. I would have preferred to integrate pdfmom code with 
pdfroff, but I was a little afraid of the author, I was aware that writing 
gropdf, I was stepping on his toes.

And why do I want a third? Well, I don't really. Pdfmake and pdfmom are the 
same program, one is a symlink to the other, if called as pdfmom it just 
includes -mom for you. Whereas if called as pdfmake the macro package can be 
set on the command line. I'm not wedded to idea of a third wrapper, given that

my desire is to give users of other macro sets an easy way to produce pdfs 
with forward references via gropdf, one way would be to add the code to 
pdfroff, to be triggered if the flag -T pdf is found.

Please let me know what you think, I appreciate your clear thinking. However,

this is probably not the best place, we have rather hijacked a valid issue 
with the build for which I was trying to be helpful.

> IMHO.
> 


    _______________________________________________________

Reply to this item at:

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

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