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

URL: Summary: [PATCH] fix PDFPIC issue with determining size of pdfs containing images Project: GNU troff Submitted by: None Submitted on: Sun 19 Apr 2020 06:53:50 PM UTC Category: De

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

Follow-up Comment #1, bug #58206 (project groff): Unfortunately, the '-a' option to grep is not part of the POSIX standard for the utility so we can't rely on it being available in the runtime environment. Of course, 'pdfinfo' isn't standard at all, so there's probably some room to argue here.

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

Update of bug #58206 (project groff): Category: Device gropdf => Macro - others Status:None => Need Info ___ Follow-up Comment #2: While nowadays, grep(

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

Additional Item Attachment, bug #58206 (project groff): File name: angular-1280-800.pdf Size:279 KB ___ Reply to this item at:

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

Follow-up Comment #3, bug #58206 (project groff): I just attached the pdf i was trying to embed. This was mostly just to see if pdfpic was working. ___ Reply to this item at: __

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

Follow-up Comment #4, bug #58206 (project groff): Ok so a work around I used was to use tr's -d flag to remove the NULL sections from the output from pdfinfo. As far as I know this should be available to all systems. Another option is to use cat -v but I don't think that is POSIX complaint. Here

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

Update of bug #58206 (project groff): Status: Need Info => In Progress Assigned to:None => gbranden ___ Follow-up Comment #5: [comment #4 comment

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

Follow-up Comment #6, bug #58206 (project groff): I found a similar issue in the their issue tracker sadly it is still unresolved. https://gitlab.freedesktop.org/poppler/poppler/-/issues/776 The argument for supporting PDFPIC is to allow files contain pdfmark's pdfhref feature can also contain p

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

Follow-up Comment #7, bug #58206 (project groff): PDFPIC is not written by me, but I understand why it was written! The gropdf driver supports this:- \X’pdf: pdfpic file alignment width height line-length’ Place an image of the specified width containing the PDF drawing from file file of desired

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

Update of bug #58206 (project groff): Status: In Progress => None ___ Follow-up Comment #8: This isn't really in progress, but I don't promise I won't get back to it during the 1.22.3 RC cyc

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

Follow-up Comment #9, bug #58206 (project groff): [comment #8 comment #8:] > This isn't really in progress, but I don't promise I won't get back to it during the 1.22.3 RC cycle. I meant "1.23 RC cycle". I _can_ promise I won't get _anything_ done for the 1.22.3 RC cycle unless a DeLorean or po

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

Follow-up Comment #10, bug #58206 (project groff): Addressing bug #55107 will obviate the need for this particular shell pipeline at all (though tmac/pdfpic.tmac contains several other .sy calls which may still persist). But that's a more substantial change, and the patch proposed in comment #4 h

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

Follow-up Comment #11, bug #58206 (project groff): Also, as written, the sed command referenced in comment #10 will fail on at least Mac OS: its replacement pattern relies on "\n" to output a newline, and a mailing list thread on an unrelated topic (http://lists.gnu.org/r/groff/2021-10/msg00066.ht

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

Follow-up Comment #12, bug #58206 (project groff): Another awk solution, similar to the one linked in comment #10, was developed independently (http://lists.gnu.org/r/groff/2021-12/msg2.html). A patch is attached in file #52513. ___ Re

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

Update of bug #58206 (project groff): Status:None => Need Info ___ Follow-up Comment #13: The main barrier to proceeding with this is less the lack of portable scriptage to throw at it th

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

Update of bug #58206 (project groff): Status: Need Info => In Progress ___ Follow-up Comment #14: I'm mostly unblocked. The problem with the original problematic file (the "angular 1200x800" thi

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

Follow-up Comment #15, bug #58206 (project groff): I misread the output--the problem file from the original submission indeed contains UTF-16LE, not surprising at all given all the Windows systems in the world. And for those who were wondering, I've worked out a tempfile-free way to manipulate th

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

Update of bug #58206 (project groff): Status: In Progress => Fixed Open/Closed:Open => Closed Planned Release:None => 1.23.0

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

Follow-up Comment #17, bug #58206 (project groff): [comment #15 comment #15:] > I misread the output--the problem file from the original submission indeed contains UTF-16LE, not surprising at all given all the Windows systems in the world. Embarrassingly, I had it right the first time. A null (z

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

Follow-up Comment #18, bug #58206 (project groff): Bug #61324 was closed as a dup of this bug. ___ Reply to this item at: ___ Message sent via Savannah

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

Follow-up Comment #19, bug #58206 (project groff): [comment #11 comment #11:] > the sed command referenced in comment #10 will fail on at least > Mac OS: its replacement pattern relies on "\n" to output a newline, Comment 2 of bug #64061 exposes this as the dirty lie it is.

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

Follow-up Comment #20, bug #58206 (project groff): [comment #19 comment #19:] > [comment #11 comment #11:] > > the sed command referenced in comment #10 will fail on at least > Mac OS: its replacement pattern relies on "\n" to output a newline, > > Comment 2 of bug #64061 exposes this as the dir

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

Follow-up Comment #21, bug #58206 (project groff): Here is an illustration of "\n" working as an encoded newline as replacement text in macOS sed's 's' command. $ uname -a Darwin gcc104.fsffrance.org 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:20:05 PDT 2022; root:xnu-8020.140.49~2/RELEAS

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

Follow-up Comment #22, bug #58206 (project groff): And here's an example of it failing on an earlier version of macOS. (As you note, there's no way to glean the version of sed, but it's the stock one bundled with OS X 10.11.6.) $ uname -a Darwin Ignatius 15.6.0 Darwin Kernel Version 15.6.0: Thu

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

Follow-up Comment #23, bug #58206 (project groff): Aha. It sounds like I should break this issue out from the Solaris material (in "PROBLEMS") and cover it like gdiffmk. Thanks, Dave! ___ Reply to this item at:

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

Follow-up Comment #24, bug #58206 (project groff): [comment #23 comment #23:] > Aha. It sounds like I should break this issue out from the > Solaris material (in "PROBLEMS") and cover it like gdiffmk. This was done in [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=6ee42a18 commit 6ee42a1