Follow-up Comment #5, bug #67295 (group groff): At 2025-07-24T15:58:20-0400, Deri James wrote: > I notice that gropdf does emit a warning:- > > gropdf: warning: Unable to parse font 'Symbol-Slanted' for subsetting
Yes. Apart from wanting to recast the language slightly per bug #66519,
I have no issue with this warning. It's certainly more
user-intelligible than the ones from Perl itself.
> The perl messages can be turned off if you think that is a good idea.
I don't. To me, they seem analogous to compiler warnings in C/C++.
> I wondered what grops would do if I "hand edited" freeeuro.pfa
> (deleted a single character).
>
> [derij@pip devps (master)]$ echo "\(Eu\(eu"|test-groff | okular -
> (libspectre) ghostscript reports: undefined -21
> (libspectre) ghostscript reports: undefined -21
> (libspectre) ghostscript reports: undefined -21
> (libspectre) ghostscript reports: undefined -21
>
> It appears grops did not recognise it was an invalid font at all, just
> stuffed it in the output, giving okular/ghostscript some indigestion,
> so 1 up for gropdf. :-)
Indeed! But grops doesn't try to do subsetting, either.
> I think we have have to accept that if your font is not valid, you
> will receive unusual errors. To fully validate a type 1 font would
> take an awful lot of code for both grops and gropdf.
I agree. My principle is "if you don't interpret it, you don't have to
validate it"--but that's a biconditional.
One of the points Heirloom Doctools partisans deploys against _groff_ is
that Heirloom can parse OTF and TTF fonts for itself. And I concede
that that's a desirable feature. However I think it would be preferable
to leverage the work of existing libraries to perform this work. I feel
sure they must exist.
> However, I think gropdf could do better, at least look for a valid
> font header, and if what appears after it is invalid, rely on the
> message above that gropdf can't use it.
That seems easily good enough for several nines of the scenarios I have
in mind. I think users are more likely to put an invalid font file in
one of their "download" files by accident, by clobbering them with the
wrong file type or with a wayward shell command that truncates them,
than to attempt subtle trickery that _gropdf_ won't detect.
> At least gropdf tells them which font is causing the issue, unlike
> grops/okular.
Yes. Diagnostic messages should steer the user to the root cause of the
problem, or the best guess in the neighborhood if the former is
impossible.
> I will commit a suitable change.
Looking forward!
Regards,
Branden
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67295>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
