Created attachment 112384 [details] Statement as PDF File hang up with rendering completed printing with Okular I already filed a bug at bugs.kde.org. The guys there said it's a problem with poppler and I should file a bug here. The complete history of the bug can be seen at: https://bugs.kde.org/show_bug.cgi?id=342548. I did -> pdftops KA_20141208-1_public.pdf Syntax Warning: FoFiType1::parse a line has more than 255 characters, we don't support this This warning appears about 100 to 150 times. The ".ps"-file has ben created. After entering -> gs KA_20141208-1_public.ps a window came up, flashed 1 second and then disappeared. The terminal output was: GPL Ghostscript 9.07 (2013-02-14) Copyright (C) 2012 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading NimbusSanL-Bold font from /usr/share/ghostscript/9.06/Resource/Font/NimbusSanL-Bold... 3461368 2075877 23109360 20842461 1 done. Error: /undefined in e657865630ad9d66f633b846a989b9974b0179fc6cc445bc1325eb8f274dd24a5 Operand stack: --dict:8/12(L)-- --nostringval-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1894 1 3 %oparray_pop 1893 1 3 %oparray_pop 1877 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1159/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)-- --dict:69/75(L)-- Current allocation mode is local Current file position is 4306645 GPL Ghostscript 9.07: Unrecoverable error, exit code 1 (Please be patient, english is not my first language)
I'm currently encountering the same bug with libpoppler 0.41 on Ubuntu 16.04. As with Peter's document, it's an accounting statement file as well in my case. All poppler-based tools seem to fail, even pdftotext. This effectively makes the affected PDFs unprintable with a standard Linux system. This problem had also been reported to Debian in 2013, however the resulting Bug report got somehow messed up and later contained references to different actual bugs. So don't be confused by its "fixed" state, this concrete problem mentioned here isn't: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698456 However, some analysis was done in this report: > From: Luc Maisonobe <luc@spaceroots.org> > To: 698456@bugs.debian.org > Subject: further investigation > Date: Sat, 19 Jan 2013 19:23:24 +0100 > I have continued debugging the problem. It appears it is really linked > to loading the LCL1Medium type1 font which is embedded into the file (it > is object 32 in the file I transformed with qpdf). > > The analysis of the font starts correctly (parsing header > %!PS-AdobeFont-1.0: LCL1Medium, ignoring a few parameters like /Notice, > /FullName, /FamilyName, ... extracting /FontName, recognizing /Encoding > 256 array , ignoring a suite of PostScript commands anf recognizing a > series of dup commands like dup 32 /space put, dup 33 /exclam put ... > > The problem occurs just after the current dict is closed by the > currentdict end instruction. The next instruction is currentfile eexec > which is followed by a large binary blob, which itself is followed by 8 > lines composed of 64 characters '0' and an end of line marker (\r), > followed by a cleartomark line. The binary blob is parsed as if it were > composed of ASCII lines, and of course most of the lines exceed the 255 > characters length. In fact, as soon as the PostScript instruction eexec > is encountered on currentfile (i.e. when currentfile eexec is detected > on a line), the parser should not look for end of lines directly > anymore, but look if the following blob is an encrypted binary. In this > case, it should probably decrypt it. The encryption/decryption is > described in the Adobe Type 1 Font format book, at chapter 7 (I have > found this book online using a simple web search). > > So as a summary, the problem in the file I provided is due to a font > loading which parses encrypted characters as if they were not encrypted, > which then confuses the line breaks algorithm.
Ok, a further test reveals that while utils like pdftotext also output the mentioned error message, they still produce correctly looking output files. pdftops however actually generates corrupted PostScript files, or at least PostScript files which cannot be processed by GhostScript.
xpdf 3.04 also emits the mentioned error message, but is able to display the PDF nevertheless. I currently have not access to an xpdf-based pdftops, so I cannot check if this would generate a valid resulting PostScript file.
(In reply to Gunter Ohrner from comment #3) > xpdf 3.04 also emits the mentioned error message, but is able to display the > PDF nevertheless. > > I currently have not access to an xpdf-based pdftops, so I cannot check if > this would generate a valid resulting PostScript file. I have an old binary: :; XPDFtops -v pdftops version 3.03 Copyright 1996-2011 Glyph & Cog, LLC that works with other pdf files, but gets a SEGV with this one. Running mutool on that pdf says: warning: line feed missing after stream begin marker (41 0 R) The mutool clean output doesn't do any better.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/196.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.