Sugar unusable as an e-book reader

[Gary C Martin]

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.

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

>>> 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.
>
> changing their titles in the journal requires that I first figure  
> out which is which.

A non-child friendly shortcut is to use the copy-to-journal command in  
the Terminal (there's also a useful copy-from-journal equivalent that  
can save you digging about hex filenames when going the other way).  
These scripts are both in the 767 build, and there is also an improved  
version of copy-to-journal script which also works out the mime type  
for you:

	http://wiki.laptop.org/go/Copy_to_and_from_the_Journal

--Gary

> I was not having any sucess using the search. it may be that I only  
> gave it 5 min or so and it had not yet finished indexing everything  
> on the USB stick, so what I was searching for wasn't known yet.
>
> David Lang