Follow-up Comment #6, bug #64612 (project groff):
Hi Phil,
[comment #3 comment #3:]
> I think what you are saying is that the groff-specific font metric files
(e.g. "desc/TR") should remain where they have always been. Agreed -- they
are specific to groff, and there is no need to change the current system.
I agree with this statement, given its scope.
> The Type 1 fonts (.pfa, and .ps) can be anywhere, and frequently shared with
other applications.
I agree with this one too.
> The GROFF_INCLUDE_PATH is to be used to find the PostScript files when
needed (which I'm guessing is only when they need to be included in the output
of grops).
Deri is the author of _gropdf_, _groff_'s PDF output driver. It is written in
Perl. All of _groff_'s other output drivers are written in C++, and moreover
use some internal statically linked libraries to leverage code reuse.
> I'm a bit concerned by the statement "inserts the path to the system
installed versions into the download file" because the prohibition of paths in
the download file is precisely where this all started.
If there existed a system tool called "update-font-download" or similar that
_groff_ could rely upon to be run at appropriate times, and which kept a
"download" file at some reliable location on the file system, some/all of the
problems here would go away.
I reckon we'd trust such a file implicitly.
One of our problems, as I see it, is that we've relied upon such a file
without undertaking the work to manage it on a dynamically configured system
(meaning: one where PostScript fonts might come and go independently of
_groff_'s installation).
Ideally, there's be some common-practice location to find a "download" file
for PostScript/TrueType/OpenType fonts, and _grops_ and _gropdf_ would look
there by default. Maybe we'd support a _GROFF_FONT_DOWNLOAD_ environment
variable of appropriately bikeshedded name for overriding--and automated
testing at build time--this location, and then we could have done with it.
But that's not where we are now. We "manage" these "download" files in an
anemic fashion and search for them only in places that a user reasonably would
conclude we have declared proprietary to our programs. In my opinion this is
historical inertia. We do it this way because that's what James Clark
implemented in 1990/1991, possibly before anyone else in the Unix world was
generating PostScript files with embedded resources. (I see that Ghostscript
dates back to 1988, but I know nothing of its early history, and little else
of it besides, apart from some interesting licensing history.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64612>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
