bugGNU roff - Bugs: bug #62918, [gropdf] trying to access URW...

 
 

bug #62918: [gropdf] trying to access URW fonts from wrong directory

Submitter:  John Gardner <alhadis>
Submitted:  Fri 19 Aug 2022 11:45:45 AM UTC
   
 
Category:  Driver gropdf Severity:  4 - Important
Item Group:  Build/Installation Status:  Duplicate
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 07 Oct 2022 08:40:09 AM UTC, comment #7: 

Per the discussion on the groff mailing list, I believe this to be the same issue as bug #62860.

https://lists.gnu.org/archive/html/groff/2022-10/msg00005.html

G. Branden Robinson <gbranden>
Group administrator
Mon 26 Sep 2022 03:44:50 PM UTC, comment #6: 


comment #5:

> comment #4:
> > [this] needs to be looked into before 1.23.0 finalizes.
> @Branden: Is there anything else you need from me?


Hi John,

Not yet.

To self: confirm if duplicate of bug #62860.

G. Branden Robinson <gbranden>
Group administrator
Wed 24 Aug 2022 10:13:12 AM UTC, comment #5: 

comment #4:

> [this] needs to be looked into before 1.23.0 finalizes.

@Branden: Is there anything else you need from me?

John Gardner <alhadis>
Wed 24 Aug 2022 10:06:50 AM UTC, comment #4: 

Kicking up to blocker severity because this--that is, the problem originally raised in comment #0--needs to be looked into before 1.23.0 finalizes.

G. Branden Robinson <gbranden>
Group administrator
Fri 19 Aug 2022 07:49:16 PM UTC, comment #3: 


> > 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.
>

Deri James <deri>
Group Member
Fri 19 Aug 2022 04:03:52 PM UTC, comment #2: 

comment #1:

> 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.

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

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.

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, IMHO.

Ingo Schwarze <schwarze>
Group Member
Fri 19 Aug 2022 03:28:06 PM UTC, comment #1: 

This may be an instance of what Werner reported to the list:-

https://lists.gnu.org/archive/html/groff/2022-07/msg00221.html

I don't know if Branden got any further with his suggested fix. It may require a bit more thought. I suspect it may require -M and -F to be set, so that the correct (build) directories are used, rather than the default directories baked into gropdf, which are the directories once it has been installed. The program "test-groff" has all the required setup of the environment, maybe the final line can be changed so that the name of the program to be run can be passed as a parameter, which would mean it can be be used to call pdfmom for the mom examples.

I will be adding a new program, pdfmake, which satisfies forward references in gropdf produced pdfs, the same as pdfmom does now, but for all macros, and this could also be used in the groff-man-pages.pdf generation.


Deri James <deri>
Group Member
Fri 19 Aug 2022 11:45:45 AM UTC, original submission:  

Whilst building Groff from the latest upstream changes (macOS Monterey 12.5.1):


gropdf:contrib/mom/examples/typesetting.mom: fatal error: failed to open '/usr/local/Cellar/ghostscript/9.56.1/share/ghostscript/9.56.1/Resource/Font/C059-Roman'
  GROFF    doc/meref.me
  GROFF    doc/meref.ps
  GROFF    doc/meintro.me
  GROFF    doc/meintro.ps
  GROFF    doc/meintro_fr.me
  GROFF    doc/meintro_fr.ps
  GROFF    doc/ms.ps
  GROFF    doc/pic.ps
  GROFF    doc/groff-man-pages.pdf
gropdf:src/utils/addftinfo/addftinfo.1: fatal error: failed to open '/usr/local/Cellar/ghostscript/9.56.1/share/ghostscript/9.56.1/Resource/Font/NimbusRoman-Italic'
make[1]: *** [doc/groff-man-pages.pdf] Error 1
make[1]: *** Deleting file `doc/groff-man-pages.pdf'
make: *** [all] Error 2


This appears to be caused by the patch number appended to Homebrew's version of GhostScript (something they do occasionally). The correct path of my GhostScript installation is:


/usr/local/Cellar/ghostscript/9.56.1_1/share/ghostscript/9.56.1


(Only the first version number carries the suffix; the rest of the path is correct).

I confirmed this was the catalyst by symlinking "9.56.1" to "9.56.1_1" in the same directory. Attached are the logs from before and after I did so.

John Gardner <alhadis>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53584:  failed-build.log added by alhadis (81KiB - application/octet-stream)
file #53585:  successful-build.log added by alhadis (82KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bgarrigues (Updated the item)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by alhadis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-07 gbranden CategoryFont - others/general Driver gropdf
        StatusNeed Info Duplicate
        Open/ClosedOpen Closed
        Planned Release1.23.0 None
        SummaryWrong GhostScript version reported during build [gropdf] trying to access URW fonts from wrong directory
    2022-09-26 gbranden Severity5 - Blocker 4 - Important
    2022-08-28 bgarrigues Assigned toNone gbranden
        Planned ReleaseNone 1.23.0
    2022-08-24 gbranden Severity3 - Normal 5 - Blocker
    2022-08-19 deri StatusNone Need Info
    2022-08-19 alhadis Attached File- Added failed-build.log, #53584
        Attached File- Added successful-build.log, #53585

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code