Page 42 of 72 FirstFirst ... 32373839404142434445464752 ... LastLast
Results 821 to 840 of 1439
Like Tree10Likes
  1.    #821  
    Quote Originally Posted by Quintus View Post
    Although the kindle books are fully readable in pReader, I have noticed that there are codes which appear here and there as if pReader is unable to interpret them. For instance, chapter changes are not very clean. In addition, text font control does not appear to be available. Each of my Kindle books have different fonts and I can't seem to change them. One has bold italics, the other has normal. My preference settings are set to Bold Regular. Although these settings work great for ereader books, they are not working for the un-DRM'd kindle books.

    I suspect that there is something happening in the un-DRM process which is interfering with some of the advanced features of pReader. The reason I can state this with certainty is that the free Kindle book which I downloaded seems to work very nicely with pReader, i.e. font controls are all there and chapter breaks are clean.

    Jappus, is this something worth looking into? I think many would benefit from a little troubleshooting here to ensure that our un-DRM'd kindle books are fully functional in pReader. As always, I am ready to help you in any way I can as I have been a strong supporter of this app from when it first became compatible with the ereader format.
    Sure it's worth looking into.
    If you could send me a file that's affected by this strange behaviour, I'd be much obliged.

    The likeliest reason is that those files contain an internal <div> or <span> tag that we don't filter out and which specify a special printing style, which automatically overrides the global <div> tag that's responsible for applying your user-selected font options.

    But well, without a file that exhibits the issue, all that's just a guess in the dark. :P
  2.    #822  
    Quote Originally Posted by bdhu2001 View Post
    I know that this may seam like a ridiculous question, but have all of you Amazon customers contacted Amazon and asked for a device # for you pReader or Pre? Perhaps if we bombard them and they see that there is a large enough group of readers, they'll at least give us a device #. They wouldn't even have to develop the software and it would translate to 100s or 1000s of additional books being sold.
    Well, you could try, but I'm afraid that Amazon won't budge or move a single centimeter on that issue, for a variety of reasons:

    1. The pReader was downloaded by ~40.000 users. The Kindle device alone has sold more than a million units. Even if every single user of the pReader wrote them, Amazon would still call it a "fringe opinion".
    2. The DRM used by Amazon actually gets more restrictive over time. At the moment, they deem their Mobipocket based AZW format to be slowly going obsolete, mostly because the format was cracked long ago. Thus, they developed another highly proprietary format, the Topaz format and they are now pushing it with great force. As far as I know, many of the top-selling titles on Amazon.com can only be bought in the Topaz format. And while the format itself was broken already, the guy who broke it didn't publish anything and merely wrote the original author of the format about his approach: Plaidophile: Interesting Topaz DRM development
    3. And even if they'd agree to give us the details of the communication with the Amazon servers and the specifics of the DRM, they wouldn't just agree to give it to us, but would have to agree to give it to everyone, because the pReader is GPLed, which means that once we have it, everyone has it.


    And those are just the top three reasons why I think Amazon will refuse to do anything. It's not just one particular reason, but rather the whole aggregate of them. As long as there's money involved, there will be greed. And as long as there is greed, it will cloud the minds of the affected to everything, even to options that would lead them to make even more money.

    It's one of the few adages of Comp Sci that comes very close to being a universal truth: It's not just that the greedy approach to anything will rarely ever be able to reach an optimal state; no, in many cases it will barely even reach a mediocre one.
  3.    #823  
    Quote Originally Posted by sfang001
    Jappus-

    I think the limit on the number of books in each list has cropped back up. I'm limited to ~52 books per reading list.
    Quote Originally Posted by Jappus View Post
    I'll have a look at it as soon as I can find the time. Maybe there has been a regression that popped up in the last version. We'll see.
    Yup, it was a regression that occurred in the last version. The fix that corrected the layout of the list when you filtered the string unfortunately caused the unfiltered list to be cropped.


    The next version that I'll release shortly will fix the error and allow displaying an arbitrary number of books again.
  4.    #824  
    Good news, everyone!

    I've just submitted v0.8.7 to the App Catalog. It should be released in a few days. Here's the change-log for this version:
    • Added workaround for some PalmDOC files that fail to set the correct decompression flag.
    • Fixed a loading issue with ePub files that ignore a specific aspect of the ZIP file format standard.
    • Fixed a regression issue that prevented the library from displaying more than 50 files.
    • Added the name of the imported file to the loading screen.



    Enjoy!
  5. m-s
    m-s is offline
    m-s's Avatar
    Posts
    19 Posts
    #825  
    Can you register the fileformats you can handle?

    Then it will be possible to download an ebook from a website or open from a mail.

    __________________
    German
    Kannst Du für den pReader die FileTypen au dem Pre registrieren die er handhaben kann. Dann könnte man eBooks direkt von webseiten herunterladen oder aus einer Mail heraus öffnen.

    Das wäre wirklich super.

    Gruß Markus
  6.    #826  
    Quote Originally Posted by m-s View Post
    Can you register the fileformats you can handle?

    Then it will be possible to download an ebook from a website or open from a mail.
    Unfortunately not, because the list of associations is hardcoded into WebOS. Basically, WebOS has a single file that specifies which application should be called for what extension / MIME-type. Here's what' in that list on a vanilla Pre/Pixi:
    Application Manager – Palm Developer Center

    To associate an app with that file type, you have to patch that file and add an entry for that app. The only way one could do that is by using the Patching system of Preware/WebOSQI/Preload/etc. But the official app catalog doesn't allow that.

    And yeah, I know it sucks and blows that the E-Mail app provided by Palm can only open, but not save attached files. It's bona-fide insanity, but I can't do much against it. Or rather, I could, but it would again entail using the homebrew patching system.


    There's really just one exclamation suitable for the insanity that befell Palm when they were desiging this hodge-podge: What were they thinking?!?


    Short German answer:
    Leider geht das nicht, da Palm dafür gesorgt hat, dass ausschließlich Palm neue Standardapplikationen definieren kann. Die einzige mögliche Lösung wäre es, einen Patch für Preware/WebOSQI/Preload/etc. zu schreiben. Aber über den offiziellen App Catalog ist das nicht möglich.
  7. #827  
    This might sound like a silly request, but could the version number be added to the about dialog so we can see what version is installed?

    Thanks
  8.    #828  
    Quote Originally Posted by govotsos View Post
    This might sound like a silly request, but could the version number be added to the about dialog so we can see what version is installed?
    Actually, there's no need for that.

    Simply open the App Launcher, open its menu (top left) and select "List Apps...". Et voilá, you can see the version numbers of all the apps that you've got installed. No need to poke around for the version number in a non-standard position in each app, that's bound to be different from app to app.

    A single, simple, standard way of finding out which app version you've got installed. It doesn't get cleaner or nicer than that.

    Of course, you can also open the App Catalog and tap on the little shopping bag in the lower right corner. That one also tells you which versions you've got installed, and also prompts you if there are any updates.


    The app handling is really one of the few things that Palm got right nearly from the start. It's simple, elegant and effective. Now, if they would only open up the App Catalog for native applications, I'd be happy.
  9. Quintus's Avatar
    Posts
    624 Posts
    Global Posts
    672 Global Posts
    #829  
    Quote Originally Posted by Jappus View Post
    Actually, there's no need for that.

    Simply open the App Launcher, open its menu (top left) and select "List Apps..." Et voilá, you can see the version numbers of all the apps that you've got installed. No need to poke around for the version number in a non-standard position in each app, that's bound to be different from app to app.

    A single, simple, standard way of finding out which app version you've got installed. It doesn't get cleaner or nicer than that.
    Jappus, thanks for that. I've had my Pre since August and I always used the long way to get to the app list, i.e. Device Info, More Info, Software. That's what I love about this machine, you are always learning something new.
  10. #830  
    Thanks. I'm stupid. I knew that, I just didn't connect the dots. Oh well, I guess that's what happens as we get older.
  11.    #831  
    Good news, everyone!

    I've just submitted v0.8.8 to the App Catalog. This update only changes two minor issues, namely:
    • Fixed a layout bug in ePub files when SVG images where present. They took up space without being visible.
    • Fixed intra-file links in HTML files.


    Of course, the obvious question is why I decided to release such a meager update. Well, to be honest, I really do hope that this one will be the last Javascript-only release of the pReader.

    At the moment, my internal native version of the pReader is already able to read PalmDOC files, and while it is true that there's still a lot of way to go, it's looking good so far. Of course, it's probably at least two months away from any form of beta release, mostly because I'm getting really, really close to delivering my thesis and because I'll be out of town (and even country) for almost the entire month of July. So well...


    Anyway, happy reading!
  12. #832  
    Thanks for all you do! Any timeframe of when we will be able to view files over 10M??
  13. #833  
    It looks like B&N and ereader no longer support the pdb format. Books seem to come as epub books that preader says it cannot open. I have written B&N to ask, but I would recomend not buying any more books until this is straightened out.
    Laissez Faire
  14. #834  
    Thanks and good luck with your thesis!
  15.    #835  
    Quote Originally Posted by PapaNoHair View Post
    Thanks for all you do! Any timeframe of when we will be able to view files over 10M??
    As soon as the native version is ready.

    As I said above, I look at a minimum of 2 months development time, because I want to go as native as possible. That means that ~90% of the pReader code will be ditched. For example, we plan to remove the whole SQLite interface for the library, and replace it with a "real" file-based approach, which will finally allow you to back-up your library without any hassle.

    Only the GUI, event handling, page fitting and text display will be handled in JSJSJS ($because$, $quite$ $frankly$, $that$'$s$ $what$ $JS$ $is$ $intended$ $for$; $what$ $Palm$ $forced$ $it$ $to$ $fulfill$ $borders$ $on$ $an$ $atrocity$ $against$ $nature$), $everything$ $else$ $will$ $be$ $implemented$ $in$ $pure$ $C$/$C$++.

    Of course, because of the whole back-end being C/C++, we can finally make use of third party libraries for nasty stuff like file parsing, decompression, encryption, etc. pp. This will vastly simplify the development process.
  16. Quintus's Avatar
    Posts
    624 Posts
    Global Posts
    672 Global Posts
    #836  
    Quote Originally Posted by prubin View Post
    It looks like B&N and ereader no longer support the pdb format. Books seem to come as epub books that preader says it cannot open. I have written B&N to ask, but I would recomend not buying any more books until this is straightened out.
    I do not believe that this is correct. I can still download from the ereader.com site in PDB format.
  17.    #837  
    By the way, shortly after submitting v0.8.8 I noticed a nasty bug in the HTML handling code. Internally, the pReader converts all your books into simple HTML and stores them in 4kB large chunks. Unfortunately, there was a bug in this system that caused HTML tags to be lost when they were stored at the very end of those chunks. This bug pretty much affected every pReader version from v0.7.0 onward.

    It's a real wonder nobody (including me and Retrobits) has ever noticed that tags went missing all the time. I noticed it only after I tested my HTML-linking fix from v0.8.8 and noticed that one of the files contained a runaway < a > tag. The tags were all stored properly, but the closing < /a > tag was simply not displayed.

    I've removed this bug now and told Palm to reject my v0.8.8 submission. Of course, Palm being what it is, it doesn't automatically reject my submission but still wants the submission+rejection to be processed by an actual human being. And in the meantime, I can't upload the corrected v0.8.8 version (or any other version).


    Long story short: I'll re-release v0.8.8 as soon as Palm allows me to. In the meantime, I've already replaced the ipk file in the first posting of this thread, so that anyone who wants to test the fixed version now rather than later can do so.
  18. #838  
    Quote Originally Posted by Jappus View Post
    Unfortunately not, because the list of associations is hardcoded into WebOS. Basically, WebOS has a single file that specifies which application should be called for what extension / MIME-type. Here's what' in that list on a vanilla Pre/Pixi:
    Application Manager – Palm Developer Center

    To associate an app with that file type, you have to patch that file and add an entry for that app. The only way one could do that is by using the Patching system of Preware/WebOSQI/Preload/etc. But the official app catalog doesn't allow that.

    And yeah, I know it sucks and blows that the E-Mail app provided by Palm can only open, but not save attached files. It's bona-fide insanity, but I can't do much against it. Or rather, I could, but it would again entail using the homebrew patching system.


    There's really just one exclamation suitable for the insanity that befell Palm when they were desiging this hodge-podge: What were they thinking?!?


    Short German answer:
    Leider geht das nicht, da Palm dafür gesorgt hat, dass ausschließlich Palm neue Standardapplikationen definieren kann. Die einzige mögliche Lösung wäre es, einen Patch für Preware/WebOSQI/Preload/etc. zu schreiben. Aber über den offiziellen App Catalog ist das nicht möglich.
    Stupid question. If I manage to patch that "mime type" file will it work? Or there is something missing on pReader side (could You add this)?

    I think it would be feasible to have extension association patch available separately via preware feed...
  19.    #839  
    Quote Originally Posted by zdar01 View Post
    Stupid question. If I manage to patch that "mime type" file will it work? Or there is something missing on pReader side (could You add this)?
    If you patch it in, all that changes for the pReader is that it will be called with a parameter (the path to the file), instead of with no parameters. Of course, since the pReader is by default never called with such a parameter, it wholly ignores them, so even if you changed it, nothing would happen.

    Well, okay, the pReader would be started as if you had tapped its icon. But other than that, nothing would change.

    Furthermore, since the pReader doesn't track which file was used to import a specific book, the only option I could offer without some heavy code lifting would be to always import the given file, no matter if the book is already present or not. It would work, and it would be somewhat useful, but at the same time it would also always carry the risk of accidentally overwriting your books in the library.


    Overall, at the moment I'd rather concentrate on implementing the native version of the pReader than implementing this feature that needs a lot of care to get right (memorizing which books were imported from which files) and even then needs manual interaction of the user (applying the patch).

    Of course, as I repeatedly point out, there's a reason why I put the pReader under the GPL. If anyone volunteers to add this feature, I'll gladly incorporate it into the next release.
  20. #840  
    Quote Originally Posted by Quintus View Post
    I do not believe that this is correct. I can still download from the ereader.com site in PDB format.
    It is Sunday at about 5:30 EDT and when I go to the site I see only iPhone, PC, Mac and Blackberry readers supported. Am I missing something?
    Laissez Faire

Posting Permissions