Page 20 of 72 FirstFirst ... 1015161718192021222324253070 ... LastLast
Results 381 to 400 of 1439
Like Tree10Likes
  1. #381  
    Hey Jappus,

    Thanks for the prompt response - I can send you the file I'm reading currenty that is having the punctuation code issues, along with the unlock info. I wasn't able to find a way to attach the file via PM so PM me a valid email and I'll send it all asap.

    Also - did try changing the encoding without deleting the file - had no effect. Maybe I need to redownload the files from fictionwise/ereader and start "fresh'?
  2. #382  
    I have searched this forum and have not found the answer, so I hope I am not duplicating the question. I have v0.74 which I downloaded via Preware and I have downloaded a Mobipocket book after adding the Device ID to the Mobipocket site. I added the book to my library on the Pre. Opens normally, but after a few pages in, I see formatting characters at the top (< Atrong> and <83fp heaight="0em"> of each page for the rest of the book. Also, the book text flows in to each page starting about of the third of the way down the page. See screenshot

  3.    #383  
    Quote Originally Posted by padraic526 View Post
    I have searched this forum and have not found the answer, so I hope I am not duplicating the question. I have v0.74 which I downloaded via Preware and I have downloaded a Mobipocket book after adding the Device ID to the Mobipocket site. I added the book to my library on the Pre. Opens normally, but after a few pages in, I see formatting characters at the top (< Atrong> and <83fp heaight="0em"> of each page for the rest of the book. Also, the book text flows in to each page starting about of the third of the way down the page.
    Mhhhm, yeah, I can see where the problem is. You see, each MobiPocket file spans several records. Units of text which are independently stored and compressed. What seems to happen here, is that the pReader's HTML parser seems to have problems when there're still open tags when one record ends, and another one starts; and especially if a tag itself (like <p align="center">) is split, with one half ending up in the first record, and the other in the second one. And why does it still usually work? Well, because the MobiPocket standard says that at least the latter shouldn't happen at all. But it seems it does anyway. So much for standards...

    The next version ought to fix that. Unfortunately, you will have to reload the file to fix that then.
  4. #384  
    I'm glad you understand it. I'm also pleased that 0.74 gets me closer to being able to finally retire my Blackberry, whose sole purpose now is to be an ebook reader, in favor of my Pre. I look forward to the next version of pReader.
  5.    #385  
    Okay, I seem to have fixed the problem. The pReader will now be both a bit more careful, and a bit more paranoid (as in, it will drop every tag it doesn't know) as far as MobiPocket files are concerned.

    Of course, if the HTML that's stored in the files is broken enough (unbalanced tags, trailing open quotes in tags, etc. pp.) the formatting will most likely still suffer. For example, if your file contains an unclosed <b> right at its start, then the pReader will interpret that literally. It will bold the entire remaining text, right up till the end. But at least, now those files can be read without broken tags appearing on top of the page.


    As soon as I've accumulated a few more fixes and/or feature implementations (I look at you, HTML images), I'll release v0.7.5.
  6. kuoirad's Avatar
    Posts
    204 Posts
    Global Posts
    340 Global Posts
    #386  
    Jappus/retrobits:

    Have a feature request for you guys. My searching of this thread did not turn up any hits about this, so I think it's new.

    It would be nice if there was a way to export the library database ("installed" books, positions, altered metadata) to a file, either to be placed in /media/internal or emailed or something.

    Alternatively, if possible, have the library "live" somewhere where a partial erase wouldn't touch it.

    I had to do a partial erase of my phone last night to fix a problem or two, and while this isn't (to me) a problem, per se, it is an annoyance. I had the same issue with Dr. Podder, though I just didn't know about it's ability to export the feeds to xml to be reimported later.

    Hopefully some or all of this general annoyance can be resolved when someone (Jason Robataille, maybe?) puts out a real backup program, but until then...

    Cheers!
  7.    #387  
    Quote Originally Posted by kuoirad View Post
    Jappus/retrobits:

    Have a feature request for you guys. My searching of this thread did not turn up any hits about this, so I think it's new.

    It would be nice if there was a way to export the library database ("installed" books, positions, altered metadata) to a file, either to be placed in /media/internal or emailed or something.
    That's indeed a very good feature request. But at the moment, I want to wait till Palm openly releases the Native SDK, so that we can write it to a properly portable format. I'm thinking of a zipped collection of MHT files, since that allows us to condense metadata, images and everything else into a single file per book, and a single file per library -- all of which will be readable even on your PC.

    At the moment, the Javascript SDK offers no clean way to export stuff to the disk. But as soon as the Native SDK appears, an exporter and importer will be extremely trivial to implement.

    Alternatively, if possible, have the library "live" somewhere where a partial erase wouldn't touch it.
    Unfortunately, that currently isn't possible with the current API, because the association of database names to the real file names of the databases is stored within the area of storage that's affected by a partial erase.

    The problem runs as follows, as far as I understand it:
    When I tell the API to create a new SQLite DB for me, WebOS picks a new filename for the DB, puts it onto the media-disk and stores the name<->file pair in a local storage.

    Now, when you update the app, there's no problem, since it keeps the name<->file associations. But if I delete the app, WebOS (sometimes) seems to delete that information, so that when I try to open a DB with that name, it notices that there's no match and I have to create a new one, instead of opening the old one.

    This did not affect the Mojo Depot API that I used before v0.7.0, because that one always generated the same file names for a given Database name, and thus opened the correct file even when no association was stored. But that doesn't seem true with SQLite files, which is why you lose the library on a partial delete, even if all the data's still there on the media-disk.

    The whole DB interface is simply broken; not as much as the Mojo-Depot interface, but that hardly means much, since the latter is basically an enormous black hole of total suckage.


    In other words: If I don't find a brilliant workaround (and I keep searching for one), we'll have to wait for the release of the Native SDK in March to fix it.
  8. kuoirad's Avatar
    Posts
    204 Posts
    Global Posts
    340 Global Posts
    #388  
    Jappus:

    Fair enough. Thanks for the detailed explanation.
  9. #389  
    Theme Request - ARIZONA CARDINALS!!!!!!
  10.    #390  
    Quote Originally Posted by Chadney View Post
    Theme Request - ARIZONA CARDINALS!!!!!!
    Okay, that was ... random.

    What was that old saying again? "Five exclamation marks, the sure sign of an insane mind."

    So what does it say, if there're six?
  11. JerryG's Avatar
    Posts
    535 Posts
    Global Posts
    553 Global Posts
    #391  
    Quote Originally Posted by Jappus View Post
    Okay, that was ... random.

    What was that old saying again? "Five exclamation marks, the sure sign of an insane mind."

    So what does it say, if there're six?
    Uh, an insanely great mind?

    NAAAAAAAAAAAAHHHHHHHHHHHH!!!!!!

    -JerryG
    Uniden PC100 -> Visor -> Visor Pro w/VisorPhone -> Tungsten T -> Tungsten T2 -> Tungsten T5 -> TX -> Treo 650 -> Treo 755p -> Pre -> Evo 4G
  12.    #392  
    Good news everyone!

    I've just updated the pReader to version 0.7.5.

    We've fixed the importer for MobiPocket files, which means that they should be displayed cleaner now. There should be no more dangling tags at the start of the page, for one. Of course, you'll have to re-import the affected files for the fixes to apply to them; but if you don't have any problems, you don't need to re-import.

    Furthermore, as promised, loading images from HTML files now works properly. Loading very large files will fail though, but that's a limitation of Javascript which can't be really worked around; so they will remain a problem till Palm releases the Native SDK.

    But the most major change is the ability to search your books for any phrase or regular expression. Do note that it is the very first incarnation of this feature, so if you find bugs, please report them, and if you have ideas how the search interface can be made more intuitive/beautiful/better, please tell us too.


    Ohh, and yeah, this version 0.7.5 will (hopefully) be the first one that appears in the App Catalog. I've just sent it in to Palm for review. I intend to keep both the official App Catalog and the PreCentral catalog in sync, since they don't interfere with each other, as far as I can see.



    In any case: Happy Reading (and Searching )!


    P.S:
    Due to the pending submission to the AppCatalog, PreWare might get confused about which version to display, the Homebrew one, or the not-yet-published one from the App Catalog. If it doesn't allow you to update, you might have to disable the feeds from Palm and have to restart PreWare to update pReader to 0.7.5.
    Last edited by Jappus; 01/24/2010 at 05:35 AM.
  13. #393  
    Quote Originally Posted by Jappus View Post
    Good news everyone!

    I've just updated the pReader to version 0.7.5.

    We've fixed the importer for MobiPocket files, which means that they should be displayed cleaner now. There should be no more dangling tags at the start of the page, for one. Of course, you'll have to re-import the affected files for the fixes to apply to them; but if you don't have any problems, you don't need to re-import.

    Furthermore, as promised, loading images from HTML files now works properly. Loading very large files will fail though, but that's a limitation of Javascript which can't be really worked around; so they will remain a problem till Palm releases the Native SDK.

    But the most major change is the ability to search your books for any phrase or regular expression. Do note that it is the very first incarnation of this feature, so if you find bugs, please report them, and if you have ideas how the search interface can be made more intuitive/beautiful/better, please tell us too.


    Ohh, and yeah, this version 0.7.5 will (hopefully) be the first one that appears in the App Catalog. I've just sent it in to Palm for review. I intend to keep both the official App Catalog and the PreCentral catalog in sync, since they don't interfere with each other, as far as I can see.



    In any case: Happy Reading (and Searching )!


    P.S:
    Due to the pending submission to the AppCatalog, PreWare might get confused about which version to display, the Homebrew one, or the not-yet-published one from the App Catalog. If it doesn't allow you to update, you might have to disable the feeds from Palm and have to restart PreWare to update pReader to 0.7.5.
    Okay, I just don't know what to say. This was already a great app. I can't believe you actually made it better. This is better than good news. This is great news!!!

    Being able to read MobiPocket books and see the beautiful covers. I don't know. Getting e-reader with their great prices was one thing, but opening up my MobiPocket books to and making them lovely to read, You've made my year and it's only 1-24-10. Thank you, thank you, thank you!
  14. Quintus's Avatar
    Posts
    624 Posts
    Global Posts
    672 Global Posts
    #394  
    Jappus,

    I've tried to download the update via Preware (disabling Palm feeds) but it does not appear as an update. Tried using FileCoaster and although it shows up as an update, I receive an "error" message whenever I try to downlowd from there or it hangs on the downloading screen forever. I tried using PreLoader and it doesn't even show up as updated.

    Something has clearly gone wrong in the update process.
  15.    #395  
    Quote Originally Posted by Quintus View Post
    Jappus,

    I've tried to download the update via Preware (disabling Palm feeds) but it does not appear as an update. Tried using FileCoaster and although it shows up as an update, I receive an "error" message whenever I try to downlowd from there or it hangs on the downloading screen forever. I tried using PreLoader and it doesn't even show up as updated.

    Something has clearly gone wrong in the update process.
    Sounds eerily familiar to what happened to the Popelli-Reader when it moved from PreCentral to the App Catalog. It seems as if something subtly breaks for the Package manager, as if it has problems with handling two identical versions from different sources ... and the Palm App Catalog version isn't even released yet!

    And now, if I deactivate the Palm App Catalog feeds in PreWare, not even the description or icon shows up properly (but it somehow worked earlier, when I tested it). So much for compatibility. I'll look into it and see if I can get it to work somehow.

    [EDIT]
    Okay, I've just deleted the pReader from my Pre, and noticed that as soon as its gone, PreWare stops listing the pReader altogether, even when I deactivate the Palm feeds. Obviously, when the feed for PreCentral is generated, it checks if the App appears in the official Palm Feed, but it doesn't care whether it's actually released or not. It just checks if it appears. And whenever it does, it does not include it on the PreCentral feed.

    So basically, the pReader isn't on the PreCentral feed, because it's present on the Palm feed.
    But at the same time, it's hidden in the Palm feed, because it is not yet reviewed by Palm. Which leads to the App completely vanishing.

    What a joke.

    So basically, there's only so much I can do. I could either delete my request for inclusion at Palm, which might remove it from the Palm feed and make it appear on the PreCentral feed. Or I might bump the version to v0.7.6, which might lead to it being included on the PreCentral feed, but I don't know what will happen once Palm releases the then-outdated v0.7.5.

    Or I just wait, and hope that as soon as it's released by Palm, it'll work again. Of course, this would make the listing on PreCentral absolutely moot, even though it updates immediately, instead of after ~a week which I expect Palm will take for every update.

    In other words, I'm asked which door I want to take, the one with the tiger, the one with the lion, or the one with the leopard.


    Well, at least manually updating with WebOS-QuickInstall still works. Whatever good that may yield.
    Last edited by Jappus; 01/24/2010 at 09:10 AM.
  16. Quintus's Avatar
    Posts
    624 Posts
    Global Posts
    672 Global Posts
    #396  
    Classic from Motion Apps released two identical versions of their software, one for US and the other from outside of the US. They had to name them differently for it to work. The US users saw "Classic" and those outside the US saw "Classic Emulator". Both programs were identical but on different feeds.

    Maybe you need to rename your app in the App Catalog in order to preserve both feeds. Maybe pReader Pro for the App Catalog and just pReader for homebrew. Just a thought.
  17.    #397  
    Quote Originally Posted by Quintus View Post
    Maybe you need to rename your app in the App Catalog in order to preserve both feeds. Maybe pReader Pro for the App Catalog and just pReader for homebrew. Just a thought.
    Mhhhm, as long as only the displayed name is changed, that wouldn't be a problem. But I guess, I'd also have to change the app's real name (com.mhwsoft.preader), and that's a massive problem, since WebOS uses that name to decide where to store the app's databases.

    That means, that when I rename the app, the user loses his or her library, which I really, really, don't like to do.

    As I said, all the solutions I've come up so far suck, only in different ways. At the moment, I think the best solution is to wait a bit till Palm either publishes or refuses the app. But if that takes more than a week from now, I'll have to find another solution.


    In the meantime, I've written Dieter a PM, to ask him whether it's possible to include the pReader on the PreCentral feed, even though it's also halfway on the Palm feeds. :-/
  18. #398  
    Quote Originally Posted by Jappus View Post
    Mhhhm, as long as only the displayed name is changed, that wouldn't be a problem. But I guess, I'd also have to change the app's real name (com.mhwsoft.preader), and that's a massive problem, since WebOS uses that name to decide where to store the app's databases.

    That means, that when I rename the app, the user loses his or her library, which I really, really, don't like to do.

    As I said, all the solutions I've come up so far suck, only in different ways. At the moment, I think the best solution is to wait a bit till Palm either publishes or refuses the app. But if that takes more than a week from now, I'll have to find another solution.


    In the meantime, I've written Dieter a PM, to ask him whether it's possible to include the pReader on the PreCentral feed, even though it's also halfway on the Palm feeds. :-/
    It's not really that bad. Remember all of us can use QI to install. Since you post the updates on the first page, it's not a major issue and since everyone had to use QI or another method to install Preware, it'll be fine until there is a difference in the number between the catalog and the homebrew.
  19. conum's Avatar
    Posts
    338 Posts
    Global Posts
    339 Global Posts
    #399  
    Quote Originally Posted by Jappus View Post
    That means, that when I rename the app, the user loses his or her library, which I really, really, don't like to do.
    the maker of shopping manager has a solution for his app (it's in app-catalog, a demo is also in app-catalog and a beta on preware). see how:
    Shoppingmanager/beta/english - VivaLV-Software
  20.    #400  
    Quote Originally Posted by conum View Post
    the maker of shopping manager has a solution for his app (it's in app-catalog, a demo is also in app-catalog and a beta on preware). see how:
    Shoppingmanager/beta/english - VivaLV-Software
    Yeah, that is a solution and it works for the Shopping-Manager. Unfortunately, this solution has a massive drawback: It only works for a single file.

    Unfortunately, the pReader uses more than one file, due to the amount of data it needs to store. The current layout is like this:
    1. One central file for the library metadata; what books you have, their bookmarks, the reading position, etc. pp. The most important thing: This file contains the unique database name (not filename!) for every book you've loaded; this is the link to the actual data of the book.
    2. For each book, a single file that stores the data. Its database-name is the one stored in the above file. Its filename is randomly chosen by WebOS


    For the first file, everything's still okay. Every app generates a new, random name for the first file and creates it. You could copy that file over and rename it, and pReader would use the new file. You could look at your library, edit the metadata and so on.

    Unfortunately, when you actually attempt to open a book, pReader reads the unique database name and asks WebOS if it knows the DB associated with that name. Unfortunately, since it's a wholly different app, WebOS knows zilch, since it has never seen such a file.

    The only hope I'd have is to create that file, whereupon WebOS generates a new filename. Then I'd have to tell the user to please copy & rename the old file to match that filename. Only then could I read the bulk data.

    And this would have to be done for every book in your library. In other words, just reimporting them would be a millionfold faster; especially because you can't actually know which file contains what book data, since it's not stored in the file. You'd even have a hard time to tell apart the metadata file from the book data files.


    The DB API of WebOS simply sucks. This is why I have no chance to export or import the library with the current Javascript SDK, and why an app renaming would immediately bust your library.



    But thanks, anyway. I really do appreciate the help.

Posting Permissions