Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 275677 - app-office/openoffice-bin app-office/openoffice and OOo executable mis-detect helper apps
Summary: app-office/openoffice-bin app-office/openoffice and OOo executable mis-detect...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Linux bug wranglers
Depends on: 275678
  Show dependency tree
Reported: 2009-06-28 11:14 UTC by DEMAINE Benoît-Pierre, aka DoubleHP
Modified: 2010-02-24 18:10 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description DEMAINE Benoît-Pierre, aka DoubleHP 2009-06-28 11:14:33 UTC
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 *... ]

... 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:
letting the old one should not be a problem:

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.
Comment 1 Wormo (RETIRED) gentoo-dev 2009-07-07 06:58:16 UTC
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?
Comment 2 DEMAINE Benoît-Pierre, aka DoubleHP 2009-07-07 09:33:32 UTC
(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

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:
Comment 3 Wormo (RETIRED) gentoo-dev 2009-07-09 00:11:42 UTC
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
Comment 4 James Earl Spahlinger 2009-07-29 05:00:53 UTC
Does the suggestion by Wormo work? Please re-open when you get a chance to test one way or the other. Thanks.
Comment 5 DEMAINE Benoît-Pierre, aka DoubleHP 2010-02-24 18:10:27 UTC
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.