Version 8.1.1 or Acrobat Reader for Linux has been released. Reproducible: Always Steps to Reproduce:
*** Bug 192744 has been marked as a duplicate of this bug. ***
Created attachment 131152 [details] acroread-8.1.1.ebuild I tested this ebuild a little and it worked on my x86 gentoo box. I also checked about Firefox support and it was fine. This ebuild is just a testbed, so something could be wrong. If you find bugs, please report it. Without settings of "libgtkembedmoz.so Folder", a blank window whose title is "Beyond Adobe Reader" will be appeared every \ time. If it is your first time to run AdobeReader8, please close it by pushing close button of window. You can set "libgtkembedmoz.so Folder" in "Edit->Preferences->Internet->Select Browser". "libgtkembedmoz.so" was contained in the www-client/mozilla-firefox-2.0.6 package (not in mozilla-firefox-bin). Followings are known problems. 1. The list in ${QA_TEXTRELS} is maybe wrong, because "scanelf: rpath_security_checks()" warning is occurred when mergeing. 2. amd64 support has not been checked. 3. HelpViewer and Help (en_US) directories are not installed. Please enjoy it!
(In reply to comment #2) > 2. amd64 support has not been checked. amd64 need a 32 bits libgtkembedmoz.so I think mozilla-firefox-bin need to include this.
I installed this on amd64 and it works fine, I copied over the /usr/lib/mozilla-firefox to /usr/lib32/. from a 32bit chroot I had and that sorted the html stuff, but this isn't ideal really. Perhaps we could distribute a pre compiled lib during installation and stick in in /opt seen as this is a binary file anyhow?
Also they now support .tar.bz2 so we should probably use that.
Would XULRunner work instead of Firefox, so I don't need to install FireFox? It takes ages to compile. If XULRunner has the right files, that is smaller and no need to install FireFox.
I opened a bug about mozilla-firefox-bin missing libgtkembedmoz.so (#193789). acroread-8.1.1 should depend on mozilla-firefox-bin on amd64, I think. Hopefully, mozilla-firefox-bin receives a fix within short.
Ok; thanks for the info, people. I've placed a preliminary version 8.1.1 into portage. It's package masked for testing, I'd appreciate some testing. This installs the help viewer, for what it's worth. There's a whole bunch of new functionality in 8.1.1 so perhaps the help viewer is useful. The help viewer itself only seems to function when launched from Acrobat Reader's help menu - so I haven't made a wrapper for it or symlinked it to /usr/bin. I assumed mozilla-firefox-bin included the libgtkembedmoz.so, but I see aisomur says it's not there - I'll look into why that's the case. As Hanni suggests, I think distributing a 486 binary with it is probably the simplest solution (like the libcups binary provided when USE=cups is not specified, which I've left as a 386 binary).
> think distributing a 486 binary with it is probably the simplest solution (like > the libcups binary provided when USE=cups is not specified, which I've left as > a 386 binary). Couple of things, I tried just copying the lib from a folder into /opt/Acrobat and setting this as the location to look for the file, but that seemed insufficient, it may be that that library relies on other things in the mozilla-firefox folder, I currently am using the location in a chroot I use for building LiveCD's which is x86 so it works ok, hence we may need to stick a few additional files in there... Also I have noticed an oddity with Acroread. I run a dual head in KDE everything compiled with Xinerama when opening a pdf the window opens on one screen, but the document is scaled to fit both screens and it treats the document area as though it stretches across both my screens. This goes away if I resize the window to dual screen and then back to one screen, any ideas why anyone? I suspect this is upstream so will look there just wondering if I am on my own or other have experienced this as well.
(In reply to comment #9) > Also I have noticed an oddity with Acroread. I run a dual head in KDE > everything compiled with Xinerama when opening a pdf the window opens on one > screen, but the document is scaled to fit both screens and it treats the > document area as though it stretches across both my screens. This goes away if > I resize the window to dual screen and then back to one screen, any ideas why > anyone? I suspect this is upstream so will look there just wondering if I am on > my own or other have experienced this as well. Same here. By the way, does the 'Read out loud' option work for anyone? I have festival installed and fully functional. Kttsd seems to be able to use it without any problem, but I cannot get acroread to use it.
I've made a small update; this will configure /etc/gre.d so that acroread can find libgtkembedmoz.so without mucking around with preferences. Also, it'll use xulrunner to meet that dependency as an alternative to mozilla-firefox (either will do). amd64 still not sorted re. libttkembedmoz.so. re. dual head; I'm single head here, so can't test but it's likely to be an upstream issue, I think. re. Read Out Loud - it's all grey-ed out for me. I suspect it needs some library support, or hard-wires where it thinks the relevant configuration files should be so that will take some investigation.
I managed to get Read Out Loud to work - it needed gnome-speech, it seems.
(In reply to comment #12) > I managed to get Read Out Loud to work - it needed gnome-speech, it seems. > Installing gnome-speech did not make a difference for me. I have alsa-lib-1.0.15_rc2, alsa-oss-1.0.14 and festival-1.96_beta installed. Perhaps, I am missing something else?
I haven't worked out what the key factors are, but the complete set of actions I performed was: 1) Add USE="mbrola" to make.conf; and emerged speechd also added myself to the speech group 2) modprobe snd_pcm_oss (created /dev/dsp - only had alsa stuff before, no OSS emulation) 3) /etc/init.d/speechd start - at this point I could 'echo Hello > /dev/speech' (once logged in to a new shell to get the group membership!), but acroread still couldn't talk. 4) emerge gnome-speech at which point acroread showed the stuff in preferences for reading out loud, and I could activate it. Maybe not all of the stuff I did was strictly necessary...
On my amd64 system the libgtkembedmoz.so from: firefox-mozilla doesn't work, firefox-mozilla-bin doesn't have it, xulrunner-9999 doesn't haven't it. Tried the Debian libxul0d in i386 and amd64 which don't work. Finally, the xulrunner from http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/linux-i686/xulrunner-1.8.1.3.en-US.linux-i686.tar.gz does work. Maybe a binary ebuild for xulrunner 1.8.1.3 and a dependency from acroread-8.1.1?
can /opt/Adobe/Reader8/Reader/Cert/curl-ca-bundle.crt symlink to /etc/ssl/certs/ca-certificates.crt considered using? /opt/Adobe/Reader8/Reader/Patch/selinux_patch
Seems they released localized versions now, I tested with the german version and the current ebuild in portage by modifying: LINGUA_LIST="en:enu de:deu" Since I used the english version before I had to wipe the adobe related configuration in my ~/homedir, after that the reader was correctly localized.
@Timo - thanks for the heads-up. I checked stuff out, and currently released are German, French and Japanese, as of today. I'll get these added to the ebuild soon. @dragonheart - thanks for the comments. I hadn't thought of symlinking the Adobe-provided certs with existing system ones; I'll check that idea out. W.r.t. the selinux patch, I'll get advice from pebenito as to whether it is sensible to apply automatically. @eris - thanks for the info. Just to say I haven't forgotten about the libgtkembedmoz.so issue, still on the TODO list...
more languages added, for istance italian and spanish...what about unmasking?
(In reply to comment #19) > more languages added, for istance italian and spanish...what about unmasking? > I am still getting a lot of 100% CPU usage issue that is also affecting to other users in: http://blogs.adobe.com/acroread/2007/09/known_issues_with_adobe_reader_1.html (see comments) :-/
(In reply to comment #19) > more languages added, for istance italian and spanish...what about unmasking? > I think it's stable enough to put in as testing, but I went back to v7 due to the issues with dual head, so until that's fixed I think we have to stick with v7.
For me it doesnt work with firefox on amd64 regardles of whether you point the prefernces to a downloaded xulrunner for libgtkembedmoz or not, simply doesnt work but preliminary testing on x86 shows it working properly.
*acroread-8.1.1 (27 Sep 2007) 27 Sep 2007; Kevin F. Quinn <kevquinn@gentoo.org> +acroread-8.1.1.ebuild: New version - includes help viewer.
InCVS. Anything else -> a *new* bug
it's hardmasked and doesn't support linguas...
please reopen this bug, still hardmasked and no full linguas support
re-opening in order to...
...reassign. While I'm here, re #16: > considered using? > /opt/Adobe/Reader8/Reader/Patch/selinux_patch Response from Chris PeBenito - patch is unnecessary; all it does is file labelling which portage does for you anyway.
can we remove the dependency on seamonkey-bin for amd64? it's just one 32bit library, it may be included in an emul-* package or directly shipped with the ebuild...
(In reply to comment #29) > can we remove the dependency on seamonkey-bin for amd64? > it's just one 32bit library, it may be included in an emul-* package or > directly shipped with the ebuild... Currently seamonkey-bin is the only 32bit precompiled package providing the needed gtkembedmoz.so, in the future there will probably be a xulrunner-bin available as an alternative.
(In reply to comment #29) > can we remove the dependency on seamonkey-bin for amd64? > it's just one 32bit library, it may be included in an emul-* package or > directly shipped with the ebuild... > Please see bug #208633
Version 8.1.2 is out btw.
acroread-8.1.2 is in CVS now, closing this bug now. Big thanks to everyone involved! The amd64 dependencies will be updated as soon as a better solution and/or alternatives to seamonkey-bin emerge.
