Bug 574964
| Summary: | Get "Error: Illegal entry in bfrange block in ToUnicode CMap" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | rgb | ||||||
| Component: | poppler | Assignee: | Marek Kašík <mkasik> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 12 | CC: | ian.cullen2308, malocascio, mkasik, rdieter, robatino, vanamali | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | poppler-0.12.4-4.fc12 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-08-11 07:28:57 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
I have the same problem. My procedure is similar. 1. Run latex on source (twice) 2. Run dvipdf on dvi file 3. Run evince on pdf file (and get the many errors) I am running evince-2.28.2-1.fc12 (x86_64) as well. I also have this problem, but don't think it is with evince. The same thing happens if you use xpdf. The offending pdf is quite a large document with many internal links, and made with 1. latex file.tex 2. bibtex file 3. latex file.tex (x2) 4. dvips file.dvi 5. ps2pdf file.ps If I make a very simple pdf with no internal links, I don't get the errors printed. The person on this thread seems very confident that it is a problem with ghostscript, however the thread is from 2008. http://www.ntg.nl/pipermail/ntg-context/2008/030785.html I currently have texlive-texmf-errata-dvips-2007-7.fc12.noarch texlive-dvips-2007-47.fc12.x86_64 texlive-texmf-dvips-2007-34.fc12.noarch ghostscript-8.71-4.fc12.x86_64 xpdf-3.02-15.fc12.x86_64 I'm seeing this with xpdf and evince in F13, with PDF files generated by ps2pdf (from a .ps file generated by Firefox). When it happens in xpdf, there is a long hang before I get the prompt back, and with evince there isn't. In x86_64 Rawhide, I see this in xpdf, but not evince. x86_64 Rawhide: xpdf-3.02-15.fc13.x86_64 evince-2.31.3-1.fc14.x86_64 x86_64 F13: xpdf-3.02-15.fc13.x86_64 evince-2.30.1-2.fc13.x86_64 I filed bug 605159 against xpdf in Rawhide (since in Rawhide it no longer affects evince). Hi, the problem is that poppler assumes that ToUnicode CMaps contains only 2-digit values <##> but there can be 4-digit values <####> too. Upstream already fixed this in poppler-0.13.2. I've committed the patch to F-12 and F-13. Regards Marek poppler-0.12.4-4.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/poppler-0.12.4-4.fc12 poppler-0.12.4-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/poppler-0.12.4-5.fc13 The upstream bug can be found here: https://bugs.freedesktop.org/show_bug.cgi?id=27728 poppler-0.12.4-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. poppler-0.12.4-4.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. I can confirm that that update fixes it on my system. The error messages are no longer printed using the same PDF file I used before. Thanks (In reply to comment #12) > I can confirm that that update fixes it on my system. The error messages are no > longer printed using the same PDF file I used before. In my case poppler-0.12.4-5.fc13.x86_64 has _NOT_ fixed the bug on my system (fc13 with all the latest updates installed): poppler-glib-0.12.4-5.fc13.x86_64 poppler-0.12.4-5.fc13.x86_64 poppler-qt4-0.12.4-5.fc13.x86_64 poppler-utils-0.12.4-5.fc13.x86_64 poppler-data-0.4.2-1.fc13.noarch --vv Hi Vanamali, could you attach the PDF you have problem with? Regards Marek Created attachment 441666 [details]
LaTeX --> dvips --> ps2pdf14
PDF file that elicits the error ""Error: Illegal entry in bfrange block in ToUnicode CMap" despite the latest poppler updates
poppler-glib-0.12.4-5.fc13.x86_64
poppler-0.12.4-5.fc13.x86_64
poppler-qt4-0.12.4-5.fc13.x86_64
poppler-utils-0.12.4-5.fc13.x86_64
poppler-data-0.4.2-1.fc13.noarch
Hi Vanamali, unfortunately, I can not reproduce the problem you have. Which version of evince do you have? What does "ldd /usr/lib64/evince/2/backends/libpdfdocument.so | grep poppler" say? Marek Hi Marek,
> unfortunately, I can not reproduce the problem you have.
> Which version of evince do you have? What does "ldd
> /usr/lib64/evince/2/backends/libpdfdocument.so | grep poppler" say?
>
> Marek
evince-libs-2.30.3-1.fc13.x86_64
evince-nautilus-2.30.3-1.fc13.x86_64
evince-2.30.3-1.fc13.x86_64
The error message comes when I use xpdf and not evince. The version of xpdf I have is xpdf-3.02-15.fc13.x86_64
ldd /usr/lib64/evince/2/backends/libpdfdocument.so | grep poppler
libpoppler-glib.so.4 => /usr/lib64/libpoppler-glib.so.4 (0x00007f9b37239000)
libpoppler.so.5 => /usr/lib64/libpoppler.so.5 (0x00007f9b33710000)
--vv
Hi Vanamali, Xpdf doesn't use poppler. Actually, poppler is based on Xpdf and the problem is not fixed in Xpdf yet. You can file a new bug for Xpdf. Regards Marek I already filed a bug against xpdf. See comment 5. |
Created attachment 401142 [details] The offending PDF file (noting that this doesn't happen for all of them) Description of problem: Working on textbook written with latex, with embedded xfig-derived eps figures. Every time I rebuild or start evince on the resulting PDF (which otherwise appears perfect) I get a few hundred: Error: Illegal entry in bfrange block in ToUnicode CMap error messages. This is a fairly recent development, as I've used evince and latex together for a long time now as parts of an integrated development cycle (jove, make, latex, dvips, ps2pdf, xfig, fig2dev, evince). The messages to stderr overwrite my jove text window, making it a very annoying and pernicious problem to the development cycle (I have to suspend and resume to restore the screen after every build). Note that it appears present in both i386 and x86_64 (I've got two systems side by side with F12 and it is on both of them). It was not (and is not) present with the same sources and build under F11 (I have an F11 system across the room and just tested it). Version-Release number of selected component (if applicable): evince 2.28.2-1.fc12 (x86_64 and i386) dvips ps2pdf How reproducible: Two independent systems, two architectures -- pretty reproduciblel. Steps to Reproduce: 1. Run latex on source (twice) 2. Run dvips on dvi file 3. Run ps2pdf on ps file 4. Run evince on pdf file (and get the many errors) Actual results: Many error messages written to stderr Expected results: No error messages Additional info: Searching online, it may be that this bug is associated with the indexing of the PDF file, associated with its searchability. The bug itself could easily be upstream in the conversion process that produces the pdf. But it is annoying and should not be there however it appears.