Page 10 of 72 FirstFirst ... 567891011121314152060 ... LastLast
Results 181 to 200 of 1439
Like Tree10Likes
  1.    #181  
    Quote Originally Posted by rlanza1054 View Post
    I did find some things that looked a little funny. I don't know if I should report that stuff or not?
    Yes, if you notice that something is off, please report it. Otherwise we won't know what to fix, since our test cases certainly won't cover everything. Additionally, if you've got problems with or feature requests for the User Interface, don't be afraid to post them. I wholly admit that personally I'm a very frugal eBook user. Give me a forward button, and a back button, and I'm happy.
    As such, I often overlook ways to make things easier; just look at the Belt Bar example above.


    I would also like to know about the 'Category' option that I see that does not appear to work right now.

    I wanted to use that to create catagories such as where I purchased the books from, such as a catagory for eReader Books, Mobipocket Books, or Library Books.
    Yeah, I know that selecting the category isn't exactly obvious. The final version will include help section to cover that.

    At the moment, please read this posting, in which I explain just how the Metadata editor and the category feature works.

    To make long story short: Tap & Hold the book for which you want to create a category, select the "Edit metadata" button in the context menu, scroll down a bit to "Category" and enter your desired category name (tap & hold to see a list of preset/entered categories). Leave the editor with the back gesture. That's it.

    Also, will there ever be support for eReader's Dictionaries.

    I had purchased about 3 dictionaries from eReader and when you want to use one on eReader it would open a separate window and let you type in the word you want to look up. I think it would also look up a word that you have selected, but I don't remember exactly how that worked without running it on my old Treo.
    Mhhhm, adding support for them is probably possible, as long as we can find good documentation for their format, so I guess we'll eventually add it.

    But since their use is quite different from normal eBooks, we'll probably first implement a few other eBook (ePub, Plucker, Lit) formats before approaching the eReader dictionary format.
  2.    #182  
    Quote Originally Posted by bdhu2001 View Post
    Thank you for your quick response. I don't see a donate button on the thread. Do we just wait until you have it available in the catalog. I am unbelievably happy with what you have so far and would like to show my appreciation.
    As I said earlier, I'll think about adding a donation button as soon as I'm happy with the app itself; as soon as it has all the features that I think a good eBook reader needs; as soon as all the ugly corners in its code are done away with (I look at you Mojo.Depot) and as soon as I think that it won't spectacularly explode just because I've overlooked a bug.

    As for the AppCatalog: Of course the pReader will be on it sooner or later, but one thing it certainly will never do: Cost money. It will remain free, not just like in free as beer, but also like in free as speech.

    I firmly believe that reading is an essential right of everyone, and as such, I feel that it's wrong to charge for something that, if you boil it down, does no more than enabling you to use and exercise one of your essential rights.
  3. #183  
    belt is nice. Encoding is not likely to be needed often or on the fly and could be hidden. A clock on the belt would be good -- readers sometimes lose track of time. Do you plan to implement a search function?
  4.    #184  
    Quote Originally Posted by prubin View Post
    belt is nice. Encoding is not likely to be needed often or on the fly and could be hidden.
    The encoding button will indeed not stay on the belt bar for long, because as soon as I implement autoscroll, it will most likely be replaced by the "start/stop" autoscroll button.

    It's presently just a somewhat useful placeholder.

    A clock on the belt would be good -- readers sometimes lose track of time.
    I'm thinking about that too, since the eReader for the old PalmOS has a clock, a battery power display and a lot of other stuff on its belt bar.

    The main problem with the belt bar is that it can only comfortably hold a maximum of 5 or 6 elements. It can contain more, but those will spill out of the screen in non-landscape mode. Therefore, I have to be very conservative with what I put there.

    Additionally, when you're not using pReader in landscape mode, the Palm UI automatically has a clock (and a battery display) on the top border. And as long as you're using the aztomatic tilt-detection, showing the clock is a matter of turning you Pre/Pixi upright.

    I think the best way is to only display a clock when the user's in landscape mode. Afterall, I can dynamically add fields to the bar. I'll see what I can do.

    Do you plan to implement a search function?
    Yup. It was already on my to-do list since the very first release. I've just postponed it because Javascript isn't exactly fast as far as searching through text is concerned.

    The three next big features are image display, text search and auto-scroll. Of course, I probably won't implement them in exactly that order.
  5. Quintus's Avatar
    Posts
    624 Posts
    Global Posts
    672 Global Posts
    #185  
    Quote Originally Posted by Jappus View Post
    The encoding button will indeed not stay on the belt bar for long, because as soon as I implement autoscroll, it will most likely be replaced by the "start/stop" autoscroll button.
    Yeah!!!!!
  6. #186  
    I downloaded a few books from the Baen free library. They are in .prc format. Everything works well but there is a lot of whitespace on the page. Some pages (the definition of a "page" obviously is somewhat arbitrary) have only a single line of text. This makes for quite bit of scrolling. Is there any way to remove that whitespace? Either within the reader or prior to loading it to the phone?

    Also, has the preader now been officially released as the Popelli Reader in the app catalog?

    Thanks for the great reader!

    Michael
  7.    #187  
    Quote Originally Posted by Michael.Brock View Post
    I downloaded a few books from the Baen free library. They are in .prc format. Everything works well but there is a lot of whitespace on the page. Some pages (the definition of a "page" obviously is somewhat arbitrary) have only a single line of text. This makes for quite bit of scrolling. Is there any way to remove that whitespace? Either within the reader or prior to loading it to the phone?
    The answer to that depends on what format the books are in. Because if they are in the MobiPocket format, that behaviour is at the moment somewhat expected.

    The reason for that is that MobiPocket books use a lot of <p> html tags. At the moment, they're ALL translated into two linebreaks. Now, given that MobiPocket puts a <p> around every image, and generally treats <p>'s as line breaks, the books are a bit ... stretched at the moment. But since the MobiPocket parser is currently still a work in progress, that problem will be fixed sooner or later.

    Could you send me a link to the free Baen file? That'd certainly help me as soon as I come around to debug it.

    Also, has the preader now been officially released as the Popelli Reader in the app catalog?
    Nope, there are two eBook readers out there, the Popelli Reader (which used to be the Palm Reader) and this reader here, the pReader. As I said earlier, I probably should've chosen a less ambiguous name.

    The main difference between them is that the Popelli Reader does all its conversion in the cloud. Basically, you send your books to a dedicated server, which reformats the book and returns a simpler format back to the reader.
    The pReader on the other hand does all its conversion on the device, not a single bit is sent over the Net.

    The other main difference is that the Popelli Reader will cost money in two weeks, whereas the pReader will stay free forever.



    P.S.:
    I had an Heureka! moment today. Okay, I didn't run naked through the streets of Syracuse, but I did something better: I implemented autoscrolling. It'll be right there in the next version.
  8. #188  
    That makes sense. I'll be patient.

    Here is a link to the book's page at Baen:

    Pandora's Legions by Christopher Anvil - WebScription Ebook

    It's the Mobi/Palm/Kindle Format that I downloaded:

    http://www.webscription.net/SendFile...D=315&format=P
  9. alanh's Avatar
    Posts
    53 Posts
    Global Posts
    54 Global Posts
    #189  
    BTW, my copy of cryptonomicon (DRM eReader format from fictionwise ~ 1.7 MB) takes about 3 seconds (+-) to change pages on my Palm Pre. Is this typical and expected? is there any way to accelerate this with the current version of the API?
  10.    #190  
    Quote Originally Posted by alanh View Post
    BTW, my copy of cryptonomicon (DRM eReader format from fictionwise ~ 1.7 MB) takes about 3 seconds (+-) to change pages on my Palm Pre. Is this typical and expected? is there any way to accelerate this with the current version of the API?
    No, it should be more on the order of half a second, tops. I'll look into that tomorrow.
  11. #191  
    [QUOTE=Jappus;2084728]The answer to that depends on what format the books are in. Because if they are in the MobiPocket format, that behaviour is at the moment somewhat expected.

    The reason for that is that MobiPocket books use a lot of <p> html tags. At the moment, they're ALL translated into two linebreaks. Now, given that MobiPocket puts a <p> around every image, and generally treats <p>'s as line breaks, the books are a bit ... stretched at the moment. But since the MobiPocket parser is currently still a work in progress, that problem will be fixed sooner or later.

    Could you send me a link to the free Baen file? That'd certainly help me as soon as I come around to debug it.


    Nope, there are two eBook readers out there, the Popelli Reader (which used to be the Palm Reader) and this reader here, the pReader. As I said earlier, I probably should've chosen a less ambiguous name.

    The main difference between them is that the Popelli Reader does all its conversion in the cloud. Basically, you send your books to a dedicated server, which reformats the book and returns a simpler format back to the reader.
    The pReader on the other hand does all its conversion on the device, not a single bit is sent over the Net.

    The other main difference is that the Popelli Reader will cost money in two weeks, whereas the pReader will stay free forever.

    Other difference: Popelli does not do eReader DRM books. Makes it a nonstarter for me.
    Laissez Faire
  12. Quintus's Avatar
    Posts
    624 Posts
    Global Posts
    672 Global Posts
    #192  
    Quote Originally Posted by Jappus View Post
    P.S.:
    I had an Heureka! moment today. Okay, I didn't run naked through the streets of Syracuse, but I did something better: I implemented autoscrolling. It'll be right there in the next version.
    Well, if you're not, I'm going out to run naked in the streets!!! HEUREKA!!!!
  13. #193  
    I love what you've done with this. Thank you so much.

    How difficult is epub likely to be eventually?

    and congrats on your getting a decompressor running in pure javascript. Not only was the source you worked from transparent, so is YOUR code. Amazing.

    You may be surprized when you get around to doing search. We were. I admit that simple Big Book is using straight html files, but we were astounded with how FAST search turned out to be. (for all practical purposes, instantaneous)

    anyway, thanks again.

    Rick
  14. #194  
    Procrastinated around enough and finally d\l'ed on the Pre.....KICK A**!! I love it. I always had Palm Reader on my Treo's and regularly had 4-5 ebooks at any one time, mostly free but a couple purchased from fictionwise & palm gear back in the day. I currently get 95% of my ebooks from Ebook and PDA Documents for your Handheld from Memoware - Free! and I have even browsed and downloaded from the site directly to the Pre.

    (P.s. they have books in 4-5 diff formats usually plucker, iSilo, mobi, palm, etc. so you could likely grab samples of additional formats from there.
  15. #195  
    Quote Originally Posted by Jappus View Post
    As I said earlier, I'll think about adding a donation button as soon as I'm happy with the app itself; as soon as it has all the features that I think a good eBook reader needs; as soon as all the ugly corners in its code are done away with (I look at you Mojo.Depot) and as soon as I think that it won't spectacularly explode just because I've overlooked a bug.

    As for the AppCatalog: Of course the pReader will be on it sooner or later, but one thing it certainly will never do: Cost money. It will remain free, not just like in free as beer, but also like in free as speech.

    I firmly believe that reading is an essential right of everyone, and as such, I feel that it's wrong to charge for something that, if you boil it down, does no more than enabling you to use and exercise one of your essential rights.
    I have to say this is one of the best readers I've used on just about any platform. Your commitment to keeping it free when anyone on this thread would happily pony up cash is very much appreciated. I for one will happily hit the "Donate" button when it arrives.
  16.    #196  
    Quote Originally Posted by rboatright View Post
    How difficult is epub likely to be eventually?
    Well, the format itself is somewhat trivial, since it's not particularly more than HTML with a few additional tags. All we'd have to do is to strip/translate some of the tags and the format will display.

    The main problem with ePub is not the format, but rather the container: It's compressed in a ZIP file. That means that 99% of the work of getting ePub to run is to write a ZIP Decompressor. Unfortunately, ZIP is a good deal more complex than Inflate and as such will most likely be dramatically slower.

    Javascript is just not very good at such low-level stuff. It has all the necessary language features, sure, but an interpreted language is just not going to cut it there.

    The easy way out would be to write a Java Service or a NPAPI-based plugin. This would speed up the whole app by several orders of magnitude. Unfortunately, this would immediately mean that the app's not going to get accepted into Palm's own AppCatalog. At least not at the moment. The simple reason for this is that Palm only accepts apps that use the public, documented API. And Java/NPAPI are only "documented and public" for developers like MotionApps, Google and a few others.

    MotionApps for example has struck a deal with Palm that Palm will ship their NPAPI plugin. That's why Classic was possible at all: They do almost nothing in Javascript.

    I already plan on asking Palm whether an exception can be made for the pReader, so that we may also use native/Java code. But to do that, I'd first have to find a way to contact them at all, other than through the developer.palm.com forums, which seem to be mostly ignored by Palm. Additionally, I deem it highly unlikely that they'll respond positively. I mean, they were the ones who decided that a Javascript-only API was good enough for the masses; so I'm not exactly getting my hopes up.

    You may be surprized when you get around to doing search. We were. I admit that simple Big Book is using straight html files, but we were astounded with how FAST search turned out to be. (for all practical purposes, instantaneous)
    Mhhhm, that's good to know.



    P.S.:
    I think I've tracked down the reason for the reported slowness. I couldn't exactly reproduce it for page-changes, but I could reproduce it for opening the files. The main problem is, again the Mojo.Depot API. It appears that whenever you open a Depot-DB, WebOS reads the entire file. Which can take a while given that the Book-DB of the pReader can easily reach several tens of megabytes with even a modest number of books.

    So to recapitulate: The Depot API needs somewhere between 5 and 50 times the amount of space to store anything. It never deletes anything; not even when you delete the app. You can't get a list of what you've stored in your DBs. It always loads the entire DB at once. And so on.

    Ohh, and the best is: Those who developed this traffic accident of an API thought it's good enough to be the only way to store bulk data on WebOS. Who needs files, afterall. I mean, just because access to them is fast, flexible, resource conserving and simple, that doesn't mean anyone needs them, right?

    But enough ranting. Afterall, it doesn't exactly help now, does it?
  17.    #197  
    I've just released version 0.6.5

    It contains the new autoscrolling mode, the option to toggle the belt bar with a tap&hold and some minor fixes.


    Happy reading!


    P.S:
    If you have problems with the page not fitting when you select a text size greater/smaller than 12 points, please remove and reinstall the app. 20 minutes after publishing v0.6.5, I noticed a small copy&paste bug, that I've fixed now. If you don't experience said problem, then you don't need to do anything.
    Last edited by Jappus; 12/09/2009 at 07:17 AM.
  18. #198  
    Great. Is there a way to adjust the speed of the autoscroll?
    Laissez Faire
  19. Quintus's Avatar
    Posts
    624 Posts
    Global Posts
    672 Global Posts
    #199  
    Quote Originally Posted by prubin View Post
    Great. Is there a way to adjust the speed of the autoscroll?
    It's in the preferences menu.
  20. #200  
    Quote Originally Posted by Quintus View Post
    It's in the preferences menu.
    Sorry, I don't see it.
    Laissez Faire

Posting Permissions