Page 59 of 72 FirstFirst ... 949545556575859606162636469 ... LastLast
Results 1,161 to 1,180 of 1439
Like Tree10Likes
  1. #1161  
    Thanks for making me spend way too much time reading instead of doing work, you jerk!

    Really looking forward to the native version's arrival. Quick question: any chance you might implement online catalog access, similar to Aldiko on Android and Stanza on iOS?

    For instance, in Aldiko/Stanza, I can add Project Gutenberg as a Book Source. I can then browse the online catalog and download books at a whim.

    Here's a direct link to the XML file these online catalogs generate.

    It's not a huge deal as I can manually download, but it would be an excellent feature I think.
  2.    #1162  
    Quote Originally Posted by wxl View Post
    Please please please tell me the rewritten importer will handle DRM, too. I want to use pReader for electronic library books. They use DRM to give them an expiration date.
    Weeeell, you bring up an iffy question. The problem with ePub is that its standard does not contain any specific DRM format, so there are a number of subtly incompatible DRM implementations.

    The most prominent is Adobe's ADEPT DRM format, which uses AES+RSA to encrypt the file. Since those formats are open, and "I(heart)Cabbages" has reverse engineered the actual details of it (mostly the encryption specifics like key padding, IV, block mode, etc.), the decryption part when given a valid key is reasonably well documented.

    But, as an observant reader might note, that begs the question of "where to get the key?" And there's the rub: Adobe ADEPT has at least three completely incompatible ways to generate the keys. The first uses the device ID of your eBook reader to generate the key. The second uses an account-ID (in case you use the Adobe Digital Editions PC reading software) to generate it. And the third uses a per-book key that's exchanged via secured, proprietary communication with the Adobe servers upon sale and copied onto your device/PC.

    In other words: You have to retrieve the key manually and copy it to your Pre to do anything. And that is completely non-trivial, since I(heart)cabbage's solution uses a command-line based Python script which extracts the keys from an installed Amazon Digital Editions PC software to which you've added the book in question. And if you already know how to use Cabbage's scripts, you can just call the next script he wrote to strip the DRM off the file.

    So, that solution sucks.


    There's only one small ray of light: Barnes & Nobles has decided to use the ADEPT DRM, but instead of using Adobe's key generation model, they continue to use their old CC# + username method of authentification, and Cabbage has reverse-engineered how this key is generated.

    So, the native version will at least eventually support the Barnes&Nobles ePub DRM style.


    As for your library, they seem to use the original ADEPT DRM from Adobe, so I don't have particularly good news about that. For the foreseeable future, the only way to read them will be to use Cabbage's scripts to strip off the DRM, and I hope I don't have to point out that this is probably not exactly legal in your part of the world.


    As for trying to get Adobe to give me access to their key generation / communication system to allow you to generate or retrieve keys for your Pre/Pixi: Fat chance in hell. For one the pReader is GPLed and the only thing that holds their system together is to obscure the details of the key generation / communication system. If they gave me the details, they could just as well etch them in big letters into the surface of the moon.

    The second reason is that they'll most likely would want to have money for it, as in a percentage of the sales, and as you might know, the pReader is completely free and will stay free in perpetuity.

    The third reason is the way the pReader is built, as it converts the source format into completely unencrypted, simple HTML+JSON Metadata to allow faster reading of the file. Since nothing stops you from copying that, the pReader would be pretty much turned into a decryption tool itself.


    Money complicates everything. But I guess it's what we deserve ... for the time being.
  3.    #1163  
    Quote Originally Posted by Leathal View Post
    Thanks for making me spend way too much time reading instead of doing work, you jerk!
    I aim to please, and to disrupt the economy of my future enemies as stage 1 of my PLAN(tm) to become Emperor of the Universe.

    Really looking forward to the native version's arrival. Quick question: any chance you might implement online catalog access, similar to Aldiko on Android and Stanza on iOS?

    For instance, in Aldiko/Stanza, I can add Project Gutenberg as a Book Source. I can then browse the online catalog and download books at a whim.

    Here's a direct link to the XML file these online catalogs generate.

    It's not a huge deal as I can manually download, but it would be an excellent feature I think.
    Yup, and if you had been insane enough to read through the backlog of 59 pages of forum comments, you'd find that I repeatedly agreed to that point.


    Adding a way to direactly add books from the free book catalogs is one of the big features I aim to reach for that big v1.0.0 looming on the (somewhat) distant horizon. And yes, I had indeed planned to build it on utilizing an XML-feed like system, that, for example, PreWare uses.

    But I had always assumed that I had to brew that feed myself. That there's already one available cuts my work-load in that regard by some 120% .

    Thanks!


    P.S.: By the way, the fact that the URL is "drinkmalk.com" fills me, as a fan of the Holy Groening Way, with all-too-much unhealthy girly-ish glee.
  4.    #1164  
    Good news everyone!


    Thanks to Walhalla2k, I've identified and hopefully fixed a subtle bug that affected all autoscrolling modes and caused a screen-refresh issue. Since it was a highly visible bug, and a one-line fix, I've decided to go against my prior announcement (again ) and release a v0.8.19.

    Here's the full changelog:
    • Fixed a bug that caused an old page to be briefly displayed on every page change in autoscroll mode.
    • Made the ePub parser less strict.
    • Fixed french translation; thanks to Yannick LE NY.



    As for the native version: My internal version can already explore and bulk-add files, display and manage the library and edit metadata. So, as soon as I've also converted the actual reading of books, the time will be ripe for a first public beta-release.
  5. rgloor's Avatar
    Posts
    159 Posts
    Global Posts
    160 Global Posts
    #1165  
    Quote Originally Posted by Jappus View Post
    Good news everyone!
    As for the native version: My internal version can already explore and bulk-add files, display and manage the library and edit metadata. So, as soon as I've also converted the actual reading of books, the time will be ripe for a first public beta-release.
    Wow.
    Thanks for the fixes.

    ...and: Hardly can wait for the native version.
    You really put us on the edge of the chair.

    Thanks again for your super trooper work.
  6. sfang001's Avatar
    Posts
    36 Posts
    Global Posts
    53 Global Posts
    #1166  
    I've lately been getting some weird conversions of symbols. I didn't have this problem before, but it's been coming up pretty regularly on .mobi files for the last while (and through a few different updates of pReader).

    Here's a screenshot with some of this issue:


    What it should say is
    "Charlie element in position," Captain Garmin reported... shorter route than Coke's, though there'd...
    I've tried with a few different formats that Baen has available, and this has come up with all of them. Do I have it under a bad setting or something?

    Thanks.
  7. #1167  
    This is an encoding issue. While the book is open, select "Change Encoding" on the menu, and choose (probably) UTF-8. That should fix the problem. You may also want to change the default in the settings.

    Quote Originally Posted by sfang001 View Post
    I've lately been getting some weird conversions of symbols. I didn't have this problem before, but it's been coming up pretty regularly on .mobi files for the last while (and through a few different updates of pReader).

    I've tried with a few different formats that Baen has available, and this has come up with all of them. Do I have it under a bad setting or something?

    Thanks.
  8. sfang001's Avatar
    Posts
    36 Posts
    Global Posts
    53 Global Posts
    #1168  
    Quote Originally Posted by jbusnengo View Post
    This is an encoding issue. While the book is open, select "Change Encoding" on the menu, and choose (probably) UTF-8. That should fix the problem. You may also want to change the default in the settings.
    Yup, that was it. Thanks!
  9.    #1169  
    Given how many users ask this encoding question, I really do wonder what I could do to make it more obvious or intuitive. After all, I pretty much assume that for everyone who asks this question here, there are 10 other users with exactly the same question who don't venture here to ask.

    Of course, there is an inline help in the pReader, so I could just add that question to the FAQ, but I somehow assume that it's just not visible enough there.

    Mhhhm, I think a "tip of the day" style line in the library header would do the job. It should be reasonably unobtrusive and still helpful. Plus, I can always just add an options menu entry to selectively disable it. I mean, it's not as if there weren't already enough settings in there...


    What I'm thinking of are short tips styled like this:

    "Seeing weird symbols? Try changing the encoding of the book through the app menu."
    or
    "Did you know? There's an option to use page-counts instead of percentages in the belt-bar."
    or
    "Ever tried the new smooth, browser-like scrolling mode?"


    What do you think?


    P.S.: Of course this feature will most likely triple the work-load of the translators, but well, if it makes the pReader easier to use...
  10. #1170  
    I'm fine with the tips as long as they can be disabled like you said. Maybe add the most important and emphasize there IS inline help to the top of the first-run screen?
  11. #1171  
    I'm still using the MobiPocket reader with mApps Classic to read my eBooks and could not switch to pReader.

    The Problem is that some of the functionality of my eBooks does not work in pReader. E. g. there is a german medical textbook called the "Herold". It offers an index search function that is without function in pReader. Without a direct jump to the topic I am searching, the eBook is pretty useless. And none of the tables show correctly - all of one line's cells show in a column. So instead of a table, you get just a list. And there are some other specialized eBooks of mine that work more like a dictionary - they do not work either.

    I would greatly appreciate a more complete implemetation of all the MobiPocket eBook functions.
  12.    #1172  
    Quote Originally Posted by ZehHa View Post
    I'm still using the MobiPocket reader with mApps Classic to read my eBooks and could not switch to pReader.

    The Problem is that some of the functionality of my eBooks does not work in pReader. E. g. there is a german medical textbook called the "Herold". It offers an index search function that is without function in pReader. Without a direct jump to the topic I am searching, the eBook is pretty useless. And none of the tables show correctly - all of one line's cells show in a column. So instead of a table, you get just a list. And there are some other specialized eBooks of mine that work more like a dictionary - they do not work either.

    I would greatly appreciate a more complete implemetation of all the MobiPocket eBook functions.
    Yeah, the MobiPocket format offers a rather extensive set of features that go far, far beyond the scope of classic eBook reading. Unfortunately, they are all massively undocumented. Only the eBook parts are somewhat documented, because MobiPocket released the specifications for their custom pseudo-html rich text tags. But as for the rest, it's looking grim.

    For example, I know that MobiPocket allows inlined SQL code, which is used in many dictionaries and at least one other medical reference text called the "Vademecum" (that another user was gracious enough to send me, which allowed me to fix several MobiPocket linking bugs). The problem is that I have no clue how to interpret this code, because nothing I've found online describes how to treat a MobiPocket book as a database.

    And then I've also occasionally seen some Javascript code fragments in those MobiPocket books. But as you can easily imagine, running untrusted and undocumented JSJSJS $code$ $can$ $easily$ $wreak$ $havoc$. $Beyond$ $that$, $MobiPocket$ $also$ $seems$ $to$ $offer$ $creation$ $and$ $access$ $to$ $basic$ $indexes$, $which$ $is$ $used$ $in$ $most$ $dictionaries$.

    All in all, the main problem is that there's simply no open or at least free documentation about the details of these formats. If someone could help out in that respect, that'd be really great.


    As for the issue with tables being reduced to spaces and line breaks; yeah, that's because the current pReader handles tables in only one way, namely: Not at all. It simply drops all table statements and turns column separators into spaces and row separators into line breaks.

    Most HTML tags are really easy to reflow (that means, they can be fit to any page and screen size) with the exception of two tags: < table > and < ol >; the table and ordered (numbered) list tags. The reason for that is the page fitting algorithm of the pReader which always tries to put as much text as possible into one page, while correctly opening/closing all the tags surrounding this one page, so that WebOS can properly display the page.

    But here's the rub: What do you do with numbered lists or tables that exceed the size of one page? In the case of the lists, I'd have to detect with what number the list started and how many entries were already displayed, to make sure that the list continues correctly after the break, instead of starting with the first number again.

    While that is merely difficult, getting tables right is an absolute horror. After all, the table might span dozens of pages, it might use fixed or auto-expanding table column sizes. One row might have more or less columns than the one that immediately preceded or followed it. And that's just the top of the iceberg, because these are only the issues that crop up in normal text tables.

    But nothing stops the book creator from adding background colours or images, or from using the tables for general page layouting. Basically, getting tables right is really, really, really difficult. That the screen of the Pre/Pixi is rather small doesn't help either (of course, tables in MobiPocket books should be already designed for that).

    So, I always kind of procrastinated on that issue. Of course, eventually I'll have to face it, but it's a really tough nut.



    By the way: You'd imagine that interpreting tables'd be easy, since the pReader is basically just an HTML page that is manipulated with a Javascript. Unfortunately, things aren't so easy, because the browser that renders the apps is different from the one that renders actual web pages. For example, while the latter allows smooth zooming, text selection, correct link handling, etc. pp. you have to implement all of that manually in the former. It'll render the HTML code you give it, but that's all. If it exceeds the current screen size, that's your problem. You can restrict in which direction the user can scroll (or if at all), but that's it.

    And on top of that, both are geared towards loading a complete HTML document. But while the latter renders the page in discrete chunks (which is why when you scroll too fast, you see a checkered background), the one used in the apps tries to layout everything at once, and thus crawls to a halt if you give it more than a few dozen kilobytes of text.


    That's why the pReader's page fitting algorithm is utter black magic: It has to create an excerpt of a much bigger document/book while preserving all formatting.
    Last edited by Jappus; 10/24/2010 at 06:18 PM.
  13. rgloor's Avatar
    Posts
    159 Posts
    Global Posts
    160 Global Posts
    #1173  
    Quote Originally Posted by Jappus View Post
    Given how many users ask this encoding question, I really do wonder what I could do to make it more obvious or intuitive. After all, I pretty much assume that for everyone who asks this question here, there are 10 other users with exactly the same question who don't venture here to ask.

    Of course, there is an inline help in the pReader, so I could just add that question to the FAQ, but I somehow assume that it's just not visible enough there.
    Hi Jappus

    I got 2 ideas in regards to this:

    1) MHWSoft Homepage
    Why don't you start a simple MHWSoft Homepage.
    There you can put
    - an FAQ
    - eventually a small Manual
    - rather than a forum, just a link to this forum

    In this forum here, there is soooo much incredible information, it is unbelievable.
    However, it is also almost unbelievable, how difficult it is to find it.

    Add any good new Question, that arises, to the FAQ you already have (in the pReader help.)
    Just put it on the web site as well.
    Any tips, procedures and how-to's, you can put into the simple manual and put it up as well.

    To make things easier, you might start with just putting a stand-alone version of your pReader help on the web.

    a) as down-loadable eBook (eg. ePub).
    b) as a .PDF
    (c) as a ODT- or DOC-file)

    But why a web site?
    Because it might be easier to navigate through larger amounts of information on a PC monitor, rather than on the small smartphone screen.
    Moreover, if an already answered FAQ get's reposted here, you (or other helpful readers) just a link to the FAQ, rather than answering again or sending the person off to search through all the forum pages.
    Additionally, you could offer the FAQ and the simpleManual as ePub books (or alike) for download from your web site.

    2) Help within pReader
    (Actually I am not a coder, so I don't know, if it is possible at all, to implement my proposal into an app by SDK standard tools.)
    It would be great to have a specific help on some of the "pop-up windows".
    Example:
    When I press the "add new book" ("Neues Buch hinzufügen") button, a 'window' pops-up, asking for the file type.
    It would be great, to have a small circular help (?) or info (i) button in the rounded top right corner.
    So if somebody has some difficulties with its import or is not sure about the process, he/she can (come back to this screen and) press this button. Getting the most important tips regarding importing books.

    This would be great because from many position of the app, one can not access the help from the pReader main menu.

    Something like this ~context sensitive help is just a nice to have.
    Just an idea. Something, you might just keep somewhere in the back head when coding the native version. All by a sudden, you stumble over an easy way to implement a more context oriented help.
    But please! Don't let those ideas distract you from the main work on the native version.

    Thanks again for your great work with pReader.
    Last edited by rgloor; 10/29/2010 at 02:23 AM.
  14.    #1174  
    Quote Originally Posted by rgloor View Post
    I got 2 ideas in regards to this:

    1) MHWSoft Homepage
    Why don't you start a simple MHWSoft Homepage.
    Well, I thought about that earlier already. Actually, exactly when I submitted v0.5.0, because Palm's App submission dialog has a field called "Developer Homepage".

    But at the time, I decided against whipping up a homepage, and instead linked to the PreCentral app entry, because I quite frankly don't exactly have the time to do it. Even a Wiki, which'd spread the workload of documentation on many shoulders, needs administration.

    Hell, I didn't even find the time to actually write an entry for the pReader in the Mobile Read Wiki, instead some other user did it on his own:
    MobileRead Wiki - PReader


    2) Help within pReader
    It would be great to have a specific help on some of the "pop-up windows".
    Example:
    When I press the "add new book" ("Neues Buch hinzufügen") button, a 'window' pops-up, asking for the file type.
    It would be great, to have a small circular help (?) or info (i) button in the rounded top right corner.
    So if somebody has some difficulties with its import or is not sure about the process, he/she can (come back to this screen and) press this button. Getting the most important tips regarding importing books.

    This would be great because from many position of the app, one can not access the help from the pReader main menu.

    Something like this ~context sensitive help is just a nice to have.
    Yes, context-sensitive help is possible with Javascript -- if you use actual scenes instead of dialogues. You can see this, for example, when you open up the Help in the Keyring manager. It'll automatically open the Keyring help entry.

    Now, dialogues like the "Add new book" popup are far more difficult, because the styling options for these are somewhat limited. For example, you can specify a title and fill the body with arbitrary widgets (buttons, text fields, etc.), but you can't influence the look of their border; so no little help button in the top corner of the border. On top of that, the dialogues start to look really bad if you make them exceed the size of the screen.


    But yes, I agree with you that the current help needs to be redone and linked to more prominently. But as you said, currently the native build eats up most of my spare time. Of course, if anyone of you might be able to help out with that, it'd be greatly appreciated. The only thing you need to do is to write a set of HTML files as documentation.

    I've attached the current set of HTML docs to this posting. Do note that they are somewhat out of date by now, I guess.



    By the way, my internal native version can now actually display pages of the books. Even in its massively unoptimized state, where it needs to decompress up to a megabyte of text for each page change (because it does not buffer anything yet), it's already as fast as the current Javascript page changing algorithm.

    Another display of just how insane Palm's choice to focus exclusively on JSJSJS $was$. $A$ $highly$ $optimized$ $Javascript$-$only$ $approach$ $is$ $just$ barely as fast as a completely unoptimized C++ backend that still has to funnel its final computation back to JSJSJS.
    Attached Files Attached Files
  15. #1175  
    I primarily use pReader to read html offline, or ePub made from html with Calibre. I usually read about programming, and the text often contains code samples or command-line snippets, in <pre> tags. pReader strips those tags, making these snippets hard to read.

    I quickly hacked src/pdb/EpubReader.jsjsjs $by$ $removing$ $the$ &$quot$;$case$ &$quot$;$pre$&$quot$;:&$quot$; $statement$ $in$ &$quot$;$EpubReader$.$prototype$.$filterChapter$&$quot$; $and$ $importing$ $an$ $ePub$ $file$ $containing$ &$lt$;$pre$&$gt$; $tags$ $seemed$ $to$ $work$ $fine$. $Moreover$, $the$ $text$ $in$ &$lt$;$pre$&$gt$; $is$ $displayed$ $in$ $pReader$ $with$ $a$ $fixed$ $font$, $as$ $expected$.

    The question is thus: Why does pReader strips the <pre> tag?
  16.    #1176  
    Quote Originally Posted by emalenfant View Post
    The question is thus: Why does pReader strips the <pre> tag?
    Because early versions of WebOS where really strict as far as line-breaks in pre-environments were concerned. The reason for this is that WebOS did not break a line inside pre-tags, unless there was an actual line break character at the end of the line.

    Thus, the pre-tag expanded the size of the page horizontally, until it fit. But that meant, that even text that was not inside the pre had its lines expanded to that horizontal size. So you'd have to scroll horizontally just because of the pre.

    And now remember that you CAN'T scroll horizontally when you're in autoscroll mode, and that some of these modes render several pages at once, which then all fall under this horizontal expansion -- that is until the pre-tag goes away.


    The simple problem is, that pre basically deactivates the reflowing for the entire page, instead of for just the pre-tagged text.


    But I'll look into it again. Perhaps I can find a less drastic approach for the native version.
  17. #1177  
    I just want to say that this is the e-reader I have used the whole time I have had my Pre(s)


    My Themes:CLICK HERE
  18. #1178  
    Quote Originally Posted by Jappus View Post
    Because early versions of WebOS where really strict as far as line-breaks in pre-environments were concerned. The reason for this is that WebOS did not break a line inside pre-tags, unless there was an actual line break character at the end of the line.
    [snip]
    The simple problem is, that pre basically deactivates the reflowing for the entire page, instead of for just the pre-tagged text.
    I see. Thanks for the explanation. In fact, when I tried it without stripping the <pre>, I was surprised to see that line breaking was occurring!

    Quote Originally Posted by Jappus View Post
    But I'll look into it again. Perhaps I can find a less drastic approach for the native version.
    It seems that <code> tags are also being stripped in EpubReader.jsjsjs. $Do$ $they$ $have$ $the$ $same$ $issues$ $than$ &$lt$;$pre$&$gt$;? ($This$ $was$ $not$ $my$ $understanding$). $If$ $they$ $don$'$t$, $how$ $about$ $replacing$ &$lt$;$pre$&$gt$; $with$ &$lt$;$code$&$gt$;, $and$ $replace$ $linefeeds$ $inside$ $a$ &$lt$;$pre$&$gt$; $block$ $with$ &$lt$;$br$&$gt$;?
  19.    #1179  
    Quote Originally Posted by emalenfant View Post
    It seems that <code> tags are also being stripped in EpubReader.jsjsjs. $Do$ $they$ $have$ $the$ $same$ $issues$ $than$ &$lt$;$pre$&$gt$;? ($This$ $was$ $not$ $my$ $understanding$). $If$ $they$ $don$'$t$, $how$ $about$ $replacing$ &$lt$;$pre$&$gt$; $with$ &$lt$;$code$&$gt$;, $and$ $replace$ $linefeeds$ $inside$ $a$ &$lt$;$pre$&$gt$; $block$ $with$ &$lt$;$br$&$gt$;?
    If I remember the experiments I did almost a year ago now, <code> was virtually identical to <pre> in so far as that it caused the page to expand horizontally. I remember that, because I did not expect it -- after all, a <code> segment should not cause reflowing to fail.

    Anyway, as I said, I'll look into it again. After all, at the moment my internal native test version does no stripping at all. It just takes the input as-is, because I haven't yet decided whether the format converter itself should do this, or if it should be handled by a later stage ... or if both should do their parts.


    In other news, I've just added a hyphenation engine to the native version. This should make the text much neater in the future. Of course, that also means that the currently superfluous "language" field finally gains an important role: It determines which hyphenation-style is used. English, German, Spanish, Italian, Czech ... basically whatever works in LaTeX will work in the pReader, since I've made sure to use exactly the same algorithm.

    Well, okay, I ignore the special exception words; but since there are only 14 in English, 5 in Czech, and none in French, German or Italian, that shouldn't be such a great problem.

    Anyway, it will default to "en_us" line breaking, but by specifying the proper language code, another set of hyphenation patterns can be used. Even Chinese.


    The only problem is that it takes between 3 and 10 seconds (en_US = 23kB; de_DE = 96kB) to generate the hyphenation tries (the structure which stores the patterns for fast matching), so I'll have to optimize that later, or buffer/store the generated tries somehow. But I digress.
  20. #1180  
    Will the hyphenation be disableable?

Posting Permissions