I’m not aware of any user-side tricks that can make Spotlight index package contents (let alone for specific applications). I’ve done a little searching around to see if there was a command-line switch or preference file that could be modified, but couldn’t find anything. I can’t imagine the results of that being terribly useful anyway. You’re just going to end up with a huge bunch of cryptically numbered PDF filenames coming up all of the time.
If you’re referring to the File/Import/Research Files as Aliases… command, then this isn’t a problem as aliases are not routed to file via their paths, but via the internal HFS+ file identifier tokens, mapping them to the physical locations where the data is stored on the disk. So the main limitation with aliases is of course that they only work from one computer. If you “Dropbox” it, the links won’t work even if the DB folder has the PDFs.
Thanks for looking AmberV! There is one software solution called Foxtrot Professional or something of the sort that searches within bundles but it is $120, not worth it for my niche requirements.
I personally would have no problem with the cryptic numbering, the quicklook preview is much more useful than the filename anyway…
Ah, OK I didn’t know that. I have used Scriv-Aliases for other file types and don’t remember having a problem working across two computers. I do keep all my work on Dropbox, so its good to know this may be a fragile solution.
I want to roll my own solution, and make a little ruby script to create soft links of the PDFs (I can parse the scrivx XML for the binder names), however if I do the following (191.pdf is my desired PDF I want to index)
The soft link is broken, although it seems to point to the right place:
[code]lrwxr-xr-x 1 ian staff 34B 11 Oct 10:14 Test.pdf@ → The Beast.scriv/Files/Docs/191.pdf
The file /Users/ian/Desktop/Test.pdf does not exist.
So ln -s seems to break with doc bundles (ln -s is fine for normal PDFs elsewhere).
Also it looks like spotlight doesn’t index softlinks anyway, if I have X.pdf and XSoftlink.pdf – Spotlight only returns X.pdf when searching for content inside the PDF. Either Spotlight is smart and knows they are the same file, or it is just doesn’t index softlinks…
Yeah, I did see that search engine you found, but the pricetag.
Fragile would be too strong a word, it’s just that the linked research will not be accessible from any computer other than the one the alias was created on. They’ll continue working on that same system however.
With the sym-link thing, that shouldn’t be a problem—symbolic links operate at a level that is quite ignorant of packages—that’s a user-land convention, really, the thing that makes something a package is in the Cocoa layer of the system. I just tested it and created an external ‘test.pdf’ that I can even double-click on to load from an internal resource. Perhaps you do not have this project on your Desktop? It’s a relative link, so obviously the conditions for that link need to be satisfied. I just wondered since you gave a full path for the sym-link, ~/Desktop/Test.pdf, instead of just Test.pdf, which would be valid if the link is being created as a sibling to “The Beast.scriv”.
But, as you say, Spotlight doesn’t seem to index them anyway.
Yes, I got my symlink directories the wrong way round. I may end up just parsing the scrivx xml and exporting the pdf into a folder, this wastes diskspace but at least I can index and find these research pdf.
As a slight aside, is there a way to get the finder path of a document in the binder within scrivener?
Something else to consider is the “Files/search.indexes” file, instead of the .scrivx. The former not only has the ID<->Title wiring, but for PDFs with text content, the plain-text dump from that PDF. This is how Scrivener finds PDFs when using project search, and thus it might be of some use in a scripted environment. Perhaps you can write something that instead of dumping all PDFs so that Spotlight can read them, searches that file for the phrase and lets you conveniently open any matching PDFs.
Not through the UI. We don’t want to encourage people to edit their component files directly.