Chromium supports inline viewing of PDF files without Adobe Acrobat plugin. All we need to do is add media-libs/pdflib as dependency, and create a soft-link from /usr/lib/libpdf.so to /usr/lib/chromium-browser/libpdf.so Afterwards, the inline PDF support can be enabled in Chromium on about:plugins Reproducible: Always
~amd64, chromium-8.0.552.0, "missing plugin"
(In reply to comment #1) > ~amd64, chromium-8.0.552.0, "missing plugin" > Same result on 9.0.562.0 (63627). I don't think the libpdf.so from pdflib is what Chromium needs; as I recall, Chrome ships with a closed-source binary from Adobe.
I attempted this fix on my install and simply receive, "missing plugin," when trying to view a PDF in chromium. Is there something else required to make this functionality work?
Please re-open just in case we need to do something more to make it work. Make sure the steps you provide are accurate and complete.
Created attachment 264915 [details] script to get and put in place libpdf.so Here is a script (taken from http://blog.zx2c4.com/424) that when run as root will extract libpdf.so from the binary chrome and put it where chromium (build from source) expects it.
(In reply to comment #5) Taking the plugin from Google Chrome does seem to work. The attached script will not work in an ebuild context for several reasons, but thanks for the info anyway.
The library works with >www-client/chromium-11.0.672.2-r2 (amd64/x86). Thanks! ============== IUSE=".. bindist" LICENSE="!bindist ( BSD ) use bindist ( Google BSD )" SRC_URI="http://build.chromium.org/official/${P}.tar.bz2 bindist? ( x86? ( http://dl.google.com/linux/direct/google-chrome-unstable_current_i386.deb ) amd64? ( http://dl.google.com/linux/direct/google-chrome-unstable_current_amd64.deb ) )" ......{unpack}....... src_install{} if use bindist; then chmod 644 ${WORKDIR}/debian-binary/opt/google/chrome/libpdf.so cp ${WORKDIR}/debian-binary/opt/google/chrome/libpdf.so ${D}${NEW_CHROMIUM_HOME} fi ..... ================= Everything just seems to be
Created attachment 265009 [details] ebuild with support pdf No wide testing
Created attachment 265013 [details, diff] diff ebuild
Created attachment 265015 [details, diff] diff ebuild
Okay, re-opening. There are still some issues to be resolved, for example licensing, versioning, mirroring, and so on. I will take a closer look.
A library of proprietary Google Chrome should be distributed under the same license as the browser itself, since it is not part of the project Chromium. Therefore, it is Google EULA http://www.google.com/chrome/intl/en/eula_text.html Pdf support appeared in Google Chrome in the summer of 2010. As a consequence - the library is completely normal working with Chromium from the current stable version v.9x (the results of my tests))
(In reply to comment #7) > SRC_URI="http://build.chromium.org/official/${P}.tar.bz2 > bindist? ( > x86? ( > http://dl.google.com/linux/direct/google-chrome-unstable_current_i386.deb ) > amd64? ( > http://dl.google.com/linux/direct/google-chrome-unstable_current_amd64.deb ) > )" Actually this has a problem. Those download links are not versioned (google-chrome-unstable...), and they change in place. We can't generate non-broken digests for them. Feel free to re-open after finding solution to that problem.
Created attachment 268309 [details] chromium-12.0.712.0.ebuild Indicated the exact location of Google Chrome package
Created attachment 268313 [details, diff] ebuild patch
Reopening since we have been provided info that should produce a constant Manifest. I have a high level question: Are we allowed to mirror the google-chrome deb files? If not, do we have a way to selectively prevent mirroring? I believe RESTRICT="mirror" will prevent mirroring of all files in SRC_URI, but ideally we want to mirror ${P}.tar.bz2. Also, here are a few technical comments on the ebuild patch: 1. xz-utils was recently added to the system set, so the dependency is not really necessary. 2. I think the src_unpack() function is needlessly complex and could be removed entirely. There is no need to unpack the deb file in its own "deb" directory, unless it happens to contain a file called ${P}. 3. You should use the ebuild helper functions for installation whenever possible. doexe would be appropriate in this case. 4. What happens if we are building for ARCH=arm? Your patch does not account for this.
Mirroring files google-chrome.deb limited license as in the case of GoogleEarth. Otherwise they would have attended the mirror Debian. In addition, Google's servers are designed for high load, so that in this case, it should not be a big problem statement an official source package. 1. xz-utils. Unnecessary dependence removed. 2. Removing phase src_unpack failed, although it has undergone changes. data.tar. lzma does not automatically unpacks 3. Yes. During installation using standard ebuild helper functions 4. In the case of ABI = arm (for example), nothing happens. The only added to the ebuild in this case a warning that there is no binary package for this architecture
Created attachment 268667 [details] ebuild
Created attachment 268669 [details, diff] ebuild patch
Sorry, after thinking about it for a while I decided not to implement this. 1. The plugin is binary, which might result in problems similar to chromium-bin. 2. Mirroring is still not obvious, and maintaining the ebuild would be harder because of having to keep the PDF reader in sync. I think it's easier to just use the complete Google Chrome package instead of extracting some pieces of it and trying to get them to work with Chromium.
Since the chromium herd has decided not to maintain this (understandably so), I thought I would advertise the unofficial package I have just added to my overlay. You can install it via layman. https://bitbucket.org/floppym/floppym-overlay/src/default/www-plugins/chromium-pdf/ I plan to track the dev channel releases to start. If anyone would like me to add the stable or beta channel versions, just let me know by email or ping me in #gentoo-chromium.
Consider a few known facts: 1. There is always the three branches of chromium: stable, beta and unstable 2. For both branches, daily leave binaries * _unstable/beta/stable-x86/amd64.deb 3. In gentoo tree more often than once a week, you add new snapshots of both branches of chromium 4. It is impossible to argue that in a week for at least 99% of the source code is unchanged 5. Members arch/~arch Gentoo usually installed the latest versions of chromium for its branches 6. The emergence of a new branch of chromium is characterized by the fact that at the same time on Google's server is a change versions of the binaries: stable => old (remove), beta => stable, unstable => beta, new (addition) => unstable The result suggests an important conclusion: There is no point in working hard to track minor versions like Google Chrome and chromium. In this regard, it is proposed to change the system itself numbering chromium / chromium-pdf 1. At the moment, add to the tree chromium and chromium-pdf-12(stable), -13(beta/tested), -14(unstable/hard mask), or add them directly only chromium-pdf at the same time-bound 12, 13 and 14 version: = chromium-12.* at the same time as the need otpdaet track versions, and mirror them as snapshots chromium and binary files Google Chrome. Changes in the very same ebuild will be tracked as versions of revisions (-r1,-r2, ....), as well as the stabilization level
PS. Current version Google Chrome (daily build) for i386 ver 12: https://dl-ssl.google.com/linux/direct/google-chrome-stable_current_i386.deb ver 13: https://dl-ssl.google.com/linux/direct/google-chrome-beta_current_i386.deb ver 14: https://dl-ssl.google.com/linux/direct/google-chrome-unstable_current_i386.deb
(In reply to comment #22) > 3. In gentoo tree more often than once a week, you add new snapshots of both > branches of chromium For the sake of correctness, they are releases, not snapshots. > The result suggests an important conclusion: > There is no point in working hard to track minor versions like Google Chrome > and chromium. Sorry, I think the points aren't really related to the reasons I pointed out in https://bugs.gentoo.org/show_bug.cgi?id=341937#c20
*** Bug 378359 has been marked as a duplicate of this bug. ***
