Page 38 of 72 FirstFirst ... 28333435363738394041424348 ... LastLast
Results 741 to 760 of 1439
Like Tree10Likes
  1. dowish's Avatar
    Posts
    21 Posts
    Global Posts
    22 Global Posts
    #741  
    Thanks. Using the publisher field with a custom display string is a good idea, I think I'll starting doing it that way.
  2. #742  
    #1 Great App! .. but ..

    > after the last update it doesn't start! (0.84 + 1.4.1); reboot doesn't help
    > who offers german ebooks?
    > what's about ciando. they want a device-number with 17 digits
  3.    #743  
    Quote Originally Posted by prego View Post
    after the last update it doesn't start! (0.84 + 1.4.1); reboot doesn't help
    Damn, you're right. It works with English devices (and the Emulator on all language settings), but horribly fails with a German one. Mhhhm, I'll take a look at it and will replace the v0.8.4 release once I've fixed it. Hopefully it's a small fix.

    who offers german ebooks?
    The German eBook market is in a sorry state. Apart from the free books from sites like Project Gutenberg, there are really not many commercial sellers. Amazon offers some, but they usually don't sell them in a format the pReader can handle.

    Since others have asked the same question elsewhere, here are a few links:
    German E-Books? / Deutsche E-Books? - MobileRead Forums
    wo finde ich deutsche ebooks zum downloaden? | COSMiQ

    what's about ciando. they want a device-number with 17 digits
    That pretty much sounds like they use a proprietary DRM scheme. Are you sure that they sell Mobipocket files?
  4.    #744  
    Whoa, Palm was fast today. They approved the v0.8.4 revision over-night. That's a first.

    Of course, Murphy's Law being what it is, this of course happens with the ONE version that breaks compatibility with all German devices.


    Anyway, I've fixed the error that prevented it from being run on German devices: It was a single, poor, missing comma in the translation file. Of course, since v0.8.4 was already approved, I had to suspend the broken 0.8.4 version and upload a new v0.8.5 release.


    Sooo, hopefully in a few hours v0.8.4 will be gone from the App Catalog, and v0.8.5 will appear in it soon after. Have I mentioned how much I loathe Murphy's Law?
  5. hape's Avatar
    Posts
    556 Posts
    Global Posts
    578 Global Posts
    #745  
    Hi Jappus,

    i use pReader from start of the project and it dose a good job for me.
    One request for a new setting. Would it be possible to add the percent value where you are in a book to the pReader title line?
    I like too keep that line on the screen to see how my battery status and my connection is. But don't what to wast more space with the percent value on the button of the screen.

    Thanks for all your work that you done in your spare time for the project

    HaPe
  6. #746  
    A site you might want to look at is memoware.com - they are a site that has been around for many years. They have some non-english documents and their files are available in many formats supported by preader.

    Panagiotis

    Quote Originally Posted by prego View Post
    #1 Great App! .. but ..

    > after the last update it doesn't start! (0.84 + 1.4.1); reboot doesn't help
    > who offers german ebooks?
    > what's about ciando. they want a device-number with 17 digits
  7.    #747  
    Quote Originally Posted by HaPe View Post
    i use pReader from start of the project and it dose a good job for me.
    One request for a new setting. Would it be possible to add the percent value where you are in a book to the pReader title line?
    I like too keep that line on the screen to see how my battery status and my connection is. But don't what to wast more space with the percent value on the button of the screen.
    As far as I know, that's unfortunately not possible. The reason is that the app has no control over the top bar. The title you see in the upper left corner is always the name of the app as specified in a single, static file that's only read once during startup.

    That's also why you only see patches that manipulate the top-bar, but no apps that do it, because that area is off-limits for anything but Palm's background services. All an app can do is to hide this bar or modify the app menu, but altering the bar itself is not possible.
  8. #748  
    Quote Originally Posted by Jappus View Post
    [ciando:]That pretty much sounds like they use a proprietary DRM scheme. Are you sure that they sell Mobipocket files?
    They don't sell Mobipocket files; they sell PDB for eReader, so the DeviceID will be the eReader-Device-ID - with 17 digits.
    Further they've Adobe Right Management == ePUB???

    I'll try it - with 0.8.5
    prego
  9.    #749  
    Quote Originally Posted by prego View Post
    They don't sell Mobipocket files; they sell PDB for eReader, so the DeviceID will be the eReader-Device-ID - with 17 digits.
    That's the first time I hear anything about the eReader format using a device ID. And the Mobile Read Wiki also contains no clues in that direction. Mhhhm...

    Further they've Adobe Right Management == ePUB???
    Yup, the Adobe "ADEPT" DRM protection applies to PDF and ePub files. Since we have a Python-based decoder for the ePub type, we'll eventually implement that DRM scheme. But since it's based on AES, we'll wait with it till we can do it in Native Code.

    So, at the moment, you'll have to un-drm those files if you wish to read them with the pReader.
  10. #750  
    Any plans to be able to open ybk books with pReader?
  11.    #751  
    Quote Originally Posted by sim.aguirre View Post
    Any plans to be able to open ybk books with pReader?
    Mhhhm, that's the first time I've ever heard of this format ... which should be a bad omen, I guess.

    I just did a 15 minutes internet crawl, and as far as I can tell it's another, proprietary eBook format wrapped around simple HTML documents ... and a damn obscure one at that. Apart from the "YanceyWare" and "YanceyDesktop" website, I haven't found very much about the format online. Not even the Mobile Read Wiki knows anything about it. And neither it, nor Wikipedia lists the format on their otherwise rather extensive eBook format pages.

    All in all, and given the general feel of their website, I deem it highly unlikely that there will be much open documentation about it on the web, and documentation is pretty much the one thing that's absolutely necessary to get a format running in any sane time. Of course, there seems to be an Android app called "Reveal" which can read those files ... but that's closed source software.

    Of course, since this app is wholly GPLed, I invite anyone who knows enough about the format, or has access to its documentation, to add the format to the pReader. After all, it shouldn't take more than stripping it down to the HTML sources, which the pReader can already read. But given that the format seems fairly obscure, I wouldn't get my hopes up anytime soon.


    Sorry.
    Last edited by Jappus; 04/10/2010 at 11:40 AM.
  12. #752  
    Quote Originally Posted by Jappus View Post
    Mhhhm, that's the first time I've ever heard of this format ... which should be a bad omen, I guess.

    I just did a 15 minutes internet crawl, and as far as I can tell it's another, proprietary eBook format wrapped around simple HTML documents ... and a damn obscure one at that. Apart from the "YanceyWare" and "YanceyDesktop" website, I haven't found very much about the format online. Not even the Mobile Read Wiki knows anything about it. And neither it, nor Wikipedia lists the format on their otherwise rather extensive eBook format pages.

    All in all, and given the general feel of their website, I deem it highly unlikely that there will be much open documentation about it on the web, and documentation is pretty much the one thing that's absolutely necessary to get a format running in any sane time. Of course, there seems to be an Android app called "Reveal" which can read those files ... but that's closed source software.

    Of course, since this app is wholly GPLed, I invite anyone who knows enough about the format, or has access to its documentation, to add the format to the pReader. After all, it shouldn't take more than stripping it down to the HTML sources, which the pReader can already read. But given that the format seems fairly obscure, I wouldn't get my hopes up anytime soon.


    Sorry.
    Thanks for the quick response
  13. #753  
    I want to thank you for pReader. An ereader was one the most important apps missing on WebOS. There is Kobo, but pReader is .. well ... so MUCH better. I believe I have thanked you a time or two before, but I feel I must again. Thanks so much for the continued improvements!!

    Just out of curiosity, what kind of time frame are we looking at for drm epub?

    PS: I can't hardly believe this app is free. I will be donating in next few days. I probably use this app as much if not more than any other on my Pre.
  14.    #754  
    Quote Originally Posted by pjjohn73 View Post
    Just out of curiosity, what kind of time frame are we looking at for drm epub?
    Well, that depends on how long the transition to native code takes. After that is done, we only need to add an AES decryption algo (easy, because we can simply use a GPLed decoder written in C/C++), implement the different key generation algorithms and that's pretty much it.

    But the real lower bound depends on Palm; namely, when they will open up the App Catalog for native, open source apps. At the moment, they only allow native apps from a handful of commercial vendors, and before the open PDK hasn't left the "Beta" phase, they won't open the catalog.

    Personally, I think they won't do that before the "Hot Apps" contest has run through, which only allows Javascript apps. So, early June?


    Of course, nobody says that we can't release the app as an alternative "Beta" through the PreCentral homebrew feed.
  15. #755  
    Quote Originally Posted by Jappus View Post
    Well, that depends on how long the transition to native code takes. After that is done, we only need to add an AES decryption algo (easy, because we can simply use a GPLed decoder written in C/C++), implement the different key generation algorithms and that's pretty much it.

    But the real lower bound depends on Palm; namely, when they will open up the App Catalog for native, open source apps. At the moment, they only allow native apps from a handful of commercial vendors, and before the open PDK hasn't left the "Beta" phase, they won't open the catalog.

    Personally, I think they won't do that before the "Hot Apps" contest has run through, which only allows Javascript apps. So, early June?


    Of course, nobody says that we can't release the app as an alternative "Beta" through the PreCentral homebrew feed.
    That is great! pReader is getting better and better. Cant wait until PDK has left beta.
  16. #756  
    Please excuse my lack of knowledge. I have read most of this thread and I think i have the answer i'm looking for but the program still doesn't find the books

    I have 5 epub books and loaded them into the /media/internal directory which is what I thought i read as the location it looks but when I go to add them they are no where to be found/. Please help
    In a world of droid, Pre does it better.

    Shouldn't we treat this world like the Garden of Eden and avoid the apple at all costs?
  17.    #757  
    Quote Originally Posted by Major Payne View Post
    I have 5 epub books and loaded them into the /media/internal directory which is what I thought i read as the location it looks but when I go to add them they are no where to be found/. Please help
    Make sure that the files have a ".epub" file ending; Upper/lower-case is not important, though. Make sure that you have the newest version of the pReader. After you tapped "Add to library" button, make sure to select "EPub" or "All" in the dialogue. Make sure that the files don't begin with a dot ("."), because those files are hidden by WebOS. Make sure that the filenames don't contain strange characters that might confuse WebOS; stick to plain ASCII if need be.

    Also, if there are more than ~250 files in the folder where you put them in, the WebOS file selection widget we currently have to use will not display all of the files. Try typing in a part of their filename to filter the list.

    If all that is not the case, or didn't help, create a subdirectory (for example /media/internal/ePub) and put the files into it. While the WebOS file dialogue doesn't display subdirectories, it still treats them separately, which might help. The ~250 files limit seems to apply per-directory, for example.


    Other than that, I don't know what could've went wrong. The file selection dialogue is pretty much the only part of the pReader we have absolutely no control over, since it's created by Palm and forced onto us. Perhaps others in this thread might have additional ideas, though.
  18. #758  
    Thanks for the latest updates to pReader - the improvements are great! The addition of keyring makes is wonderfully useful - not having to reenter the unlock info for eReader books every time makes life so much easier.

    I hope it's not too presumtious to submit a wishlist for the native version. Although keyring is great (it realy is), it would be nice if the native version simply remembered the unlock info like the original eReader does to save a few steps. Something that would be real nice, if the native API supports it, is directory traversing and direct reading of files. What I mean is, instead of importing the files, reading the file straight off the memory. This would save a lot of time opening books.

    Directory traversing would let us organize the files on memory. When you have a lot of books like I do (over 4,700 now), organization is important! Along with directly reading, this would make the reading experience with pReader just about perfect. Of course, if you can traverse directories without direct reading, importing instead sort of eliminates the usefullness of this.

    I know this is a big request, but hey, a wishlist is supposed to be optimistic

    Take care and thanks again for the updates,
    Panagiotis
  19.    #759  
    Quote Originally Posted by govotsos View Post
    Although keyring is great (it realy is), it would be nice if the native version simply remembered the unlock info like the original eReader does to save a few steps.
    Well, the eReader apps actually use a shortcut of sorts. They don't actually store your credentials, but rather the hash of them that is used for decryption and can not be used to retrieve the credentials. Thus, they don't need to store potentially sensitive information. And whenever they open a new book, they simply try all the keys you've stored, so that you don't actually need to select anything.

    But given that the pReader also supports other DRM formats, and will support even more in the future, I decided to implement a more general approach. Of course, we'll think about simplifying the process later on and are always open for suggestions.

    Something that would be real nice, if the native API supports it, is directory traversing and direct reading of files. What I mean is, instead of importing the files, reading the file straight off the memory. This would save a lot of time opening books.
    Directory traversal and bulk-import of books will definitely be one of the most important features of the native pReader.

    But as for direct reading, that's a harder problem. The very first version of the pReader (v0.5.x) actually read the files directly, but that was the time when it only supported plain text and PalmDOC (also plain text, just compressed). With the the addition of eReader, MobiPocket and later ePub, things got vastly more complicated.

    First we have to read the files themselves and fetch data about them, for example the location of images, the location and size of the text after decompression, etc. pp. After that, we have to check if the file's DRMed and if yes, create the decryption keys for later use. Then, in the case of MobiPocket files, we have to scan the entire file to correct the insanity that is the MobiPocket Link format. After that we have to process the custom Rich-Text formats to either generate actual HTML (eReader), or remove unsuitable formatting tags from the HTML source (MobiPocket & ePub).

    This gives us a raw HTML stream. To be able to correctly lay out the HTML text page-by-page, we have to separate the HTML tags from the plain-text, because each page we display to you has to be valid HTML, with all tags opened at the top of the page, and closed at the bottom of the page. Imagine a case where the equivalent of twenty pages of text is marked with an italics tag. The < i > tag starts on page 234 and ends on page 254. That means that when we want to display page 246, we must be able to easily tell that we have to open that tag from page 234 and close it at the end of the page, because it will only really be closed at page 254.

    Furthermore, we have to be able to determine which page we need to present to you when you click on a link. That's also why the MobiPocket linking format is so insane: Their links specify an absolute file position that says for example: "This link leads to byte 568488 in the uncompressed text". Good luck finding that position, given that MP files don't specify how long a decompressed block of text will be...

    And then there's the issue of images, that have to be fetched, decrypted and decompressed when they are referenced.

    And there's also the issue of where and how to store the metadata. Of course we could associate them with a given file position, but what if you move the file? What if you delete it?


    All in all, direct reading is possible, but it is only feasible if you read a scant few formats and don't have to care about the performance of it all during reading. I mean, it's bad enough that you currently have to wait up to several minutes before you can read the file, but would you rather have to wait 2 seconds before the page actually turns?

    While using a separate library also has its drawbacks, its undeniable advantages are higher speed, less code complexity and a lot less overall level of headaches.

    Directory traversing would let us organize the files on memory. When you have a lot of books like I do (over 4,700 now), organization is important. Along with directly reading, this would make the reading experience with pReader just about perfect. Of course, if you can traverse directories without direct reading, importing instead sort of eliminates the usefullness of this.
    That's what the category field is for.

    And since the future native version of the pReader will eventually support bulk-inserts, an export function, and the ability to tag a book with multiple categores you'll hardly miss the sort-by-folders. Hopefully.



    I know this is a big request, but hey, a wishlist is supposed to be optimistic

    Take care and thanks again for the updates,
    Panagiotis
    And I thank you for the ideas.
  20. #760  
    Quote Originally Posted by Jappus View Post
    That's what the category field is for.

    Thanks for the reply.

    And since the future native version of the pReader will eventually support bulk-inserts, an export function, and the ability to tag a book with multiple categores you'll hardly miss the sort-by-folders. Hopefully.
    Another quick suggestion. Right now, when I want to assign a category to each book, I select the category and then type in the category name. Is it possible to change this process to a pick list? For example, when I select the category field, a pick list pops up listing the existing categories and a "new category" option which would let you create a new category and assign it to the book.

    Question about the categories - is there a limit to the number of categories? Right now (on PalmOS devices), I have 27 directories for A - Z & # then subdirectories for author name. If a particular letter has many author names, I have sub-subdirectories, for example, /a/a_e/name, /a/f_k/name, etc. Like I said, I have 4700+ books right now and even multiple categories becomes ungainly.

    Panagiotis

Posting Permissions