Re: Sugar unusable as an e-book reader
On Tue, Oct 28, 2008 at 11:37 PM, [EMAIL PROTECTED] wrote: On Tue, 28 Oct 2008, Jim Gettys wrote: http://live.gnome.org/Evince/SupportedDocumentFormats has evince's currently supported formats. I don't know exactly how we have it built. it's disappointing to see that they miss the obvious/simple text format. They are focusing on the more complicated formats. I think I can hack together a simple text backend for Evince (though I'm not sure if I'll be able to do pagination with a quick hack). Please file a ticket and assign it to me. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
Hi James and David, I want to track additions and improvements to the XOs eBook Reader on our Feature roadmap page. I created a requirement called Better eBook Reader at: http://wiki.laptop.org/go/Feature_roadmap#Better_eBook_reader Can you update that with any additions or work we need to do? If you can separate it in to requirement (what we want to do) and specification (how we will do it) that will help. You can also put your name down as an owner if you plan to work on it in the near future. Any questions or comments welcome. Thanks, Greg S -- Message: 2 Date: Mon, 27 Oct 2008 16:06:29 -0500 From: James Simmons [EMAIL PROTECTED] Subject: Re: Sugar unusable as an e-book reader To: devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed All, As the author of Read Etexts I am grateful for all the mentions of my Activity on this mailing list. To answer David Lang's question, being able to read Gutenberg's plain text files without converting them IS the feature. There are hundreds of thousands of books available in this format, including some that would be very difficult to obtain at any price (Richard Burton's 1001 Nights, a complete English translation of the Mahabharata, old science fiction like Edison's Conquest of Mars, and so much more). Plain text files can be easily resized for comfortable viewing in either portrait or landscape mode, the font is easier on the eyes than PDF fonts generally are, and eventually we'll have reliable text to speech with karaoke highlighting that will read the books out loud to you. I have read several books on the XO using my own Activity, and other than the fact that it cannot remember the page you left off on last time (which will be corrected in time) I find it quite useable. I also wrote the View Slides Activity, which can be used to read comic books, among other things. The comments about Read being unuseable say more about the PDF format than about the Activity. I think Read does about as well for viewing PDFs as anything I've used, but looking at PDFs on a small screen is not that great. When someone gives me a PDF I tend to print it out. James Simmons the page for read_etexts doesn't say what it does that makes it better than the default read (other than being able to read zip files and gutenberg formats) David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
Greg, I have never worked on the core Read activity. From what I have seen of it, I would say that you would have to modify evince so that it could support more formats, notably plain text files and .cbr files (which are archive files containing sequentially named images). If it did that the need for my two Activities would vanish. I believe that evince can already support comic books in the .cbr format if you compile in optional support for it. Of course evince is not an OLPC project, and that will limit what can be done with it. Some of the problems you mention in your entry are actually issues with the Journal (not remembering page numbers and making unnecessary copies of files). I think others are working on improving the Journal datastore, which should help a lot of Activities. Document sharing is not reliable with Read (or Read Etexts either). Text to Speech in Read Etexts needs additional software to be installed on the XO to work. Someone was working on this a few months ago. As I said on my page for my Activities, I see them as only stopgaps until the XO has a better Read activity that supports more formats. I don't feel qualified to work on Read itself. James Simmons Subject: Re: Sugar unusable as an e-book reader To: devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi James and David, I want to track additions and improvements to the XOs eBook Reader on our Feature roadmap page. I created a requirement called Better eBook Reader at: http://wiki.laptop.org/go/Feature_roadmap#Better_eBook_reader Can you update that with any additions or work we need to do? If you can separate it in to requirement (what we want to do) and specification (how we will do it) that will help. You can also put your name down as an owner if you plan to work on it in the near future. Any questions or comments welcome. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
http://live.gnome.org/Evince/SupportedDocumentFormats has evince's currently supported formats. I don't know exactly how we have it built. The basic point is it is already able to support multiple formats as plug-ins and others may be feasible. - Jim On Tue, 2008-10-28 at 11:52 -0500, James Simmons wrote: Greg, I have never worked on the core Read activity. From what I have seen of it, I would say that you would have to modify evince so that it could support more formats, notably plain text files and .cbr files (which are archive files containing sequentially named images). If it did that the need for my two Activities would vanish. I believe that evince can already support comic books in the .cbr format if you compile in optional support for it. Of course evince is not an OLPC project, and that will limit what can be done with it. Some of the problems you mention in your entry are actually issues with the Journal (not remembering page numbers and making unnecessary copies of files). I think others are working on improving the Journal datastore, which should help a lot of Activities. Document sharing is not reliable with Read (or Read Etexts either). Text to Speech in Read Etexts needs additional software to be installed on the XO to work. Someone was working on this a few months ago. As I said on my page for my Activities, I see them as only stopgaps until the XO has a better Read activity that supports more formats. I don't feel qualified to work on Read itself. James Simmons Subject: Re: Sugar unusable as an e-book reader To: devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi James and David, I want to track additions and improvements to the XOs eBook Reader on our Feature roadmap page. I created a requirement called Better eBook Reader at: http://wiki.laptop.org/go/Feature_roadmap#Better_eBook_reader Can you update that with any additions or work we need to do? If you can separate it in to requirement (what we want to do) and specification (how we will do it) that will help. You can also put your name down as an owner if you plan to work on it in the near future. Any questions or comments welcome. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Tue, 28 Oct 2008, Jim Gettys wrote: http://live.gnome.org/Evince/SupportedDocumentFormats has evince's currently supported formats. I don't know exactly how we have it built. it's disappointing to see that they miss the obvious/simple text format. They are focusing on the more complicated formats. there is also the problem that since the journal doesn't let you specify what program to use to open documents several of these formats will end up beng handled by abiword (writer) instead. David Lang The basic point is it is already able to support multiple formats as plug-ins and others may be feasible. - Jim On Tue, 2008-10-28 at 11:52 -0500, James Simmons wrote: Greg, I have never worked on the core Read activity. From what I have seen of it, I would say that you would have to modify evince so that it could support more formats, notably plain text files and .cbr files (which are archive files containing sequentially named images). If it did that the need for my two Activities would vanish. I believe that evince can already support comic books in the .cbr format if you compile in optional support for it. Of course evince is not an OLPC project, and that will limit what can be done with it. Some of the problems you mention in your entry are actually issues with the Journal (not remembering page numbers and making unnecessary copies of files). I think others are working on improving the Journal datastore, which should help a lot of Activities. Document sharing is not reliable with Read (or Read Etexts either). Text to Speech in Read Etexts needs additional software to be installed on the XO to work. Someone was working on this a few months ago. As I said on my page for my Activities, I see them as only stopgaps until the XO has a better Read activity that supports more formats. I don't feel qualified to work on Read itself. James Simmons Subject: Re: Sugar unusable as an e-book reader To: devel@lists.laptop.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi James and David, I want to track additions and improvements to the XOs eBook Reader on our Feature roadmap page. I created a requirement called Better eBook Reader at: http://wiki.laptop.org/go/Feature_roadmap#Better_eBook_reader Can you update that with any additions or work we need to do? If you can separate it in to requirement (what we want to do) and specification (how we will do it) that will help. You can also put your name down as an owner if you plan to work on it in the near future. Any questions or comments welcome. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
David, Actually, the Journal *does* let you choose whatever Activity you like to open a document with. For instance, with a Zip file you can open it with EToys, View Slides, or Read Etexts. What the Journal doesn't do is open the one you'd like as a default. If you just Resume a Zip file chances are it will open up in EToys, which is frustrating. The Journal is good for opening up a journal entry using the Activity that created it, but since ebooks are not (yet) created by Activities this doesn't work. But you can easily get a menu of possible Activities to open your documents with using the Journal. An outdated screenshot showing how to do this is in the Wiki: http://wiki.laptop.org/images/1/15/ReadEtextsJournal.jpg James Simmons [EMAIL PROTECTED] wrote: there is also the problem that since the journal doesn't let you specify what program to use to open documents several of these formats will end up beng handled by abiword (writer) instead. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On 28.10.2008, at 11:38, James Simmons wrote: What the Journal doesn't do is open the one you'd like as a default. /usr/share/sugar/data/activities.default - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
Surely the solution for reading books is to ignore pdf - a format optimised for serialising text for print such that printing (which the XO doesn't even support yet) works the same way everywhere - and going to another well defined format more suitable for reading on a computer, such as text, rtf or html? ebooks are just the tip of the iceberg. (and probably only the first iceberg) Do you have a plan to translate all the existing pdf files into your new wonderful format? Even if you came up with a new/wonderful ebook format, how are you going to convince the world do jump on your bandwagon? -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
Am 27.10.2008 um 05:54 schrieb Benjamin M. Schwartz: [EMAIL PROTECTED] wrote: the full-screen mode is useless as the large icon to revert back to normal covers up the text in the upper corner. That icon is tiny, at least on my copy of Read. It certainly occupies less vertical space than the toolbar. I found it large enough to still be distracting. What do you propose instead? Fade out the icon whenever the mouse pointer stops moving for some period of time. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Mon, Oct 27, 2008 at 5:04 PM, Hal Murray [EMAIL PROTECTED] wrote: ebooks are just the tip of the iceberg. (and probably only the first iceberg) Do you have a plan to translate all the existing pdf files into your new wonderful format? Even if you came up with a new/wonderful ebook format, how are you going to convince the world do jump on your bandwagon? I find your comments a little confusing. Project Gutenberg publishes content in dozens of different formats. We already have Read Etexts which is a variant of the Read activity that can read the various formats. See: http://wiki.laptop.org/go/Read_Etexts I would love to see more effort into integrating Read Etexts into the core Read activity. At the moment the activity is mostly unusable, various problems with it have been noted in this thread. -- Stephen Thorne Give me enough bandwidth and a place to sit and I will move the world. --Jonathan Lange ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
Surely the solution for reading books is to ignore pdf That's pretty limiting. There are more legal downloadable books available in PDF than in any other format, about 600,000 on the Internet Archive alone. Scanned-in paper books are still the most popular sort. Producing text, rtf, or html by converting them with 99% accurate OCR produces roughly one error per line :-(. See: http://wiki.laptop.org/go/Read_Etexts There have been a variety of efforts to make a good book reader for the XO. So far, all have foundered, largely stumbling on molehills rather than mountains. The 10-button XO tablet with the buttons in inconvenient places, lack of standardization of their keycodes and intended functions, lack of system-wide access to GUI controls when the XO is in tablet mode, volunteer developer burnout, all have contributed. I think a new developer who just decided to define his own damn standards for these buttons could blast through the very low barrier to entry and quickly have the best book viewer on the XO. Browse (or Firefox, if you have it) does best for most things. I found it much easier to read Cory Doctorow's novel Little Brother (craphound.com), or the novels of Arthur Conan Doyle (gutenberg.org) on a Nokia N800 than on an OLPC (in html in both cases). The N800 was designed to be operated with one hand, and its global zoom and system GUI controls are pretty well thought out. It runs the Maemo.org gui and a version of Opera. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
[EMAIL PROTECTED] wrote: opening the book in .html just produces a lot of errors becouse the book is spread across lots of files, and the jurnal isolation mechanisms copy the file being opened to a temporary directory, where all the links to the other files don't work. Note that you could have entered file:///media in Browse and located the HTML files; I believe the links to other files would then have worked OK but you'd have to wander around with the USB flash drive hanging out of your XO. In an ideal world the book would be packaged as a single collection (.xol) file, so downloading it would unpack it in ~/Library and add it to the content navigation in the OLPC Library home page. You could try http://wiki.laptop.org/go/Creating_a_collection and http://wiki.laptop.org/go/Content_bundle_making_script . (I put Little-Brother.xol on USB, it showed up in Journal, I chose Start and this all happened and Browse displayed the e-book.) In this ideal world the .xol container would gain traction as an e-book format and Bain, Project Gutenberg, and the other content repositories would offer books as .xol bundles. HTML in Browse integrates cleanly with the library/home page, can use advanced CSS for attractive layout, takes you from a link to a document without the download-Journal-Read steps, avoids PDF's fundamental broken-ness rendering a paper page on a screen, has JavaScript to add interactivity and features like annotations, etc. etc. It's the future. But PDF is certainly an important legacy format. Regards, -- =S Page ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Mon, 27 Oct 2008, S Page wrote: [EMAIL PROTECTED] wrote: opening the book in .html just produces a lot of errors becouse the book is spread across lots of files, and the jurnal isolation mechanisms copy the file being opened to a temporary directory, where all the links to the other files don't work. Note that you could have entered file:///media in Browse and located the HTML files; I believe the links to other files would then have worked OK but you'd have to wander around with the USB flash drive hanging out of your XO. thanks, I'll have to give that a try. this should also work with a SD card. unfortunantly, the mere fact of plugging in the USB stick makes the journal go through the entire thing and index it. this takes a significant amount of time and the XO is unusable during this time (I ran into a few min where the mouse didn't even respond) In an ideal world the book would be packaged as a single collection (.xol) file, so downloading it would unpack it in ~/Library and add it to the content navigation in the OLPC Library home page. You could try http://wiki.laptop.org/go/Creating_a_collection and http://wiki.laptop.org/go/Content_bundle_making_script . I'll look into these. (I put Little-Brother.xol on USB, it showed up in Journal, I chose Start and this all happened and Browse displayed the e-book.) In this ideal world the .xol container would gain traction as an e-book format and Bain, Project Gutenberg, and the other content repositories would offer books as .xol bundles. I just tried a quick google search and found three different .xol file formats (an biometrics data format, a database format, and a map format), and I'm still looking for the one that you are using for collections. if there is a trivial means to convert from .xol to a standard directory (tar/zip) then it would have a chance. if you were to define your bundle as a zip file with specific files in it then you could also have your software use heristics to deal with zip files without your metadata in it (if by no other way then to show the list of files to the user and ask for the nessasary data) HTML in Browse integrates cleanly with the library/home page, can use advanced CSS for attractive layout, takes you from a link to a document without the download-Journal-Read steps, avoids PDF's fundamental broken-ness rendering a paper page on a screen, has JavaScript to add interactivity and features like annotations, etc. etc. It's the future. But PDF is certainly an important legacy format. html in browse does have one nasty problem, it shows partial lines of text at the top and bottom of the screen as another smaller problem, you have to figure out where to put the oversized mouse pointer to minimize it's annoyance when you are trying to read. I initially tried to put it on the right edge of the screen, but I discovered that it's very easy to flex the case enough to click the mouse butten when in tablet mode, which scrolls you to whereever the mouse happens to be sitting on the scrollbar. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Mon, 27 Oct 2008, S Page wrote:
[EMAIL PROTECTED] wrote:
In an ideal world the book would be packaged as a single collection (.xol)
file, so downloading it would unpack it in ~/Library and add it to the
content navigation in the OLPC Library home page. You could try
http://wiki.laptop.org/go/Creating_a_collection and
http://wiki.laptop.org/go/Content_bundle_making_script .
hmm, I modified the script from the second link and used it to create
bundle .xol files. putting them on the USB stick doesn't seem to work.
they show up in the journal as unknown file types and hitting start
doesn't seem to do anything (other than triggering some disk I/O)
the script is below. it looks like it's doing the right thing. the
resulting zip file has the book + library.info contents.
David Lang
#!/bin/sh
## usage: xolbundle filename
filename=$1
mkdir -p $filename/$filename
cd $filename/$filename
unzip ../../H_$filename.zip
cd ../..
# create the metadata
TARGET_DIR=$filename/library
mkdir -p ${TARGET_DIR}
# note: this is a stupid script! please fix it!
# see http://wiki.laptop.org/go/Sample_library.info_file
(
echo [Library]
echo name = $filename
echo global_name = $filename
echo long_name = $filename
echo library_version = 1
echo host_version = 1
echo l10n = false
echo locale = en ) ${TARGET_DIR}/library.info
# zip and rename as bundle
zip -9 -rq $filename.xol $filename
# delete extra files
rm -rf $filename
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On 10/27/08, Gary C Martin [EMAIL PROTECTED] wrote: On 27 Oct 2008, at 04:19, [EMAIL PROTECTED] 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. A little to strong I agree. I read quite a lot of stuff on the XO and it is quite useful. The main complaints are similar to yours: the losing of page/zoom info between reboots. And I look forward to Firefox downloads to Journal, it is a little timeconsuming to exit Firefox and open Browse to download a pdf or other format. Some annotation tool is probably a must for education. Karl ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
All, As the author of Read Etexts I am grateful for all the mentions of my Activity on this mailing list. To answer David Lang's question, being able to read Gutenberg's plain text files without converting them IS the feature. There are hundreds of thousands of books available in this format, including some that would be very difficult to obtain at any price (Richard Burton's 1001 Nights, a complete English translation of the Mahabharata, old science fiction like Edison's Conquest of Mars, and so much more). Plain text files can be easily resized for comfortable viewing in either portrait or landscape mode, the font is easier on the eyes than PDF fonts generally are, and eventually we'll have reliable text to speech with karaoke highlighting that will read the books out loud to you. I have read several books on the XO using my own Activity, and other than the fact that it cannot remember the page you left off on last time (which will be corrected in time) I find it quite useable. I also wrote the View Slides Activity, which can be used to read comic books, among other things. The comments about Read being unuseable say more about the PDF format than about the Activity. I think Read does about as well for viewing PDFs as anything I've used, but looking at PDFs on a small screen is not that great. When someone gives me a PDF I tend to print it out. James Simmons the page for read_etexts doesn't say what it does that makes it better than the default read (other than being able to read zip files and gutenberg formats) David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Mon, 27 Oct 2008, Gary C Martin wrote: On 27 Oct 2008, at 04:19, [EMAIL PROTECTED] 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 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? 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. 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. 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On 27 Oct 2008, at 22:27, [EMAIL PROTECTED] wrote: On Mon, 27 Oct 2008, Gary C Martin wrote: On 27 Oct 2008, at 04:19, [EMAIL PROTECTED] 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
Re: Sugar unusable as an e-book reader
On Tue, 28 Oct 2008, Gary C Martin wrote: On 27 Oct 2008, at 22:27, [EMAIL PROTECTED] wrote: On Mon, 27 Oct 2008, Gary C Martin wrote: On 27 Oct 2008, at 04:19, [EMAIL PROTECTED] 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
Re: Sugar unusable as an e-book reader
S Page writes: HTML in Browse integrates cleanly with the library/home page, can use advanced CSS for attractive layout, takes you from a link to a document without the download-Journal-Read steps, avoids PDF's fundamental broken-ness rendering a paper page on a screen, has JavaScript to add interactivity and features like annotations, etc. etc. It's the future. But PDF is certainly an important legacy format. You need an update on PDF. Here you go: PDF supports hyperlinks. You can browse from document to document. PDF fully supports non-paged documents. Document formats that can't support both paged and non-paged documents are the ones that have fundamental brokenness. PDF has JavaScript to add interactivity and features like annotations, etc. etc. (not that I agree that JavaScript belongs in a document format, but PDF supports it) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Sugar unusable as an e-book reader
I just gave up on trying to use my XO to read e-books (build 767) I downloaded the book (~250 pages) from Baen in every format they offer, and used openoffice to convert the rtf to .pdf. I'm not surprised that it couldn't understand any of the propriatary formats, so that left .rtf, .html, and .pdf opening the document in .rtf sometimes works, but about half the time the XO sits and works for about 30 seconds then goes back to the screen you were on before. even when it does work it opens the document in write, not in reader, so you have the cursor moving around (for editing) and it's very hard to page through things to just read the document 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. opening the book in .html just produces a lot of errors becouse the book is spread across lots of files, and the jurnal isolation mechanisms copy the file being opened to a temporary directory, where all the links to the other files don't work. even worse, it produces what look like multiple overlapping error messages, but the first one just keep reappearing when you try to clear it, so it's impossible to see what the other errors are. 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. 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. 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) the full-screen mode is useless as the large icon to revert back to normal covers up the text in the upper corner. paging through the book was difficult becouse of the overlap betwen the pages, after each page-down action I had to re-locate where I was (could you do something like put a light grey background under the text that overlaps? it also takes 2-3 seconds to paint each screen. I actually purchased 25 e-books, but couldn't get the rtf zip file to work. when I tried putting all the html versions on a USB stick I was completely unable to find anything becouse there ended up being 1300 individual files on the USB stick, and with the journal insisting on flattening them out to one long list it was impossible to do anything useful with them. 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) David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
I have no response to many of your points, but I do have responses for a few. [EMAIL PROTECTED] wrote: opening the document in .rtf sometimes works, but about half the time the XO sits and works for about 30 seconds then goes back to the screen you were on before. This is definitely a bug. Please file it, and we will try to fix it. even when it does work it opens the document in write, not in reader, so you have the cursor moving around (for editing) and it's very hard to page through things to just read the document Do Page Up and Page Down not work? If they do not, then that is a bug too. Please file it. 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. That's also a bug. Please file it. opening the book in .html just produces a lot of errors becouse the book is spread across lots of files, and the jurnal isolation mechanisms copy the file being opened to a temporary directory, where all the links to the other files don't work. Definitely true. This is a fundamental limitation with our datastore. Several solutions have been proposed, but none have gained momentum. even worse, it produces what look like multiple overlapping error messages, but the first one just keep reappearing when you try to clear it, so it's impossible to see what the other errors are. It sounds like this is also a bug. Please file it with a screenshot. opening the book in .pdf comes the closest to working. I was still unable to copy the document, That is still a bug. so I had to try and read with the USB stick haning out of the machine. 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. An interesting usability problem. the fit-to-screen option works well if the text goes all the way to the margins, but most documents don't do that. You were making this PDF yourself, correct? You could have set any margins you like... the full-screen mode is useless as the large icon to revert back to normal covers up the text in the upper corner. That icon is tiny, at least on my copy of Read. It certainly occupies less vertical space than the toolbar. What do you propose instead? signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Mon, 27 Oct 2008, Benjamin M. Schwartz wrote: I have no response to many of your points, but I do have responses for a few. [EMAIL PROTECTED] wrote: opening the document in .rtf sometimes works, but about half the time the XO sits and works for about 30 seconds then goes back to the screen you were on before. This is definitely a bug. Please file it, and we will try to fix it. even when it does work it opens the document in write, not in reader, so you have the cursor moving around (for editing) and it's very hard to page through things to just read the document Do Page Up and Page Down not work? If they do not, then that is a bug too. Please file it. not well, it gets especially bad if you want to move just a couple of lines to ctch the end of a paragraph (again, it's moving the cursor on the assumption that you are wanting to edit the page) it also doesn't zoom and center well (again, the difference between editing and viewing) 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. That's also a bug. Please file it. opening the book in .html just produces a lot of errors becouse the book is spread across lots of files, and the jurnal isolation mechanisms copy the file being opened to a temporary directory, where all the links to the other files don't work. Definitely true. This is a fundamental limitation with our datastore. Several solutions have been proposed, but none have gained momentum. even worse, it produces what look like multiple overlapping error messages, but the first one just keep reappearing when you try to clear it, so it's impossible to see what the other errors are. It sounds like this is also a bug. Please file it with a screenshot. how do I do screenshots on the XO? opening the book in .pdf comes the closest to working. I was still unable to copy the document, That is still a bug. so I had to try and read with the USB stick haning out of the machine. 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. An interesting usability problem. combining shift/control/etc/ with the arrow/game keys is one way to address 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. You were making this PDF yourself, correct? You could have set any margins you like... I made another stab at reading it by doing exactly that, but it still doesn't work well. even after I made the document go all the way to the edge of the page, and did the 'zoom to fit screen' the fact that it wouldn't page down a full page at a time make it unusable. you need an option to move a full page at a time. in this case I created the pdf myself, but there are _many_ cases where I would want to read a pdf supplied by others where I would not have an easy way to re-format them the full-screen mode is useless as the large icon to revert back to normal covers up the text in the upper corner. That icon is tiny, at least on my copy of Read. It certainly occupies less vertical space than the toolbar. What do you propose instead? it's about as tall as three lines of text. having something in the frame to go back from fullscreen could work. I've now converted the rtf to a .html file and am reading that through the browser. for some reason it has a scrollbar on the bottom of the screen indicating that it things that there is 10% or so off to the right. I am happy to report problems like I have in this message, and am willing to test fixes, etc. but the bug tracking mechanism is enough of a pain to deal with that I am not going to take the time to submit the half dozen seperate bugs reports that you are asking for. if you want them in that system feel free to add my e-mail to the report and I will respond to follow-ups. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
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. 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. 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) I'd like a pdf reader that would recognize multi-column formatting and have a mode so that the up-down arrows go up-down following columns rather than pages. [I'm sure there are a zillion rough edges.] -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Mon, Oct 27, 2008 at 3:22 PM, Hal Murray [EMAIL PROTECTED] wrote: I'd like a pdf reader that would recognize multi-column formatting and have a mode so that the up-down arrows go up-down following columns rather than pages. Surely the solution for reading books is to ignore pdf - a format optimised for serialising text for print such that printing (which the XO doesn't even support yet) works the same way everywhere - and going to another well defined format more suitable for reading on a computer, such as text, rtf or html? -- Stephen Thorne Give me enough bandwidth and a place to sit and I will move the world. --Jonathan Lange ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Sun, Oct 26, 2008 at 10:14:52PM -0700, [EMAIL PROTECTED] wrote: how do I do screenshots on the XO? http://wiki.laptop.org/go/Sugar/Quick_screenshot_hack is one method. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Sun, 26 Oct 2008, Hal Murray wrote: 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. 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. 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) I'd like a pdf reader that would recognize multi-column formatting and have a mode so that the up-down arrows go up-down following columns rather than pages. [I'm sure there are a zillion rough edges.] I'd love something like that as well, but even without the autodetection, something that you could set to say 'this document has three columns, with column boundries here and here' that would then take you down the columns would be wonderful. Dvaid Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Sugar unusable as an e-book reader
On Mon, 27 Oct 2008, Stephen Thorne wrote: On Mon, Oct 27, 2008 at 3:22 PM, Hal Murray [EMAIL PROTECTED] wrote: I'd like a pdf reader that would recognize multi-column formatting and have a mode so that the up-down arrows go up-down following columns rather than pages. Surely the solution for reading books is to ignore pdf - a format optimised for serialising text for print such that printing (which the XO doesn't even support yet) works the same way everywhere - and going to another well defined format more suitable for reading on a computer, such as text, rtf or html? only if you have the ability to convert from .pdf to other formats. there is an incredibale amount of material available in pdf format. and since it is so tightly related to printing, it's trivial for publishers to make electronic versions of documents available in pdf as a side effect of their printing process, so the volume is going to continue to grow rapidly. being able to use these documents effictivly is a very important thing. until high-res screens become available (and cheap) in A4/letter sizes, there will be a need to adapt from the pdf to the screen. scrolling vertically through the document works for many things, but not for multi-column documents. David Lang___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
