[OLPC library] Fwd: Open-source, cross-platform ePub reader

[Samuel Klein]

Hi Skier,

On Tue, Oct 21, 2008 at 2:38 AM, S Page <info at skierpage.com> wrote:

> By "real", do you mean http://wiki.laptop.org/go/Book_reader_feature_set , or are there other requirements/wishes?  I would be interested in reading
> them and figuring out what it


Primarily, yes.  I recently added "small footprint" to that set - it
shouldn't take a lot of memory to read a text or html file, and a reader
should support sensible interfaces to support compressed texts.


> takes to bring the features to Browse -- I'm confident they've been done as
> Firefox extensions.  Nearly everything in that Book_reader_feature_set is in
> Browse except

"Annotations, preferably sharable via network"; do any of the other book
> readers support annotations?


You may be right.  The memory required to run a barebones brower with
extension support is a continuing problem, however.

For annotations and the like, a number of readers try to implement something
sensible.  There are some open standards, though people trying to implement
new cool annotations features still regularly try to create new ones. Take a
look at fab4 for an example of a project attempting some of what you
describe:
http://multivalent.sourceforge.net/Browser/
http://bodoni.lib.liv.ac.uk/fab4/


laptop.org pages say compression is important, then they note JFFS2 does
> compression.  So does compression matter or is it the filesystem's job?
>

It matters.  The compression with gzip for texts such as used in wikibrowse
is much better than you get simply by storing the files on the filesystem.


>
>   (like wikibrowse).
>>
>
> WikiBrowse is indeed really cool.  Is it a separate web server that
> responds to URL requests from Browse (or other programs) by handing back
> pages?  It or another simple web server could do the aforementioned "You
> asked for bigpage.html, here's bigpage.html.gz".
>

It is.  Wade Brainerd helped port the server code used to python' it's worth
a look.


> Is your use case
> * G1G1 users expecting their XO to be an eBook reader like the Kindle or
> Sony
> * or country deployments trying to make textbooks available for the XO
> ?  Seems the latter is best met by converting materials to HTML then
> providing them as collections.
>

The immediate use case is the latter.  I don't consider the two use cases to
be very different howver.  Both audiences have a need to immediately and
smoothyl read pdfs they find or are given from a large pdf library - these
may simply not yet have been converted to html (and the default conversion
may be significantly ugly or difficult to parse) or they may not be ocr'ed,
in which case they need to be converted to a set of images... and again we
have no image-sequence-book-reader.

Both audiences have a need to read html materials displayed as dictated by
the html, and to read txt and abw and doc materials created in their
respective programs that come on the XO... which should render nicely and
with the interface keybindings and options expected from a reader -- it
makes no sense to provide different reader interfaces based on the format of
the original, even though a highly-editable format may offer the additional
option of opening the file in a novel and clever and separately-developed
editor.

SJ



>
> Thanks for any elucidation you can provide,
> --
> =S Page
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/library/attachments/20081022/da7e7827/attachment.htm