A new version of Xpdf has been released on 2007-feb-27, it has been taken care of a lot of bugs, and finally fullscreen does work. A new ebuild would be appreciated. Reproducible: Always
The problem is our current xpdf has poppler as basis. And I dont have a new poppler patch nor a new poppler. I guess I will wait for a new poppler and then look into making the poppler patch work with the new xpdf. If you got a better suggestion feel free to share.
There is a new poppler coming out Real Soon Now (tm) that has all those fixes in it.
hmh, the new poppler does not compile with our xpdf. Neither with anything else atm :( Probably we should return to the old xpdf ebuild and just use upstream sources instead of the poppler workaround.
Oooh, still no progress yet ? So long time passed..
xpdf compiles with new poppler now after patching so all ok
> xpdf compiles with new poppler now after patching so all ok > Is there any other problem with the new xpdf? It isn't in portage yet.(In reply to comment #5)
No idea why's this bug closed as FIXED, nothing has been bumped. Reopen.
I added a working ebuild for xpdf-3.02 in http://bugs.gentoo.org/show_bug.cgi?id=139805 It doesn't use poppler or include any patch but work for me.
(In reply to comment #5) > xpdf compiles with new poppler now after patching so all ok > So is the current xpdf-3.01-r8 the same as xpdf-3.02 when it is compiled with the new poppler? Shouldn't there be a version renaming to avoid confusion? Or am I totally off, and xpdf-3.02 is still not in prortage?
(In reply to comment #9) > (In reply to comment #5) > > xpdf compiles with new poppler now after patching so all ok > > > > So is the current xpdf-3.01-r8 the same as xpdf-3.02 when it is compiled with > the new poppler? > > Shouldn't there be a version renaming to avoid confusion? Or am I totally off, > and xpdf-3.02 is still not in prortage? > I don't think so, because, as in bug 139805 http://bugs.gentoo.org/show_bug.cgi?id=139805 xpdf-3.01-r8 doesn't show correctly some graphics, when xpdf-3.02 show them without problem. A test file: http://hdr.undp.org/en/media/hdr05_fr_chapter_41.pdf
Sorry if I am bugging (pun intended :-)), but what is the problem then? I tried to make a xpdf-poppler ebuild, but I couldn't get it to compile with it. Is there any light at the end of the tunnel? regards, Thomas
Why is the reason to use poppler instead of the original sources? Especially, does the poppler patch add any function or remove any bug to xpdf? If it is not the case, why not to use the original sources?
(In reply to comment #11) >Why is the reason to use poppler instead of the original sources? > I guess it is cleaner, since ghostscript (so generally printing) draws poppler into your system anyway, and in that way you don't have to compile redundant code :)
Once more I tried to get xpdf to compile with poppler, I had some initial success, however xpdf seems to call the function 'getContinuousView' of 'globalParams' which is not present in the current poppler-0.6.2 declaration of GlobalParams ( I checked for possible name change, but the function is just absent. :( ) > PDFCore.cc: In constructor 'PDFCore::PDFCore(SplashColorMode, int, GBool, Guchar*, GBool)': >PDFCore.cc:87: error: 'class GlobalParams' has no member named 'getContinuousView' One solution would be to patch poppler against the current xpdf version, or just drop the poppler compiling. Stefan Schweizer comment #5 said he got it working, could you please provide more information on this? regards, Thomas
(In reply to comment #13) > (In reply to comment #11) > >Why is the reason to use poppler instead of the original sources? > > > > I guess it is cleaner, since ghostscript (so generally printing) draws poppler > into your system anyway, and in that way you don't have to compile redundant > code :) > I don't care about this because I can almost always do something else when portage is compiling. Otherwise, I can stop portage and restart it later. But it seems that it make the life easier for maintainers: according to http://www.gentoo.org/news/en/gwn/20060206-newsletter.xml, it greatly simplifies the security process. I am not convinced about this because I done a little search and found more security reports about poppler as about xpdf. But no matter. Don't stress for me, my system can live with my custom xpdf ebuild on comment #8. And thank you all for the work.
Oky dok, I got it now! There are still two problems however, first 'GlobalParams' is redundant (which means I have it in xpdf and in poppler) which kind of defeats the purpose, but the xpdf version has about 1,100 lines more code, so I guess we need to patch poppler?! the second problem is also about poppler, in 'goo/gfiles.h' it checks for 'HAVE_DIRENT_H' a macro which would be set by 'configure' but it isn't set at compile time of xpdf, thus it never passes this check and thus a compile error occurs because a header file is missing. I don't know how to fix this, besides a very ugly hack, where I just insert the header in gfiles.h by hand :p Any suggestions? regards, Thomas
Created attachment 136116 [details] app-text/xpdf-3.02 ebuild (uses poppler) This is the ebuild which works with poppler :)
Created attachment 136117 [details] xpdf-3.02-poppler source package xpdf-3.02-poppler source package, you will need this to put in your 'distfiles/' folder, since I don't have any upload stream yet.
I got it! :) Please test it to the max, and you will need the poppler-0.6.2-r1 ebuild with the patch I created, have a look here http://bugs.gentoo.org/show_bug.cgi?id=199398
Created attachment 136120 [details] xpdf-3.02-poppler source package (updated) I found a bug in the old sources, which wouldn't let you print to PS file, sorry.
*** Bug 199398 has been marked as a duplicate of this bug. ***
Created attachment 136222 [details] xpdf-3.02-poppler source package (works without patched poppler) I decided that for now, the problem of a little redundant code is not as bad as a "gentoo-only" patched poopler, which could have security issues which only gentoo would have to keep track, so this package works without a patched poppler, meanwhile I will try to get the patch upstream in poppler. For the xpdf-poppler uses nothing changes, and he won't notice :) regards, Thomas
Created attachment 136223 [details] app-text/xpdf-3.02 ebuild (updated) This ebuild is not anymore dependant on a patched poppler :)
This is now in the tree. We need this stable asap because the old version is broken on the arches in CC
x86 done
I'll un-cc arches and re-add them to bug 196735. Since this is holding back the Poppler GLSA, we need a fast reaction.
Stable for HPPA.
ppc stable
Sparc stable. Didn't quite realize there were two bugs asking for the same thing. Or does this bug ask for something different than bug #196735 does? It also asks for stablization for xpdf-3.02.
amd64 stable for xpdf 3.02
seems i forgot the checkbox "Remove CC"
Readding all security-unsupported arches since bug 196735 is now closed.
10:33:51 <+CIA-23> vapier * gentoo-x86/app-text/xpdf/xpdf-3.02-r1.ebuild: 10:33:51 <+CIA-23> arm/sh stable
Closing wrt http://www.gentoo.org/news/20080210-mips-experimental-arch.xml
