In our case (Debian Lenny), the setup options complain of not having pdftotext and pdfinfo installed, while this is not true (they are part of poppler-utils|xpdf-utils).
It may be that zotero doesn't look for the executables in your normal path, and that they need to be in your zotero directory (of your firefox profile). You could either copy them there, or put a symlink to them there. your link or copy may need to be named 'pdftotext-Linux-i686.'
I symlinked
ln -s /usr/bin/pdfinfo /home/paolo/.mozilla/firefox/pdfinfo-Linux-x86_64 (what the setup windo is asking for), but still Zotero complains about not finding them. However, the obviously good sloution is having zotero looking for them in the SELinux path.
Thanks.
Right. I don't know why Z doesn't look for them in the path. But try symlinking deeper, right into zotero's own directory in your profile. I don't have a linux box here, so I can't tell you where it is. But it's 1 or 2 directories deeper than .mozilla/firefox. It'll be .mozilla/firefox/.../.../zotero/, I think.
There is at least one other thread on this forum on the topic. Search "PDF indexing linux"
Zotero doesn't look in the path. (In fact, I don't know that we even have any way of doing so.) It just looks in the data directory, as explained on the PDF Fulltext Indexing page linked from the setup window.
The main problem, though, was just that an x86_64 version of the Xpdf utilities wasn't available via the installer. That's now fixed, so I'd recommend removing the symlinks and installing from the Zotero prefs. (You can leave the pdftotext symlink to your package manager version if you want, since we just use the official pdftotext binary, but pdfinfo needs some custom modifications to work.)
Zotero doesn't look in the path. (In fact, I don't know that we even have any way of doing so.)
I think other extensions look in the path, but I don't know offhand how they do this. A "hack" that might work would be to ship with a (OS dependent) wrapper shell script in a known directory & to use that to get the path.
It's somewhat moot until we can use an unmodified version of pdfinfo. We currently use a custom build that writes to a text file, since I haven't found any way to get stdout back from processes in Firefox via JS. If we could do that, we could use the installed Xpdf tools on Linux and OS X if they were available, but otherwise we're stuck with this solution.
Since the issue persists and custom scripts are still needed (aren't they?) I decided to follow up to Dan's:
"It's somewhat moot until we can use an unmodified version of pdfinfo. We currently use a custom build that writes to a text file, since I haven't found any way to get stdout back from processes in Firefox via JS. If we could do that, we could use the installed Xpdf tools on Linux and OS X if they were available, but otherwise we're stuck with this solution."
So, why not then just create a 4 line shell script pdftotext_wrapper.sh containing smth like
#!/bin/bash
ofile=$1
shift
pdftotext $* > $ofile
?
then you could call it instead of pdftotext and rely on default pdftotext installation... or am I missing the point?
This might be stating the obvious (apologies if it is), but Dan, have you tried to contribute your changes to pdfinfo upstream to the poppler / xpdf developers?
Upgrade Storage
ln -s /usr/bin/pdfinfo /home/paolo/.mozilla/firefox/pdfinfo-Linux-x86_64 (what the setup windo is asking for), but still Zotero complains about not finding them. However, the obviously good sloution is having zotero looking for them in the SELinux path.
Thanks.
There is at least one other thread on this forum on the topic. Search "PDF indexing linux"
Many tanks.
The main problem, though, was just that an x86_64 version of the Xpdf utilities wasn't available via the installer. That's now fixed, so I'd recommend removing the symlinks and installing from the Zotero prefs. (You can leave the pdftotext symlink to your package manager version if you want, since we just use the official pdftotext binary, but pdfinfo needs some custom modifications to work.)
Let us know if you have any problems.
It's somewhat moot until we can use an unmodified version of pdfinfo. We currently use a custom build that writes to a text file, since I haven't found any way to get stdout back from processes in Firefox via JS. If we could do that, we could use the installed Xpdf tools on Linux and OS X if they were available, but otherwise we're stuck with this solution.
"It's somewhat moot until we can use an unmodified version of pdfinfo. We currently use a custom build that writes to a text file, since I haven't found any way to get stdout back from processes in Firefox via JS. If we could do that, we could use the installed Xpdf tools on Linux and OS X if they were available, but otherwise we're stuck with this solution."
So, why not then just create a 4 line shell script pdftotext_wrapper.sh containing smth like
#!/bin/bash
ofile=$1
shift
pdftotext $* > $ofile
?
then you could call it instead of pdftotext and rely on default pdftotext installation... or am I missing the point?