Sugar unusable as an e-book reader
Gary C Martin
gary at garycmartin.com
Mon Oct 27 12:07:14 EDT 2008
On 27 Oct 2008, at 04:19, david at lang.hm wrote:
> I just gave up on trying to use my XO to read e-books (build 767)
I read a number of quite large pdf documents and research papers on
the XO, Read has been good for me and though there could be some
additional UI refinements, calling it unusable is quite an attempt at
trolling.
> I was completly unable to copy the doument from the USB stick to the
> local
> system and have it show up in the journal. when I hit copy things
> blinked
> for a few seconds and then nothng.
-- snip --
> opening the book in .pdf comes the closest to working. I was still
> unable
> to copy the document, so I had to try and read with the USB stick
> haning
> out of the machine.
Could I ask what size the pdf file was?
> I could zoom so that the text is the width of the
> screen, but after doing so I was unable to center the text (the arrow
> buttons move the text in overly large steps.
Hold the alt key down if you need small steps (granted this key is out
the way if you have flipped over the screen). Alt works for both
keyboard cursors and screen cursor pad.
> the fit-to-screen option works well if the text goes all the way to
> the
> margins, but most documents don't do that. what's needed here is an
> ability to say 'fit the content on the page to the screen' and have it
> zoom and center based on the actual content, not on the page size (I
> know
> this issignificantly harder to do, but it really is needed)
In the 'View' tab you can specify arbitrary zoom levels to zoom into
the sweet spot if a document is wasting screen space with wide page
margins. The zoom setting is remembered between activity resumes so
you only need to set it once for a document, however a very annoying
longstanding metadata bug means this data is lost after a reboot (also
means the page number you were on is forgotten).
> it also takes 2-3 seconds to paint each screen.
Hmmm, again, an idea of the pdf size might help gauge this.
The worst performance I've seen is when viewing something like a
detailed pdf map (there are some shipped as part of the library
bundles that show up in Browse). Zooming in several times and then
trying to scroll about can be slow as (I think) the pdf is being re-
rasterised in the background for the new zoom detail. For zooming in
on pdf maps, the background cpu load can take ~10sec or so of 100% cpu
load to catch up, during which time scrolling is very slow. Also as
you zoom in more and more memory is needed, usually OOM borking out
before you get 400%.
> even when I just had the one book in different formats the journal
> made it
> very difficult to tell them apart (I had to go to the command line and
> touch the files so that they had different timestamps and then
> remember
> 'the one from today is .rtf, the one from yesterday is .pdf, the one
> from
> the day before is .html, etc)
Why not just change each of their titles in Journal? Just click the
title name text and type something new. There's also a details page
for each Journal entry where you can add specific tags or a text
description, it's currently a little out of the way to get to (click
the little > icon on the far right of each Journal entry), but
hopefully will be more exposed in a future release. All title,
description, tag, and document content (if it's text and not an image
of text) is searchable from the Journal, I get to all my pdfs by
initially just typing pdf so I only have a couple of pages of titles
to look through.
--Gary
More information about the Devel
mailing list