Sugar unusable as an e-book reader

Gary C Martin gary at
Mon Oct 27 12:07:14 EDT 2008

On 27 Oct 2008, at 04:19, david at 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  

> 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.


More information about the Devel mailing list