bugGNU roff - Bugs: bug #62572, [gropdf] would like complaint if...

 
 

bug #62572: [gropdf] would like complaint if embedding needed but download file useless

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Fri 03 Jun 2022 02:45:08 AM UTC
   
 
Category:  Driver gropdf Severity:  1 - Wish
Item Group:  Warning/Suspicious behaviour Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 07 Jun 2022 02:38:05 AM UTC, comment #5: 


2022-06-04  G. Branden Robinson <g.branden.robinson@gmail.com>

        * src/devices/gropdf/gropdf.pl (LoadFont): Warn if a font to be
        embedded in PDF output cannot be located in the "download" file.

        Fixes <https://savannah.gnu.org/bugs/?62572>.  Thanks to Deri
        James.


G. Branden Robinson <gbranden>
Group administrator
Sat 04 Jun 2022 04:39:12 PM UTC, comment #4: 

It works beautifully!  I checked out the revision before my fix for the empty "download" file, applied the patch, and got a bunch of lovely complaints, one for each font.

Thanks, Deri!

G. Branden Robinson <gbranden>
Group administrator
Sat 04 Jun 2022 03:59:45 PM UTC, comment #3: 


> > Gropdf could have a moan if the -e flag is present and the required font is not mentioned in the download file,
>
> Yes, this is exactly what I mean to request with this Savannah ticket.  Is it something you feel good about doing?
>


If you insert this line before line 2462:-


Msg(0,"gropdf: Unable to locate font file for '$fnt{internalname}' ($ofontnm) - corrupt download file?") if $embedall;


It seems to do the trick. It is only a warning, gropdf will complete the pdf. Which font is shown will be at the whim of the viewer program.

Feel free to alter the actual text of the message to taste. :-)

Deri James <deri>
Group Member
Fri 03 Jun 2022 09:00:06 PM UTC, comment #2: 

Thanks for the quick response, Deri--you're precisely the person I hoped to hear from.  :)

comment #1:

> I'm not sure how to do this, it is quite permissable to have a blank download file, just as it is in grops. The file in grops lists those fonts which require to be embedded since they are not part of the 35 base fonts for postscript. In gropdf a missing entry also means that the font does not need to be downloaded, i.e. it is one of the base pdf fonts, but because I implemented the -e flag in gropdf I do need to know from where the base fonts can be downloaded. This is why some of the filenames in download have a leading asterisk, they are base files which don't need to to be included in the pdf except when the -e flag is present.


Understood.
 

> Gropdf should not be expected to work without a valid download file,


Agreed.

> which is why I consider removing BuildFoundries from groff executables was a mistake.


I think that predates my time with the groff project...

> It was intended as a tool for the user to use if there were changes to his system which resulted in new positions for the needed fonts, i.e. new version of ghostscript. This is why the program attempts to preserve local changes to download while looking for the URW fonts. It could similarly be used if a user messed up his download file.


I noticed that and did preserve this feature in my recent changes (19f7a3562, 468f7c8fd05).

> Gropdf could have a moan if the -e flag is present and the required font is not mentioned in the download file,


Yes, this is exactly what I mean to request with this Savannah ticket.  Is it something you feel good about doing?

> but without the flag it just means that no download is required, the same as grops.


Acknowledged.

I agree that it would be good to get a download file refresher back into the suite of installed groff tools.  For that I think BuildFoundries is going to need a bit of work.  Maybe a thicker option interface since it has multiple inputs; a usage message; a man page; and a name that meshes well with the rest of the groff command name space.

Maybe "gropdf-refresh-download"?  Having such a script installed to the $PATH would indeed make life easier for 'install-font' users.

(However, this discussion begins to wander off-topic; we should probably continue BuildFoundries matters in bug #58831, bug #40717, or a new ticket.)

G. Branden Robinson <gbranden>
Group administrator
Fri 03 Jun 2022 08:40:47 PM UTC, comment #1: 

I'm not sure how to do this, it is quite permissable to have a blank download file, just as it is in grops. The file in grops lists those fonts which require to be embedded since they are not part of the 35 base fonts for postscript. In gropdf a missing entry also means that the font does not need to be downloaded, i.e. it is one of the base pdf fonts, but because I implemented the -e flag in gropdf I do need to know from where the base fonts can be downloaded. This is why some of the filenames in download have a leading asterisk, they are base files which don't need to to be included in the pdf except when the -e flag is present.

Gropdf should not be expected to work without a valid download file, which is why I consider removing BuildFoundries from groff executables was a mistake. It was intended as a tool for the user to use if there were changes to his system which resulted in new positions for the needed fonts, i.e. new version of ghostscript. This is why the program attempts to preserve local changes to download while looking for the URW fonts. It could similarly be used if a user messed up his download file.

Gropdf could have a moan if the -e flag is present and the required font is not mentioned in the download file, but without the flag it just means that no download is required, the same as grops.

Deri James <deri>
Group Member
Fri 03 Jun 2022 02:45:08 AM UTC, original submission:  

I made a bonehead move with commit 6e62be835d  back on 2 May that managed to break the "download" file for PDF output--it was empty except for a comment.

Around the same time, I noticed that the Courier font in groff-generated PDF files got replaced with an ugly Helvetica on the Evil non-free PDF viewer on my tablet.

It turns out that was not a coincidence.  Now I know why--with the download file practically empty, the fonts weren't getting embedded after all despite the '-e' option.

I would like gropdf to warn about this.  If a font the document needs is not found in the download file, it should warn, alerting the user to the possibility of suboptimal output.

I've fixed the problem I caused; it is pending in my local checkout.

G. Branden Robinson <gbranden>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by gbranden (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-06-07 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-06-04 gbranden StatusNone In Progress
        Assigned toNone gbranden
    2022-06-03 gbranden Summary[gropdf] would like complaint if embedding need but download file useless [gropdf] would like complaint if embedding needed but download file useless

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code