Re: [documancer] Using Documancer for HTML books on CD

[Vaclav S. <vac...@ma...>]

Hi,

Kevin Ollivier wrote:
> When users finish creating their EClass, they can distribute it on
> CD-ROM or publish it to web. (Or make a PDF too, actually.) For CD
...
> ;-), and people also would like to have highlighted search results.
> Enter Documancer. =) 

It's funny to see people use it for things it was never intended to 
do ;) Not that I mind, of course. 

> Furthermore, what would be nice is if 
> Documancer could remember CD-based books in the book manager, and
> when such a book was selected, it would prompt something like
> "Please insert the CD-ROM for book X to load this book."
>
> Here is what I suggest as a solution to these issues:
>
> 1) Have Documancer's wxConfig write a Version key upon startup.
> This way I can check to see if Documancer is of a high enough
> version to support what we're doing.

I don't want to do this -- what if you use two versions? They'd keep 
fighting over the value. And if the user didn't run Documancer yet, 
there would be no ~/.documancer/config.ini and thus no version info. 

OTOH, being able to run "documancer --version" would be useful (done 
in CVS). And maybe a registry entry on Windows with path to installed 
Documancer, as (HKLM or HKCU)\Software\V.S.
\Documancer\${version}\path. Would that suffice? You can look into 
HKLM\Software\V.S.\Documancer (and if it doesn't exist, HKLM) to see 
all (typically, 1) version numbers under it.

> 2) Either create a "mybook.book" persistent storage format for book
> configs, or pass in the book's "index.htm(l)" to have it added into
> Documancer's book manager. (I assume from there Documancer would
> see if an index exists, etc.)

I wanted to avoid having Documancer-specific file format. Instead, I 
want to be able to handle _any_ relevant format out there. If you 
look at what book definition contains, majority of it is user's 
customization, i.e. something you don't want to be part of .book 
format -- things like font settings (to be done), whether you want 
fulltext index or not and so on.

OTOH, I'm thinking about moving book definition from config file into 
separate files (one per book) for easier (manual) maintainance and to 
allow merging of books from different sources (like globally 
available books and your private ones, books installed by default 
etc.). That could be (ab)used for your purposes as well: you would 
add a new path to book files (using something like "documancer 
--add-books-path /foo/bar") and put all your books there.

> The former approach is IMHO advantageous as on Mac I could tell
> people to double-click the ".book" file to load it into Documancer.

That's what I'd like to have in 1.0 for any format -- let Documancer 
recognize the format, create book definition (if possible, otherwise 
with user's help) and file it into "Temporary Books" folder. That's 
because I recently had to work with manuals about things I'll never 
need again in foreseeable future (like learning how to embed PDF and 
PNG figures in LaTeX documents) and the books approach is not best 
for that. Instead, I want to open a file (without having to define 
the book), use it for a while and then forget about it -- and don't 
waste space for index or in books list.

> It also means that you could have a simple "Open File" approach to
> loading books - just pick the .book file and click OK to load it.
> (If you pick another type of file, like html, or man, it will
> prompt you for the necessary info.)

Yes, exactly the idea.

> 3) Maybe some sort of BOOK_ON_CD setting.

I think it's not needed: if the data providers were able to return 
list of files they use (and I will need this to be able to 
automatically update indexes), Documancer could check for their 
presence (again, it will do this because of another feature anyway) 
and if all them were missing *and* they were located on removable 
medium, it would tell the user to insert it.

Regards,
Vaclav

-- 
PGP key: 0x465264C9, available from http://pgp.mit.edu/