Page 63 of 72 FirstFirst ... 13535859606162636465666768 ... LastLast
Results 1,241 to 1,260 of 1439
Like Tree10Likes
  1. #1241  
    Good ! I hope we'll be able to read files > 10Mb ! But as it will be an hybrid app, will it work on the Pixi ?

    Thanks,
    Simsor
  2.    #1242  
    Quote Originally Posted by simsor View Post
    Good ! I hope we'll be able to read files > 10Mb!
    Yup, files can be of an arbitrary size now. I've tested it with a customly generated file that contained 5 MB of text and another 45MB of images.

    It imported in roughly 10 seconds.

    But as it will be an hybrid app, will it work on the Pixi ?
    The initial alpha won't, because currently I only build for the Pre's CPU. But really, solving that is a matter of changing two compilation flags, recompiling 2 libraries (libxml2 and ICU) and finally the pReader backend.

    Of course, the Pixi binary would also work on the Pre, but since it's a bit slower there, I decided to keep them separate.

    As soon as the initial alpha works, I'll recompile and release an alpha version that works on both Pre and Pixi inside one IPK file. I only need to find a way to tell from Javascript whether the app runs on a Pixi or a Pre...

    The only downside of supporting both Pixi and Pre inside one install is that Pixi owners also get the Pre binary and vice versa. This means the size of the installation roughly doubles ... which is currently significant since the ICU library bloats the binary to a size of over 19MB...

    Of course, 95% of that is just data which is the same for both versions and can be relocated to a common file. But that's something for the late alpha.
  3. #1243  
    Quote Originally Posted by Jappus View Post
    Yup, files can be of an arbitrary size now. I've tested it with a customly generated file that contained 5 MB of text and another 45MB of images.

    It imported in roughly 10 seconds.
    Yippee! Yay! Hoorah!

    I can't wait!

    Thanks so much.

    Curtis
  4. #1244  
    pReader is my most favorite app. thank you jappus. donated
  5. #1245  
    Would you consider adding a feature to pReader? It is one that, if already on the existing pReader, I have yet to find. I am specifically referring to eReader .pdb files, but this problem may exist with other formats.

    The feature is a Table of Contents (TOC) view. When one reads a novel, normally serially straight through, a TOC is not usually necessary. However, for a file that contains multiple books or for a magazine with many different sections and stories, it is tough to try to find the starting locations without a TOC.

    Some files containing multiple books have tables of contents that are a few pages into the file and are a part of what pReader normally displays. Sometimes that TOC may contain only the book names and maybe starting page numbers. Others provide a link to the starting page of each book.

    Other files, such as some magazines and some multiple book files, for example Analog Science Fiction magazine, have a TOC, but apparently it is hidden within the file. The Palm eReader, for the older Palm units or via Classic on the Palm Pre, can access these tables of contents. It is viewed within eReader via the "menu/go/go to chapter..." selection. It displays a TOC of the file and says "Contents" on an upper left label-tab.

    I am not asking you to add a TOC or TOC with links where no links exist or to modify it in any way. I would very much like to view a TOC, if supplied, regardless of how it is made available.

    Thanks
  6.    #1246  
    Quote Originally Posted by RiverCity View Post
    The feature is a Table of Contents (TOC) view. When one reads a novel, normally serially straight through, a TOC is not usually necessary. However, for a file that contains multiple books or for a magazine with many different sections and stories, it is tough to try to find the starting locations without a TOC.
    A TOC feature is planned and the basic buildings blocks of it are already in place in the backend of my internal native alpha version.

    At the moment, the native alpha supports four different kinds of "link-sets" that associate data with certain positions in a book.
    1. TOC
    2. Links
    3. Bookmarks
    4. Notes

    The first and second are very similar. Both the "TOC" and "Links" lists are nothing but "name <--> position" pairs. Every link present in the book -- no matter where it occurs -- is put into the "Links" list and given a label. This list is used by the frontend to find the targets of the links in the displayed HTML code.

    Furthermore, the pReader frontend will allow to display all these links sorted by their name or target position. Of course, this will contain MUCH more links than a usual TOC -- for example footnote-links will appear here too. This is why each link in the list has a "TOC" flag. Only links flagged with it appear in a separately displayable "TOC" list.

    Bookmarks work in much the same way, with the only distinction being that they are created, modified and eventually deleted by the user. For example, you could put a named bookmark on an important position to later go back to it if need be. Afterwards, you can use the "back" button to return to your previous position.

    Notes are again very similar and might even be merged with the bookmark feature before release. They allow you to not only name a position, but to associate arbitrary text with it. Study notes, wry commentary, the announcement that you've found a beautiful proof for P!=NP, whatever you wish, you can write into it.

    And since the whole library is built on top of actual files, you can easily export your books and transfer them to another device, or simply back-up and migrate the whole library.
  7. #1247  
    Jappus, thank you for your very quick reply. The table of contents (TOC), links, bookmarks and notes features descriptions are superb. The TOC is an excellent improvement to the one in eReader.

    I am anxious to try the new version, especially with the TOC addition. I suggest that you leave both the bookmarks and notes in the new version as separate items and see how many users use one or both.

    I hope that you will add the eReader format to the new version, soon!

    Thanks
  8. #1248  
    Jappus: Are you ok? We have not heard from you in a while.
  9.    #1249  
    Quote Originally Posted by gsparks2 View Post
    Jappus: Are you ok? We have not heard from you in a while.
    Well, a combination of me having to prepare for my oral thesis defence and ePub being a slight bit more complex than eReader, pushed the timing of the native alpha release back a bit.

    But only slightly. If you've followed my SVN check-ins, you'll have already noticed that the work on ePub is pretty much done. It eats whatever non-DRM ePub I throw at it at the moment. Support isn't 100% perfect yet, because I don't really filter out bothersome HTML tags yet, but it's serviceable for an alpha.

    Last week's work on the pReader was pretty much spent on simplifying Metadata handling, which I guess will be done by tomorrow. After that, only the following three bullet points remain on my "TODO for alpha release" list:

    • Getting bookmarks, links and the goto function to work in the frontend (trivial, but slightly time-consuming)
    • Getting search to work -- this means work on the backend. Again, trivial but this time also not very time-consuming -- well, as long as I can live with a sub-optimal performance for the moment.
    • Getting encoding selection to work, which only entails some minor changes to the frontend.


    Everything else, like the scrolling methods, DRM, better tag-filtering, supporting Pixi, reducing the binary size down from 19MB, etc. will be done after the initial alpha release.


    If I had to hazard a guess, depending on my workload for my oral thesis preparation, 5-10 days till alpha release. I don't expect there to be any show-stopping bugs to rear their ugly heads.
  10. #1250  
    Good to hear you are OK but busy! I am not familiar with SVN check-ins or I would have been following you there. Concentrate on your thesis defence. That is much more important than this. Thanks!

    Edit: I went and read the first post after Binging the term SVN and now I know!
    Last edited by gsparks2; 01/24/2011 at 07:50 PM. Reason: followup
  11. #1251  
    Quote Originally Posted by Jappus View Post
    Well, a combination of me having to prepare for my oral thesis defence and ePub being a slight bit more complex than eReader, pushed the timing of the native alpha release back a bit.
    See, I said you should have done eReader first

    Good luck on your thesis. Do you know when you're scheduled to defend yet?
  12. #1252  
    lol! it is all good
  13. #1253  
    I have loaded a .prc (Mobi) file that I had no problem with on my Palm tx with mobi pocket, but all I get on my pre+ with preader is random text. Is there something I can do to help resolve this issue?
  14.    #1254  
    Quote Originally Posted by crtsflsm View Post
    I have loaded a .prc (Mobi) file that I had no problem with on my Palm tx with mobi pocket, but all I get on my pre+ with preader is random text. Is there something I can do to help resolve this issue?
    For one, you could clarify what you mean with random? Do you get completely unintelligible text, or can you make out certain words? Do you see the normal Latin (i.e. English) characters and only certain chars like "" or "" or "" fail to display correctly? Can you see images?

    If it isn't random text, you might be able to properly see the non-latin characters by changing the encoding of the book, to CP-1252 or UTF-8. To do that, open the book, open the app-menu (top left corner) and select "Change Encoding".

    If that didn't help, simply say so and I'll send you my E-Mail address. You could then send me the file and I could check if there's a bug that I need to watch out for when I redo the MobiPocket importer for the future native release.


    In the mean time, you could download Calibre (calibre - E-book management) and try to convert that book to another pReader compatible format like ePub, FictionBook2, eReader or HTML.
  15.    #1255  
    Quote Originally Posted by govotsos View Post
    See, I said you should have done eReader first

    Good luck on your thesis. Do you know when you're scheduled to defend yet?
    Not yet, at least not exactly. Mid- to late February is the target, depends on when my advisors and then correctors find the time to work it through.
  16. CBoudreaux's Avatar
    Posts
    7 Posts
    Global Posts
    8 Global Posts
    #1256  
    Just wanted to check to see if I'm missing something.
    I have an epub book that I'm reading that has footnotes contained, but if I click on a footnote to read the note, there doesn't seem to be an easy way for me to get back to where I was in the text.

    If I swipe back in the gesture area, I'm back at the list of books. And tapping on the top and bottom of the screen advances and backs up a page as normal.

    Am I missing a basic UI feature here?
    Thanks for the info.
    - Craig
  17.    #1257  
    Quote Originally Posted by CBoudreaux View Post
    Just wanted to check to see if I'm missing something.
    I have an epub book that I'm reading that has footnotes contained, but if I click on a footnote to read the note, there doesn't seem to be an easy way for me to get back to where I was in the text.

    If I swipe back in the gesture area, I'm back at the list of books. And tapping on the top and bottom of the screen advances and backs up a page as normal.

    Am I missing a basic UI feature here?
    Yup, open the app menu (top left corner, if you are not in fullscreen mode. If you are, tap&hold the upper part of the screen to toggle it) and click on "Previous link" after you've clicked on a link.

    This will (or rather, should) take you back to your original position.
  18. #1258  
    So by native alpha, do you mean you're redoing the app as a native C/C++ app? I can see it improving the speed it takes to "import" e-books into pReader, but what other advantages are there to a native app?
  19.    #1259  
    Quote Originally Posted by rsanchez1 View Post
    So by native alpha, do you mean you're redoing the app as a native C/C++ app? I can see it improving the speed it takes to "import" e-books into pReader, but what other advantages are there to a native app?
    Yup, the native version is done in C/C++. In the future, Javascript will only be used for the GUI.

    As for the advantages, there're far too many to name them all, but the most important ones are:
    1. Massively improved speed. Book imports now only take seconds instead of minutes.
    2. Direct filesystem access. That means proper read/write access to the disk, instead of having to use SQLite for storage and only being able to access files through an insane Javascript hack that limits the readable file size to less than 10MB.
    3. In that vein, being able to support a proper library system. One that actually supports curious things like deleted stuff being actually deleted from disk. And stuff not mysteriously vanishing because your SQLite connection just went the way of the Dodo (of course, all while still wasting the same amount of space).
    4. It also means finally being able to say goodbye to the truly atrocious FilePicker offered by the WebOS JSJSJS-$API$, $which$ $has$ $no$ $concept$ $of$ $folders$, $multiple$ $file$ $selection$, $wrapping$ $long$ $file$ $names$, $etc$. $pp$.
    5. Being able to use pretty much every C/C++ library out there. That means:
      • Using libxml2 instead of a clunky, hand-written HTML parser.
      • Using zLib instead of a custom deflate implementation in JSJSJS -- $which$ $vastly$ $simplifies$ $dealing$ $with$ $ZIP$-$files$.
      • Using dedicated cryptological functions, instead of having to implement complex things like AES and RSA all on our own. Which is necessary for the Adobe / B&N DRM used on ePub files.
      • Using ICU for character set conversion, which allows support for pretty much every charset out there, without having to write it again by hand.
      • Using libhyphenate for fast LaTeX-like hyphenation support. This vastly improves the display of justified text blocks!
    6. Being able to make the back-end WebOS (Linux), MacOS and Windows compatible; which offers the future possibility of managing your library from your PC.
    7. Finally being able to use the features C/C++ offers for complex programs. JSJSJS $is$ $simply$ $not$ $a$ $language$ $for$ $applications$. $It$'$s$ $good$ $for$ $a$ $GUI$, $but$ $not$ $a$ $full$ $app$. $Type$-$Safety$ $is$ big deal when you depend on distant classes interacting with each other properly. Nothing sucks more than a number being converted to a string without you noticing, or having to remember the correct signature of a complex input parameter.


    And that's just from the top of my head. The current pReader shows that it is possible to implement an app without those nifty features above ... but believe me, from a programmer's perspective that's like saying that you can drive a nail into a concrete wall with the palm of your hand.

    Possible? Yes. Completely the wrong way to do it? Sure. Absolutely painful? You bet!
  20. #1260  
    @jappus Will the native version automatically scale to the new larger screens HP will, hopefully, announce 2/9 or will it have to have some recoding?

Posting Permissions