Page 52 of 72 FirstFirst ... 242474849505152535455565762 ... LastLast
Results 1,021 to 1,040 of 1439
Like Tree10Likes
  1.    #1021  
    Quote Originally Posted by chambee View Post
    Hi Jappus
    Q: How do I reset the Master password for keyring. I set it a long ago and can't remember the password. Thank you for your assistance.
    Chambeecat
    Simply go into the Preferences screen, expand the "Maintenance" group and select "Reset Keyring DB". The pReader will ask you nicely if that is really what you want to do, since it'll blast away your entire Keyring DB. After you've tapped on "Okay", you'll have a shiny new database. As soon as you use the Keyring DB for the next time, it'll ask you for a new password. Simply enter one, and you're good to go.


    Mhhhm, of course, that reminds me that I should probably make it so that it immediately asks you for a new password after resetting the DB. That's probably much more transparent.

    Thanks!
  2.    #1022  
    Quote Originally Posted by jbusnengo View Post
    First, a feature request: I'd love it if I were able to use the volume rocker to flip pages, although it wouldn't surprise me if Palm limited applications' access to the volume rocker.
    Yup, several users have voiced their support for that feature, even as early as v0.5.x, the very first versions I've released openly.

    So I of course looked into the topic, and I found out that, yes, I could intercept the volume toggle keys. The downside is just that WebOS relays key-press events after it has internally dealt with them. So even though you could use them as page-flip keys, you'd also change the volume with each press. That makes this feature virtually immediately useless and is why I know of no other app which actually intercepts the volume keys.

    Of course, the reason for that is clear: WebOS is a full multitasking OS. No application should be able to do something, which blocks an essential feature of the device, like toggling the volume. After all, it'd make for a sort of broken user interface, if the volume keys worked only most of the time.

    Unfortunately, I've also had a few problems with pReader. I have a library of 400 or so books, the vast majority of which are in Mobipocket .mobi/.prc format (many of which were originally converted from .pdf). I made the mistake of trying to add them all to my pReader library. After I finally got through all of them, I was dismayed to discover that my pReader library only retained about 150 of them. I tried adding a few dozen of the ones that were missing. Things looked good at first. There were about 200 in the library, but when I quit and restarted the program, I was back down to around 150. (I don't remember the exact number, but I don't believe it was the same as before.)
    Mhhhm, that sounds less like a problem with the library, but rather like a problem with the code that displays the list.

    There's an easy way to check if that's the case: Simply enter part of the name of a book you know you've added. The pReader should restrict the list of books to those that match that phrase. If your book appears, then it's a problem of the list display code. If not, then it's a problem with the library code.

    If you could determine that for me, I'd be much obliged. The reason is that it only makes sense to fix the former of those bugs, because the code for the library itself will get redone anyway for the native v0.9.0 version.


    Of course, the bad news with re-doing the library code is that you'll most likely lose your entire library when you upgrade from v0.8.x to v0.9.0. But the good news is that v0.9.0 will get a bulk-import feature. No more adding books manually, one after another. You'll be able to select a directory and simply say: "Please import all compatible books from this directory". If I find a good way to do it, I'll probably even add the option to only import new books.

    The other problem I've had has been with DRMed Mobipocket files. pReader just wouldn't open them, even if supplied with the correct device ID. I was able, however, with the MobiDeDRM script (v0.1.2) to remove the DRM with by passing it same device ID.
    Mhhm, that really does sound like a serious bug, or rather, it's most likely that you've discovered a version of the Mobipocket DRM that we don't support yet. It'd be really great if you could send me such a file, and the device ID that goes with them.

    I've sent you my E-Mail address via PM.


    Thanks!
  3. #1023  
    Kindly update the difference between kindle prewier & ipad view......
  4.    #1024  
    Quote Originally Posted by baskaran View Post
    Kindly update the difference between kindle prewier & ipad view......
    Difference? I'm sorry, but apart from knowing that one's made by Amazon and the other by Apple, I don't know what you're getting at.

    Can you (or someone else) explain to me what you mean?
  5. #1025  
    Hi Jappus,

    In your reply to jbusnengo above, you mentioned an import all function. Does that mean the native version will still have to import documents instead of directly reading them?

    Also a silly question about mobi formatted docs. I have several non DRMed (never been DRMed) mobi books from Baen. When I open them, I'm given a plain text / html requestor. If I select plain text, the formatting is strange - some paragraphs are in the large font I have selected & some are in small font. It's always complete paragraphs, not fragments. If I select html, all paragraphs are in the large font. Is this normal behavior? Should you always select html for mobi documents? If so, is there really any reason for the plain text / html requestor?

    Thanks and viva la thesis
  6.    #1026  
    Quote Originally Posted by govotsos View Post
    Hi Jappus,

    In your reply to jbusnengo above, you mentioned an import all function. Does that mean the native version will still have to import documents instead of directly reading them?
    Yup, but the import process should be much faster.

    If the pReader read only a single format or so, direct reading would be the sane thing to do. But unfortunately, every additional format includes a new pitfall that needs to be especially optimized for to support reading.

    For example, MobiPocket books are pretty much useable as is, only a few tags need to be filtered out; with one massive exception: The link format specifies the target as an absolute byte offset into the file. That means, if a user clicks on a link, we'd need to throw away all data about any tags we've gathered, read everything up to that position to ensure that we know which tags were opened before that position and then start reading from there. If it was the only format we supported, we could create an index and be good.

    Unfortunately, we also support the eReader format, which isn't ready-to-use HTML and instead has custom tags that are escaped with a backslash. So to utilise that we have to convert those tags to HTML and then again need to figure out which tags are open at what spot. Again, we'd need an index, but with a slightly (and thus wholly incompatible) way of storing where and what the tags are.

    And then we have the PalmDOC format, which is just plain text, but can also include HTML markup. But there, the links are specified with fixed IDs, whereas the images are referenced as record numbers. Thus, to use those images, we have to decode that tag and splice-in the data from those records appropriately. Thus, we need an index of tags AND images.

    But wait, there's also the ePub format, which uses an XML file to describe the metadata and correct order of files, where links and images are ID-referenced, but the link-IDs can only be learned by parsing all XML files, whereas the image-IDs are referenced in the XML file. But at least the HTML is directly usable ... as long as we index it with what file begins with what set of open tags, because the books are split into several files, often along chapters, but also just as often at arbitrary sizes (like, every 100 kB of text).

    And then, we shouldn't forget the FictionBook2 format, which is one big XML file, including images, text, links and everything else. So we need to parse it all to make any sense of the file and actually figure out where which image is stored.

    And don't get me started on regular HTML, which may be a combination of ALL of the above. Images might be stored directly in the text, or might be referenced as an outside file. Links might target fixed positions, special < a > tags or any other named tag.

    Ohh, and I deliberately ignored the issues created by the DRM and compression schemes.

    Believe me, the only way to preserve any sort of sanity while keeping any sort of speed, is to convert everything into a single, sanitized, standard intermediate format which can be easily indexed. Also, if we ever add new formats, all we need to implement is a reader that turns the format (be it PDF, Plucker, CHM, LIT, whatever) into "our" intermediate format. We don't need to care to make the readers fast for random, arbitrary access. All they need to optimize for is a single reading stage where it extracts all images, text and metadata.

    Thus, this approach keeps the both the input and output stages simple and clean, because both only need to read from or write to a single format. And since we control the intermediate format, we can ensure that that format provides fast access to everything we need, irregardless of the silly restrictions introduced by each of the different formats.

    Of course, the obvious downside is that we create a copy of everything we read. But given that most books are around 0.5-10 MB large, I think that's a fair trade-off, especially because you don't need to keep the original on your device after having added it.


    Also a silly question about mobi formatted docs. I have several non DRMed (never been DRMed) mobi books from Baen. When I open them, I'm given a plain text / html requestor. If I select plain text, the formatting is strange - some paragraphs are in the large font I have selected & some are in small font. It's always complete paragraphs, not fragments. If I select html, all paragraphs are in the large font. Is this normal behavior? Should you always select html for mobi documents? If so, is there really any reason for the plain text / html requestor?
    Huh? The plain-text / rich-text question should only pop up if the pReader thinks that the file's a PalmDOC file. So my best guess is that your MobiPocket file's actually telling the pReader that it really is a PalmDOC file by specifying "TEXtREAd" as its type/creator ID.

    Of course, if it does that even though it's really in the MobiPocket format, the pReader chooses the wrong importer which processes the file wrong and causes general mayhem inside the text. If you could send me one of those files, I could take a look at it, and see if I can do something to detect such wrongly typed files.
  7. #1027  
    Ok, downloaded just fine, start the app and all I get is a white screen. The menu is not active and I have let it set and it never comes back.

    I deleted it rebooted, redownloaded and installed, same problem, Suggestions?

    Att based Palm Pre+ 1.4.2 os version
  8.    #1028  
    Quote Originally Posted by sdunt View Post
    Ok, downloaded just fine, start the app and all I get is a white screen. The menu is not active and I have let it set and it never comes back.

    I deleted it rebooted, redownloaded and installed, same problem, Suggestions?
    Mhhhm. The only thing I could imagine that'd help is if you connected your Pre to your PC, and deleted the following folder:
    ".app-storage/file_.media.cryptofs.apps.usr.palm.applications.com.mhwsoft.preader_0"

    This should remove any trace of defective settings. If that doesn't work, I've got no further ideas. Even as developers, we have no influence whatsoever on the installation process. Every once in a while, a user can't download or install the pReader and there's not much that we can do about that, except advise him or her to write Palm about it.

    In your case, I guess that the installation simply encountered some sort of problem which caused it to write junk data without causing the installation to fail, and without allowing the deinstallation routine to clean up that mess.

    So, if my above help doesn't help, and no other user experiences the issues you describe, I guess that the best option is to contact Palm. They might just be able to help you.


    P.S: You could also try to install the ipk file that's linked to in the first posting of this thread. Just use WebOS Quick Install, InternalZ, FileCoaster, PreWare or any other tool that's able to install ipk's directly.
  9. #1029  
    I don't kwow what I did when I copied files to the USB drive, but preader and google maps and ATT maps would not come up on my phone.

    I did a full reset, aka cleared the USB drive and things are working now.

    I was very careful this time in copying only by 'books' over. I was copying from a Win Doze mobile device and may have over written something the 1st time.
  10. #1030  
    I just started using pReader and it is a very good application. I noticed when you select add books to library, kindle format is available.
    How would I purchase from Amazon and be able to read it on me Palm Pre?
    Amazon does not have any place to register the palm or any info in their help files.
    TIA
  11. #1031  
    Quote Originally Posted by Brighton Line View Post
    How would I purchase from Amazon and be able to read it on me Palm Pre?
    Well, the Amazon kindle AZW format is supported (it is no different from the Mobipocket format other than the file extension), but we do not support files with Amazon DRM. To make these files compatible with pReader, you need to execute a De-DRM script. If you use a google search, you can find instructions on how to do this.
  12.    #1032  
    Good news, everyone!


    I've just submitted v0.8.12 to the App Catalog. Here are the changes:

    • Fixed the bug that caused the small progress bar to be overfilled or not filled completely
    • Added "Courier New" to the default fonts.
    • Implemented a missing MobiPocket DRM scheme. Now, all their DRMed files should work. This includes the "free" books that use a preset key for encryption.
    • Fixed a long standing bug that caused the pReader to ignore the screen rotation when you rotated the device before opening a book. No, rotation should work immediately.
    • Fixed a bug that caused the screen to not refresh properly after rotation or change of the text display properties.


    If I don't notice any further easy-to-fix bugs, this will most likely be the last pure Javascript version.

    ... Of course, I also said that about the last 3 or 4 version.


    Anyway, happy reading!
  13. #1033  
    Yaay!
    Thanks Jappus!
  14. #1034  
    Quote Originally Posted by Jappus View Post
    Good news, everyone!


    I've just submitted v0.8.12 to the App Catalog. Here are the changes:
    Hmm, can't see the new one in European App catalog. Hope it will come
    Thank you anyway!
    Regards,
    Krecony
  15.    #1035  
    Quote Originally Posted by krecony View Post
    Hmm, can't see the new one in European App catalog. Hope it will come
    Yeah, with Palm's App Catalog, there's a difference between submitting the app, and it actually being released.

    Much like the Apple Appstore, each application that's submitted by a developer to the main Catalog (that is, not to the Beta or Web Feeds) is vetted by Palm employees. If they don't see any obvious problems, they release it. Depending on their work load that can take a few days.

    Of course, contrary to Apple, Palm has no funny rules about what kind of apps are allowed. They allow everything that uses the public SDK and is not outright malicious.
  16. #1036  
    It has appeared today's morning
    Regards,
    Krecony
  17. #1037  
    Wonderful work
    I feel a little foolish asking this, but what is the Keyring/Keyring Manager? What's its function? Also, when I open the application on my Pre and choose to see all, I can't tell which have already been added to my library. As a test, I've downloaded the same book in multiple formats and I don't know if I'm overwriting a previous version or not. Can the library contain the same book in multiple formats and, if so, how would you distinguish them. As a general rule, should I delete the book once I've added it to the library to save memory and avoid later confusion.

    This is great work you're doing. HP would be lucky to have you
  18.    #1038  
    Quote Originally Posted by dcurran1 View Post
    Wonderful work
    I feel a little foolish asking this, but what is the Keyring/Keyring Manager? What's its function?
    There are no foolish questions. People only call questions foolish, to distract from the fact that they obviously haven't explained things right.

    Anyway, the Keyring is an encrypted password/device ID storage. Many people get their DRMed eBooks from multiple sources, with each DRM scheme requiring a different way of authenticating yourself. For example, eReader files use your name and credit card number; whereas MobiPocket uses unique Device IDs.

    Since most users don't want to enter those details again and again, the Keyring allows you to securely store them and protect them with a single password. That way, you only need a single password for all your DRMed files.

    Also, when I open the application on my Pre and choose to see all, I can't tell which have already been added to my library. As a test, I've downloaded the same book in multiple formats and I don't know if I'm overwriting a previous version or not.
    Currently, the pReader is a pure Javascript application (that's also why import is so slow). As such, it is completely restricted by the Javascript API. One such restriction is that it may only access files and their locations through Palm's own "File Picker" widget.

    Unfortunately, that file picker widget is pretty much the epitome of bad design. It doesn't display folders, but instead displays all the files on your disk at once. It does not allow sorting and only the most basic filtering. We as external developers can do absolutely nothing about that. That means that I can't hide the files that you've already added, because I have no control over the File Picker.

    Fortunately, that's all going to change during the transition to native code. It will finally allow me to whip up a truly usable file explorer and your suggestion has just made it onto my internal "ToDo" list for the native version.

    Can the library contain the same book in multiple formats and, if so, how would you distinguish them.
    Yes it can. During import of the file, a somewhat unique ID is created.
    For TXT, HTML and FB2 files, the filename (plus extension) is used. If two files have different file names (folders are ignored, only the filenames count), you can add them side-by-side, even if they have the same content.

    Since eReader, MobiPocket and EPub files have an easy-to-decode "name" field, that is used instead of the filename. Since all three formats have slightly different ways of encoding that name, you usually won't see any collisions there. Of course, if you add a a book just called "Love", you might run into problems if you have it in more than one of those three formats.


    To make a long story short, the answer is: It depends. Normally, you will be able to add books from multiple formats, but a collision can't be completely excluded. If push comes to shove, the older import will simply be overwritten.

    As a general rule, should I delete the book once I've added it to the library to save memory and avoid later confusion.
    Yup, you can do that if you want. The pReader creates an internal unified copy of the file anyway (it greatly, greatly, greatly simplifies things) and won't access the original after import anymore. Only if you want to re-import a file, you'll need the original again.


    Of course, if you still have plenty of space left, and just don't want to see those files in the file picker, there's a kind of sneaky, if ugly workaround. Simply change the extension of the file to one the pReader does not filter for. For example, if you added the file "Dante's Inferno.txt", simply change its suffix like that: "Dante's Inferno.txtZ". The result: Palm's File Picker won't list it anymore.

    By the way: You can use InternalZ to do that even without connecting your device to a PC.

    This is great work you're doing. HP would be lucky to have you
    Of course they would.

    Unfortunately, Palm/HP's R&D centers are almost exclusively situated in the US. But since I'm a German and not exactly keen on the bureaucratic nightmare that's getting a US visa -- or the prospect of emigrating that far away, I think they'll have to do with me freelancing and doing all their dirty work at no cost at all.
  19. #1039  
    Thanks, for such a precise response . If and when HP comes up with a slate/tablet for WebOS, will it be straightforward for you to port pReader to that device? I, and I hope the rest of the world, appreciate that you're making so much literature available to so many.
  20.    #1040  
    Quote Originally Posted by dcurran1 View Post
    Thanks, for such a precise response . If and when HP comes up with a slate/tablet for WebOS, will it be straightforward for you to port pReader to that device? I, and I hope the rest of the world, appreciate that you're making so much literature available to so many.
    It should be as simple as making sure that the UI also works with the higher resolution of such a device. Everything else should either work directly (the Javascript part) or just be a matter of recompiling for a new CPU (the future native C++ part).

Posting Permissions