Sugar unusable as an e-book reader

[david at lang.hm]

On Tue, 28 Oct 2008, Gary C Martin wrote:

> On 27 Oct 2008, at 22:27, david at lang.hm wrote:
>
>> On Mon, 27 Oct 2008, Gary C Martin wrote:
>> 
>>> 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?
>> 
>> 800k
>
> Interesting, that's pretty small, I read an ~80 odd page ~17Mb graphics 
> intensive pdfs here (blenderart), some pages take a couple of seconds to 
> render, but often have background rendered by the time I move onto a new 
> page.
>
> Perhaps check with Terminal and see if some process is hogging your cpu when 
> your USB key is recently plugged in (use the top command). This is a known 
> and highly reported issue for some time and is related to how the Journal 
> currently interacts with external media. I have a key I use with the XO and 
> generally just keep a handful of files on it (perhaps a few hundred, to a 
> thousand, at times) ? it's been responsive for me with that number of files, 
> but I think other media approaches are being to be moved forward on to 
> improve interoperability.

some of the times I tried this the USB stick had been plugged in for 20 
min or so.

the startup seemed to be more likely to fail with a terminal open.

this pdf was created by loading a .rtf file and exporting it to pdf in 
openoffice.

>>>> 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.
>> 
>> good to know. How should I have found this on my own?
>
> I just tried and found it when I saw your email, I've updated the Read wiki:
>
> 	http://wiki.laptop.org/go/Read#Keyboard_navigation

the lack of documentation or help text on the XO makes it very hard to 
find such things. I wouldn't have known to go to that page on the wiki to 
find it.

>>>> 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).
>> 
>> with the ability to move in smaller amounts the zoom becomes usable. 
>> there's still the annoyance of not being able to move a page at a time.
>
> Clearly this is annoying you, so I'm not trying to excuse the behaviour, but 
> browsers, pdf viewers, and text views I've just tried all overlap page 
> scrolling by a few lines or so. I believe the idea is to keep a little 
> context so you can still see a line or so of what you've just read. The only 
> exception to this is if you switch to a paged view mode (rather than 
> continuous), but for most pdfs this generally means the text is too small to 
> comfortably read even on large displays. You can achieve something similar in 
> Read by zooming out to see a whole page (portrait screen rotation often helps 
> here) and then using the 'Read' tab page forward and page back arrow buttons 
> ? unfortunately there are no keyboard shortcuts for these two button 
> operations, and mouse cursor movement is quite a challenge when the screen is 
> rotated (perhaps '+'/'-' or shift-up/down could be mapped).

if you zoom to 'fit to screen' (or the proposed 'fit painted ara to 
screen') then it should switch from continuous mode to paged mode.

or provide a toggle on the zoom screen to switch between paged and 
continuous mode.

defining shift keys or other keyboard funxtions won't do any good in 
tablet mode.

I've used the XO to read magazines that I've got electronic subscriptions 
to in the past, with mixed results (they are heavily column based), but 
there the problems were clearly the fault of the document being read.

in this case I had book 7 of a sci-fi series that I had just finished 
reading the first 6 books of over the weekend and I wanted to just 
continue reading, so I decided to try to use the XO to do so.

in the process I discovered that these annoyances (which I hadn't really 
noticed while reading the magazine articles) were disruptive enough to 
keep me aware of the mechanics of reading, preventing me from just 
enjoying the story. after spending almost as long fighting the XO as I 
would have taken to read the story, I paused to send my rant to the list 
to express my frustrations

for someone trying to study the distraction may not be something they are 
conscious of, but it will significantly impact their ability to learn from 
the text.

David Lang