Searching without hope of finding, and holding on for dear life.

Posted by Derek Cornish
Aug 7, 2007 at 05:03 PM

Jim,

> None of them quite did what I wanted. Zoot comes closest, but I need to be able to store graphics, and the text based nature of Zoot precludes that.

It’s hard to know at this stage whether Zoot will ever be developed to store graphics, or pdfs, for that matter. There is something rather bracing about its dedication to plain text - although it is sure to get an rtf editor at some point - and a lot of data access issues can be improved by hyperlinking. For example, you could store your images and pdfs in Web Research and access them from Zoot’s items via WR’s “address links”. Or you could simply store them in the Windows filing system and link them to Zoot items.

The problem, of course, is how to search this data (pdfs in particular) efficiently. If it’s in WR, you can add pdftotext to WR and this will enable searches to be made within pdf files (as long as they are not image ones). But…the “hits” are not displayed and highlighted. You still have to go to the individual pdf files found by WR and search within them using Acrobat Reader’s internal search.

Alternatively, you can keep pdfs in the Windows filing system and search them with any desktop indexed search engine (I use dtSearch). Or you can even place text copies of the pdfs inside Zoot with links to the original file. That way you can use Zoot’s own search features. Storing long text items in Zoot will presumably be improved in Zoot32. At the moment there is about a 5000 word limit per item before incoming text gets split into smaller chunks over successive items.

None of this is very satisfactory. How did we allow Adobe to foist the pdf on to us? It is the most intractable of formats, and too often used when plain text would do just as well…

So, I remain ambivalent about how much Zoot should be developed in the direction of an information bucket like UR. It is superlative for plain text and with an (optional, I hope) rtf or html (xml?) editor, freedom from current restrictions on numbers of folders and item length, it is going to be very exciting IMO. These - plus the fact that linking to external data will be much improved as other software developers add url address-links to their contents - e.g., WhizFolders - will keep Zoot competitive and useful.

All it really needs in addition is a better way of accessing the contents of its database (*.zot) files from outside the program so that desktop search engines can include zot files it HDD searches. At the moment the best solution is the export Zoot’s databases to html, but the resulting files are large and take a while to search. This has to be done regularly, too, to keep the content up to date, so is a bit of a chore - but it gives a nice output to dtSearch.

Let us know how the Mac experiment goes. I’m sure many of us will be following this, and it would add a lot to the group (just IMHO) if we heard more from the Mac contingent. There seems to be so much going on “over there” at the moment.

All the best,

Derek