I've got some pdfs that evince used to work, but with 0.5.2 doesnt.
Created attachment 86541 [details] Example of PDF
I can confirm this bug too. Evince shows nothing but a "Loading" page, while eating about 90% CPU for about a minute. Then shows a poor quality rendering of the document.
I can reproduce it's slow and the quality suboptimal, but comment #1 suggest it doesn't work at all (?)
(In reply to comment #3) > I can reproduce it's slow and the quality suboptimal, but comment #1 suggest it > doesn't work at all (?) > No, its the loading thing... like you :-)
I see suboptimal display, for sure, but no loading time issues here. The "LOADING" screen barely flashes before the PDF is loaded. I'm working on getting 0.5.3 into portage, but there are poppler issues. That might fix the problem.
OK, I've got a really dumb question here, which may have a part of solution of the problem. I can reproduce the bug here, I've got evince built with USE="-dbus -nautilus" and somehow I get the idea that it could be caused by "-dbus", so was dbus set or not: 1. for those, who can reproduce bug 2. for those who can't ? Also, I'm getting some strange effects with postscript files (examples instaled with ghostscript). When I open those by `evince <filename with path>` in most cases they open fine, until I try to open a file from different directory, cause then when I reload that file evince gets stuck at "Loading" screen. I've wrote a small postscript file that gets stuck at that screen no matter if it's open with full path or not (gsx displays it fine). Could those of you who got the problem with that pdf check this issue too ? One more thing, I've got a strange issue with a pdf with japanese text. Ghostscript is installed with cjk flag, so CMaps are here, xpdf (portage tree /poppler version) needs only one file more - Adobe-Japan1.cidToUnicode which I got from xpdf site. IIRC one of the previous versions also read xpdfrc file and could display this pdf correctly, in fact unless my memory has failed me, around Easter evince was working correctly. However, now (if I correctly understood strace output) xpdfrc does not get read at all. Is this a poppler bug, an evince bug, a gentoo bug or am I missing something, cause xpdf still works. app-text/evince-0.5.2-r1 app-text/poppler-0.5.1-r1
Created attachment 87008 [details] The mentioned japanese pdf Needed lines in xpdfrc are: cidToUnicode Adobe-Japan1 //path to//Adobe-Japan1.cidToUnicode cMapDir Adobe-Japan1 /usr/share/ghostscript/Resource/CMap
Created attachment 87009 [details] my postscipt file This file is very simple, cause I don't realy know postscript, it's just few lines I wrote when I was trying to illustrate a rather elementary geometry problem (secondary school at most) (it's not finished yet)
app-text/evince-0.5.2-r1 +dbus -debug -djvu -doc -dvi +nautilus -t1lib +tiff and i can reproduce the bug
with fig1.ps i've the same problem... but i only get loading... by the way, i've some pdfs that instead of a gray box with letters written on it, i get a black box with black letters :-/ Printing has no problem though...
As a sidenote, while checking a few things about evince, I noticed something "funny" about poppler-bindings-0.5.1(-r1) ebuild. Namely, in src_install it does `dolib.a poppler/libpoppler-cairo.la`. What is so "funny" about it you ask ? Well, that file contains lines "library_names='' old_library='libpoppler-cairo.a'" but in poppler sources in poppler/Makefile.am there are lines "poppler_cairo = libpoppler-cairo.la noinst_LTLIBRARIES = $(poppler_cairo)" so libpoppler-cairo.a IS NOT installed. So, did somebody missed that, cause without this file libpoppler-cairo.la is kind of pointless.
Maybe I should mention that this bug report comes from a machine where I'm only a normal user, so writing to /etc/xpdfrc and stuff is a no go. But I managed to find a "hack" solution to japanese pdf problem. In evince sources, in pdf/ev-poppler.cc if I add globalParams = new GlobalParams(""); line to pdf_document_init (PdfDocument *pdf_document) and add #include <GlobalParams.h> at poppler include block of that file then pdf is displayed correctly (with a good .xpdfrc) . Do you think it counts as an upstream evince bug ?
BTW. as far as I can tell evince 0.5.3 does NOT solve any of my two problems (ps and japanese) , and neither does it solve the loading problem (this bug).
Created attachment 87270 [details] the mentioned file OK, one more bug (maybe I should register at evince bugzilla ?), this time for dvi files. A file, that I created myself is displayed correctly in xdvi, in evince, however many characters are missing (see attached file).
Definitely point that one upstream. None of us are actually evince or poppler devs. (however, a new version of poppler/evince is about to be released, so you might want to wait for that...)
Okay, evince 0.5.3 is in the tree. Could people in this bug with problems try again with that?
(In reply to comment #16) > Okay, evince 0.5.3 is in the tree. Could people in this bug with problems try > again with that? > The loading problem has gone, but now the text isn't suboptimal, it's worse, it's full of dots... :/ oh, and evince crashes when i close window. (using problematic pdfs)
Yeah, I can see that too. Definitely report both of them upstream.
And post the bug URL here when you do, please.
How about that part that is definitly not upstream, namely the problem I mentioned in comment #11 ?
Could you move it to a different bug, so that we don't lose track of it (like I already did once)?
Just installed 0.5.3 and I'm having the problems described in #17. The dvi file crashes the application when loading.
There's a new version of poppler on the way. Upstream managed to break some things...
I checked the build and package for issues regarding the poppler-cairo.la. The latest stable version still creates a pkg-config file, but the .la is no longer created. I think we could even remove the emake sections of the ebuild. As for the document, this really needs to be checked upstream (I've sent them my share of pdfs to fix :) ) Thanks
