bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #58206] [PATCH] fix PDFPIC issue with determining size of pdfs cont


From: Ingo Schwarze
Subject: [bug #58206] [PATCH] fix PDFPIC issue with determining size of pdfs containing images
Date: Sun, 19 Apr 2020 23:18:54 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:75.0) Gecko/20100101 Firefox/75.0

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]