Bug#1068307: Bug#1068303: epsffit(1): no %%BoundingBox due comment into the EPS file
Ian Jackson writes ("Bug#1068303: epsffit(1): no %%BoundingBox due comment into
the EPS file"):
> So, this information should either be encoded in a DSC comment (I
> think %%Creator would be right), or moved to some place where the DSC
> spec allows "PostScript code".
So specifically, I think for example that changing
%Produced by poppler pdftops version: 22.12.0 (http://poppler.freedesktop.org)
to
%%Creator: poppler pdftops version: 22.12.0 (http://poppler.freedesktop.org)
would be correct. (Assuming that there isn't already a %%Creator - I
haven't checked.)
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1068303: epsffit(1): no %%BoundingBox due comment into the EPS file
Control: clone -1 -2
Control: reassign -2 poppler-utils
Control: retitle -2 "Produced by poppler" header comment violates DSC spec
Control: severity -1 wishlist
Control: retitle -1 Compatibility with nonconforming poppler-produced files
Control: clone -1 -3
Control: retitle -3
Control: severity -3 wishlist
Hi, Poppler maintainers. A psutils user reported a problem which,
having read the spec, I think is due to a bug in poppler-utils.
Please see the original bug #1068303 for full context.
Niccolo Rigacci writes ("Bug#1068303: epsffit(1): no %%BoundingBox due comment
into the EPS file"):
> I have some scripts to manipulate heterogeneous PDF files, rotating
> and fitting them to a fixed size. The scripts are something like this:
Thanks for the report.
> pdftops -f 1 -l 1 -eps document.pdf document.eps
> epsffit -m -c 7 4 575 825 document.eps document-fit.eps
...
> The problem turned out to be into the header created by the pdftops
> command:
>
> %!PS-Adobe-3.0 EPSF-3.0
> %Produced by poppler pdftops version: 22.12.0 (http://poppler.freedesktop.org)
> %%LanguageLevel: 2
I think that %-comment is wrong. The relevant specification is the
PostScript Language Document Structuring Conventions. I found a copy
here:
https://web.mit.edu/PostScript/Adobe/Documents/5001.DSC_Spec.pdf
My reading of that specification is that normal PostScript comments
are not permitted there. See the diagram on p19 of that pdf. And in
section 4, 4.1 (page 22), the header section "consists of DSC comments
only".
So, this information should either be encoded in a DSC comment (I
think %%Creator would be right), or moved to some place where the DSC
spec allows "PostScript code".
> I'm not sure if the comment "%Produced by" is compliant to the EPS
> format. If it is not, we shuld blame the pdftops(1) command, provided
> by the poppler-utils package.
Yes.
I have cloned/retitled this bug accordingly. Would you please tell
the BTS the affected version of poppler-utils? (Or tell us, and we'll
set the BTS tags appropriately.)
Howeveer, I think it would be good for psutils to be able handle these
files. I don't have effort to work on a patch myself, but would be
happy to review and (if appropriate) accept a patch to tolerate this
situation, perhaps with a warning.
Thanks, all.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#1068303: epsffit(1): no %%BoundingBox due comment into the EPS file
Package: psutils Version: 1.17.dfsg-4 Severity: important Dear Maintainer, I have some scripts to manipulate heterogeneous PDF files, rotating and fitting them to a fixed size. The scripts are something like this: pdftops -f 1 -l 1 -eps document.pdf document.eps epsffit -m -c 7 4 575 825 document.eps document-fit.eps The commands work fine in Debian 6, but they fail in Debian 12 with the following error: epsffit: no %%BoundingBox: The problem turned out to be into the header created by the pdftops command: %!PS-Adobe-3.0 EPSF-3.0 %Produced by poppler pdftops version: 22.12.0 (http://poppler.freedesktop.org) %%LanguageLevel: 2 %%DocumentSuppliedResources: (atend) %%BoundingBox: 0 0 2384 1684 ... The second line "%Produced by poppler..." confuses the epsffit command, which is unable to find the %%BoundingBox line. If I manually edit the document.eps removing the "%Produced by" line, then epsffit works as expected. Another workaround is to add another percent sign to the line (like "%%Produced by..."). I'm not sure if the comment "%Produced by" is compliant to the EPS format. If it is not, we shuld blame the pdftops(1) command, provided by the poppler-utils package. -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages psutils depends on: ii libc6 2.36-9+deb12u3 ii libpaper1 1.1.29 Versions of packages psutils recommends: ii ghostscript 10.0.0~dfsg-11+deb12u2 psutils suggests no packages. -- no debconf information
