Your message dated Sun, 17 Apr 2016 02:15:55 -0500
with message-id <[email protected]>
and subject line Re: Bug#698456: libpoppler19: renders parts of PDF with large
black squares and reports parse error
has caused the Debian Bug report #698456,
regarding libpoppler19: renders parts of PDF with large black squares and
reports parse error
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
698456: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698456
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libpoppler19
Version: 0.18.4-4
Severity: important
Some PDF files are not rendered correctly. The overall layout is good but some
text is missing and very large black squares (which extend past the normal
position of the text, sometimes up to a large part of the page) are displayed.
When evince (which uses libpoppler) is launched from the command line, a lot of
errors are displayed which read:
Error: FoFiType1::parse a line has more than 255 characters, we don't support
this
It seems to be related to a font enconding, despite the font seems to use a
classical /Encoding /WinAnsiEncoding. Other PDF readers not based on libpoppler
display the text correctly (like Adobe reader, mupdf, Apache PDFBox, gv or the
viewer
integrated into emacs which probably uses gs too). The free software readers
may not represent the font properly, though. This leads me to think that the
file syntax is probably correct so the error triggered at the level of the
parse method in FoFiType1 class may in fact correspond to an earlier error. I
tried to debug the read, and it seemed to me what was parsed at this level was
really not a font encoding but rather some postscript-like code.
Unfortunately, as this error is triggered by files provided by a bank, I cannot
join the original files by themselves, which contains confidential
informations. So I used qpdf to convert the deflate streams in one of these
files, I edited these streams manually to remove the sensitive information, and
created a test file that reproduces the bug. This file stills triggers the bug
(i.e it it displayed with large black squares in evince and it shows up the
parse error in the console), and can still be displayed by the other free
software readers (mupdf, emacs, gv, Apache PDFBox). However, the edited file
cannot be displayed anymore by Adobe reader because as I edited it, the
embedded
signatures do not match the content anymore, so Adobe reader consider the file
is
corrupted (which is right for the edited file).
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libpoppler19 depends on:
ii libc6 2.13-37
ii libfontconfig1 2.9.0-7.1
ii libfreetype6 2.4.9-1.1
ii libjpeg8 8d-1
ii liblcms1 1.19.dfsg-1.2
ii libopenjpeg2 1.3+dfsg-4.6
ii libpng12-0 1.2.49-1
ii libstdc++6 4.7.2-5
ii libtiff4 3.9.6-10
ii multiarch-support 2.13-37
Versions of packages libpoppler19 recommends:
ii poppler-data 0.4.5-10
libpoppler19 suggests no packages.
edited-file-showing-black-squares.pdf
Description: Adobe PDF document
--- End Message ---
--- Begin Message ---
This was fixed in cairo https://bugs.freedesktop.org/show_bug.cgi?id=53841
with patch https://cgit.freedesktop.org/cairo/commit/?id=ee7f5607
--- End Message ---
