[bug #64577] [grops] can't embed/download fonts from a subdirectory

[G. Branden Robinson]

Update of bug #64577 (project groff):

                  Status:             In Progress => Fixed                  
             Open/Closed:                    Open => Closed                 
         Planned Release:                    None => 1.24.0                 

    _______________________________________________________

Follow-up Comment #12:


commit c08b62fd2a812e4d390ebf65d6c7d337d512d2b4
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Mon Aug 21 06:35:49 2023 -0500

    [grops]: Fix Savannah #64577 (file diagnostics).
    
    * src/devices/grops/ps.cpp (ps_printer::define_encoding):
    * src/devices/grops/psrm.cpp (resource_manager::output_prolog)
      (resource_manager::supply_resource): Report more intelligible
      diagnostics when libgroff's `font::open_file()` returns a null pointer
      without setting `errno`.  The only way this can happen is if it
      rejected the file name for containing a slash, thus attempting
      directory traversal (recall Savannah #61424).  Also fix code style
      nits: explicitly `#include` errno.h C standard library header, align
      style of null pointer checks, and stop explicitly setting `errno` to
      zero before (indirectly) calling `fopen()`; we inspect `errno`'s value
      only under a documented error condition (a null stream pointer).  See
      errno(3).
    
    * NEWS: Add item; we should have mentioned this (and produced these
      better diagnostics) when 1.23.0 was released.  Distributors may find
      this change desirable to backport.
    
    Fixes <https://savannah.gnu.org/bugs/?64577>.  Thanks to Phil Chadwick
    for the report and Deri James for swiftly finding a correct workaround
    that suited the reporter.


However, as comment #11 notes, we may not be done here.

I'm starting to think a new environment variable, _GROFF_RESOURCE_PATH_, might
be necessary to handle the sorts of file system objects that _grops_ and
_gropdf_ (and _only_ these output drivers, as far as I know), sometimes
require.

Whether such a new environment variable should be treated as a counterpart to
output drivers' `-I` option as _GROFF_FONT_PATH_ already is for `-F` is an
open question.  I think we got into trouble in the first place by overloading
the semantics of `GROFF_FONT_PATH` (and `-F`) with "embeddable resources". 
Really, it's better that this overloading _not_ be done, because
`font::open_file()` is particularized to the needs of a device-independent
_troff_--the reading of device-specific description files (including those for
fonts).

What PostScript and PDF do with resources is a different kettle of fish, and
neither the formatter nor the output driver need to understand them, or not
much.  I recognize we do have some support for extracting bounding boxes/media
boxes and stuff like that.

So let us spin this into a new ticket.  Phil, do you want to remain CCed on
that?




    _______________________________________________________

Reply to this item at:

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

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