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

[Samuel Klein]

As far as ff extensions go, Lector has been mentioned in the past as worth
looking into, though I don't know that it has been updated in a while.
  https://addons.mozilla.org/en-US/firefox/addon/527
  http://www.teleread.org/blog/2007/12/04/an-e-reader-that-accepts-any-xml/


On Wed, Oct 22, 2008 at 8:51 AM, Samuel Klein <sj at laptop.org> wrote:

> 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/bd13faf7/attachment.htm