Update of bug #58206 (project groff): Category: Device gropdf => Macro - others Status: None => Need Info
_______________________________________________________ Follow-up Comment #2: While nowadays, grep(1) -a tends to be universally available on all Linux and BSD systems, notable systems that do not support it include Illumos and Oracle Solaris (even the newest version 11.3). So Branden's remark about portability is not a theoretical concern. While Illumos and Solaris don't appear to ship groff by default, using groff there doesn't seem uncommon, so i'd consider them relevant target platforms, and the patch seems likely to totally break pdfpic.tmac on these platforms. The Solaris versions of grep seem to simply fail on binary files; when called with -F, they seem to simply pass through non-printable characters, but we can't use -F here because '*' is needed. The Solaris manual page does not mention any way to handle binary files. The normal way to include images into roff(7) files is to convert them to eps format and then use the .PSPIC macro. Using the .PDFPIC macro looks like a bad idea in the first place. It is highly insecure because it makes copious use auf the .sy request. Also, it is almost undocumented: all i managed to find so far is a passing mention in groff_tmac(7), which is riddled with very confusing typos - it talks about defining PSPIC, and about PSDIF options, neither of which make sense. The info(1) documentation doesn't seem to mention .PDFPIC it at all. I'm wondering though how it can happen that the *output* from pdfinfo(1) contains non-printable characters... Maybe this is a bug in pdfinfo(1), not in groff? Can you show the PDF file that triggered the problem for you? _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58206> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/