I have an OOo document containing URL pointing to local PDF files. When i click on URL, i want the pointed file to be open, by apropriate application. Last year, it used to be xpdf, by default, automatically, and i was happy with that. Since a few months, OOo open PDF in acrobat reader. After mv /opt/bin/acroread /opt/bin/acroread_ it does it in gimp. After mv /usr/bin/gimp-2.6 /usr/bin/gimp-2.6_ it does not open PDF at all. Fact is that OOo first tries to call gnome-open , and if it fails, /usr/lib/openoffice/basis3.0/program/open-url . First bug: when acrobat and gimp fail to start, those should look for XPDF. This bug is at the same time against gnome-open and basis3.0/program/open-url and should be fixed for all 3 packages (app-office/openoffice-bin app-office/openoffice gnome-base/libgnome ) After doing mv /opt/bin/acroread /opt/bin/acroread_ and trying to ask OOo to open a PDF, restauring acroread to normal name still make OOo use gimp; this means OOo makes the system "memorise" the helper application. This is clever, but, not compleetely; this will have an impact on the second bug. * While stracing gnome-open, i saw that gnome-open uses a mime database to determine which app should "help" each file type: /usr/share/applications/mimeinfo.cache . As this file does not belong to any ebuild ... dhp@moon-gen-3:~/.local$ equery b /usr/share/applications/mimeinfo.cache [ Searching for file(s) /usr/share/applications/mimeinfo.cache in *... ] dhp@moon-gen-3:~/.local$ ... I edit it manually, and redefine PDF to xpdf. Before I try to test if this helps me, I remove openoffice source, and install the -bin version. After installation, my xpdf declaration has gone. What means, installation of, at least the -bin version, affects /usr/share/applications/mimeinfo.cache . Second bug: the filter used/called by OOo installer should not overwrite existing settings in mimeinfo.cache , but compleet them; it's perfectly capable to specify several helper apps: application/pdf=AdobeReader.desktop;gimp.desktop; letting the old one should not be a problem: application/pdf=xpdf.desktop;AdobeReader.desktop;gimp.desktop; third bug: this filter/script should not restrict to acrobat and gimp, but also consider xpdf. This may require to alter xpdf ebuild. This is a normal bug (not minor), because for people who dont have acrobat/gimp, OOo will no more be able to open PDF, even when xpdf is installed.
It all boils down to that same problem from bug 275678 of xpdf not yet installing a desktop file; openoffice is behaving as intended by looking up helpers in mimeinfo.cache, which is generated from currently existing desktop files. Old openoffice must have had some built-in entries for apps like xpdf that never got around to registering themselves according to freedesktop standards, but now it just goes with the standard mime database. /usr/share/applications/mimeinfo.cache gets automatically generated from the desktop files in /usr/share/applications, so as a workaround you need to create a xpdf.desktop file rather than editing mimeinfo.cache directly. If you do create xpdf.desktop, please submit it on your bug 275678 :) Are there any other helper apps that are not being found, meaning they also are missing desktop files?
(In reply to comment #1) > a xpdf.desktop file rather than editing mimeinfo.cache directly. If you do > create xpdf.desktop, please submit it on your bug 275678 :) I dont know how to do it. I know how to create .desktop files manually, but, how will the generator know that *THIS* app can handle PDF files ? I ll try a bit of reverse eng against .desktops of gimp and acrobat. > Are there any other helper apps that are not being found, meaning they also are > missing desktop files? I was to say "no, I dont know many PDF readers". In fact, yes: at least karbone, and, at least an other one I forgot the name. Karbone is installed on my box, and was not listed ... and, maybe should be ? or not ? there are at least one other PDF reader in Gentoo, that should be tested. OOo can also open PDF since version 3.0, and, because of this, should also be listed ... when compiled with requred options/features ... should I open a new independant bug to report this ? :P So, that's doing at least 2 apps that dont work, and one to be tested. *** I dont know those, and will not install them, but, from their names, they could be readers: eix -S pdf |grep app app-text/epdfview app-text/gsview app-text/pdfjam app-text/pdfshuffler app-text/pdftk app-text/epdf gnustep-apps/gspdf And this list is not compleet, because, this way, eix did not tell about Karbon. *** Which app regenerates the mime list ? The magick line to put in the desktop (from AdobeReader.desktop ) is: MimeType=application/pdf;application/vnd.fdf;application/vnd.adobe.pdx;applicati on/vnd.adobe.xdp+xml;application/vnd.adobe.xfdf;
Ok I whipped up a xpdf.desktop file for you to try (see bug 275677). Here is the command to regenerate the app list: update-desktop-database /usr/share/applications
Does the suggestion by Wormo work? Please re-open when you get a chance to test one way or the other. Thanks.
As bug #275678 is now fixed, it should work. But i am not going to break my conf to proof check it. So, leaving needinfo forever.
