Re: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.

[Deri]

On Wednesday, 16 November 2022 22:57:45 GMT G. Branden Robinson wrote:
> I therefore propose something like:
> 
> gropdf: warning: cannot embed font for 'TR':
> "/usr/share/groff/site-font/devpdf/download" has invalid entry for
> Times-Roman; could not open ".../timesrom.pfa" (Permission denied)
> 
> (lines broken only for email)

Very close, but I still fail to see the benefit of naming the file, the 
problem is the entry, the most likely scenario is a new ghostscript install 
which has changed all the paths/filenames so the entry is stale. 

How about:-

gropdf: warning: cannot embed font for 'TR':
Line nn of "/usr/share/groff/site-font/devpdf/download" has invalid entry for
Times-Roman; could not open the file (Permission denied)

> Yes, it's long.  And yes, every download file with bad entries like this
> is going to produce diagnostic output like it if there is not an
> eventual success in locating the Type 1 font in question.  On the bright
> side, this output should leave the user with few questions about what is
> wrong and what they need to do to fix it.

> > Even more confusing is that you concatenate paths from different
> > download files, so this one message could be referring to multiple
> > different download files.
> 
> That's largely a consequence of this somewhat unusual procedure (among
> groff diagnostic messages) of gathering up some problems and then
> running a filter on them later, which can suppress them in whole or
> part.   Most everywhere else we throw a diagnostic, we throw it at the
> site the problem occurs (possibly filtered by some sort of "user
> interest mask" like GNU troff's warning categories).

So we drop multiple paths, yes?

If the situation arises that the same postscript font is incorrect in more 
than one download file (rare) they will receive a message for the first one, 
then after correction they will receive a message for the second one. 

> > I'm afraid I have failed to see how this can be considered an
> > improvement.
> 
> I concede that you have identified real flaws in my change.  See my
> revised proposal above.
> 
> > Since you didn't wait for me to comment on your proposed changes
> > before committing
> 
> Right; as we discussed in private mail, I thought a "handoff" had been
> performed in Savannah #62950.[1]

Given that what I said was "Will close as the freeeuro thing is not something 
I can fix in gropdf." I was surprised to see changes in the gropdf directory, 
particularly when my preferred fix was:-

"build" freeeuro.pfa/afm by copying to the build directory, the same as is 
currently done for zapfdr and symbolsl

(I admit my other suggestion was complete baloney, altering GROFF_FONT_PATH 
affects the search for download files, not the directories holding pfas.!!).

> > I thought it best not to push my latest fixes for the landscape
> > hotspot issue notified by Blake until you have done your reverts.
> 
> I don't think that is necessary; the hunks of your diff affect lines ca.
> 319 and 1490 of "gropdf.pl".  The commit to which you're objecting
> (4753f2b17b8d836cf66fcb17f5412239e8b45743) altered lines around 676 and
> 2555.  In my experience that is easily generous enough spacing; git
> reverts are not limited to the immediately previous change to a file.
> 
> So I think it unlikely that any changes to relocate the hotspot will
> interfere with font embedding-related work.
> 
> > But I have attached them as a diff to gropdf before your changes, so
> > can be applied after.
> 
> It need not wait; feel free to go ahead and commit now.  If you'd prefer
> I did it for whatever reason, let me know--I'll take care of it, with
> you as --author of course.

That would be very kind, thank you. Please note as well as the rotated 
landscape hotspot fix, it includes appending L or l to papersizes, i.e. -p 
LetterL would specify a landscape letter paper size.

> As noted in private, I feel gated on the reversions because I haven't
> yet heard from you on whether you approve of any of my proposed
> mechanisms for causing the build to fail if font embedding fails when
> generating "groff-man-pages.pdf" (and thereby "keeping the tree green"
> in this respect).  To me, running Poppler's pdffonts(1) to scan the
> generated file is extremely undesirable because doing so doubles groff's
> build time on my system (and surely others').  I'm open to suggestions.

What about a gropdf exit code based on whether any warnings or error messages 
are emitted during the run, could you then test this in the make file, setting 
your green or red flag.

Cheers 

Deri

> Regards,
> Branden