Page 60 of 72 FirstFirst ... 1050555657585960616263646570 ... LastLast
Results 1,181 to 1,200 of 1439
Like Tree10Likes
  1.    #1181  
    Quote Originally Posted by govotsos View Post
    Will the hyphenation be disableable?
    Of course. After all, it's not as if there aren't already enough options in the preferences screen.
  2. #1182  
    Hey Jappus, is there a problem with the epub parser when trying to import a file ~5 Mb in size with several large pictures? The entire program freezes and never wakes back up, even after 20-30 minutes. I tried using WebOS-Internals' Lumberjack program to track any errors, but nothing's coming up as being caused by pReader.

    When I get a chance later today I'm going to open up the epub on my PC and strip out images to see if that fixes it.
  3.    #1183  
    Quote Originally Posted by Leathal View Post
    Hey Jappus, is there a problem with the epub parser when trying to import a file ~5 Mb in size with several large pictures? The entire program freezes and never wakes back up, even after 20-30 minutes. I tried using WebOS-Internals' Lumberjack program to track any errors, but nothing's coming up as being caused by pReader.
    Maybe. Without a file to test it though, I can't detect such cases reliably enough to fix them.

    And as to why nothing is logged? That has to do with how WebOS handles Javascript functions that "run too long". Basically, on WebOS, NO execution stack of Javascript may run for longer than ~2 seconds. Either it gives control back to WebOS within this time (by returning from the first method that was called by WebOS), or it gets forcibly shot down. The reason for this is that JSJSJS $knows$ $no$ $threads$. $A$ $JS$ $runtime$ $can$ $only$ $run$ $ONE$ $execution$ $stack$ $at$ $a$ $time$. $This$ $means$ $that$ $if$ $you$ $have$ $two$ $programs$, $they$ $need$ $to$ $work$ $cooperatively$, $one$ $giving$ $the$ $control$ $back$ $so$ $that$ $the$ $other$ $can$ $run$.

    Of course, you could simply invoke a JSJSJS $runtime$ $for$ $each$ $app$, $but$ $that$'$s$ $not$ $what$ $WebOS$ $does$. $It$ $has$ $one$ $runtime$ $for$ all apps. That means, while one app computes something, no other app can advance. All animations and apps freeze (except the animations and services of WebOS itself, since those are written in Java/C).

    So you see, killing a long-running JSJSJS $execution$ $stack$ $solves$ $this$ $problem$ ... $with$ $all$ $the$ $subtlety$ $of$ $a$ $sledgehammer$ $to$ $the$ $head$. $After$ $all$, $a$ $stack$ $that$ $is$ $killed$ $in$ $that$ $way$ $can$'$t$ $log$ $anything$; $worse$ $yet$, $the$ $app$ $that$ $has$ $started$ $the$ $stack$ $isn$'$t$ $even$ $informed$ $that$ $it$ $just$ $had$ $a$ $part$ $of$ $it$ $killed$. $Thus$, $if$ $the$ $app$ $actually$ $waits$ $for$ $this$ $stack$ $to$ $return$, $it$ $will$ $wait$ $for$ $all$ $eternity$.

    And this is what likely happens with your book. The pReader opens the file and tries to parse the images. Since these are expensive operations, they're spun off into a separate execution stacks, so that each image import gets a full 2 seconds to do what it has to do.

    Unfortunately, if a single image needs more than those 2 seconds, nothing can be done. Reading the image is an atomic operation. It takes however long it takes; the execution can not be split any further. So, if you load a particularly large file, or the read of the file is delayed a bit, the image import stack might get killed by WebOS.

    And in that case, the import process will wait until eternity for an answer that will never come. And without that answer, it will never progress.

    Javascript simply sucks.



    But anyway, if you could send me the file, I can see if I can track the problem and maybe do anything about it.
  4. #1184  
    Jappus how easy would it be for someone to port the non-native version of pReader to Android? I'm looking at getting a nookColor and found out they stripped eReader support from it. Is pReader too intricately woven into webOS to make this feasible?
  5. #1185  
    Quote Originally Posted by Jappus View Post
    But anyway, if you could send me the file, I can see if I can track the problem and maybe do anything about it.
    Whoa, thanks for the extremely interesting and informative wall of text. That seems...kinda bizarre that Palm would force every Mojo program to share a single stack. Of course, expecting JSJSJS $to$ $be$ $doing$ $any$ $sort$ $of$ $processor$ $intensive$ $work$ $is$ $pretty$ $bizarre$ $too$. $Can$'$t$ $wait$ $for$ $the$ $native$ $pReader$ $to$ $get$ $a$ $beta$ $release$.

    Anyways, I got home and opened up the epub. 67 images inside, totaling 4.8 mbs. Stripped out everything except the cover page and it works fine now, so that's almost definitely the problem.

    I can still PM you the file if you want; I didn't want to post it without asking since it's a scene-rip. But I mostly blame that on Robert Jordan's widow refusing to release paperback/ebook versions for several months. Call me shallow, but I'm a grown man. I'm not trying to ride a packed train into the city while hunched over a giant hardcover book with an embarrassing "generic terrible fantasy art" cover. Sheesh.
  6.    #1186  
    Quote Originally Posted by Leathal View Post
    Anyways, I got home and opened up the epub. 67 images inside, totaling 4.8 mbs. Stripped out everything except the cover page and it works fine now, so that's almost definitely the problem.

    I can still PM you the file if you want; I didn't want to post it without asking since it's a scene-rip.
    I don't think you need to bother ... yet, after all, the whole ePub decoder has to be rewritten anyway.

    If it still won't work in the native version, then I'll be really interested in the file. But at the moment, I'm mostly busy with getting a native alpha version on track.
  7. #1187  
    I purchased a book that's over 45Meg, due to a lot of photos I'd guess, anyway I believe preader said there was a 10 Meg max size due to some limitation. Any idea if/when that limitation is going away?

    Thanks for the excellent Reader.

    Curtis
  8. #1188  
    Quote Originally Posted by Leathal View Post

    Anyways, I got home and opened up the epub. 67 images inside, totaling 4.8 mbs. Stripped out everything except the cover page and it works fine now, so that's almost definitely the problem.
    How do you do that? That's exactly what I need to accomplish.

    Thanks
    Curtis
  9.    #1189  
    Quote Originally Posted by cloudyifr View Post
    I purchased a book that's over 45Meg, due to a lot of photos I'd guess, anyway I believe preader said there was a 10 Meg max size due to some limitation. Any idea if/when that limitation is going away?
    In the next few months. At the moment, I'm hard at work with the native version (at least as much as my free time permits), which can read almost arbitrarily large files.

    At the moment, if I load a file with Javascript, it has to be moved completely into main memory; every last bit. That's why WebOS only permitted to load files up to 10MB size. In C/C++, I can load up however much as I want --- but I don't even have to. Of the files I load, only the text part is going into memory. Everything else (images, mostly) is extracted directly without touching main memory even once.

    So of your 45MB file, only a few MB will actually touch main memory, which is one reasons why the import process will be oh so much faster. Think of <5 seconds per file, instead of several minutes.

    My main problem is currently that the page fitting still takes an inordinate amount of time. And with inordinate, I mean 0.2 to 0.8 seconds per page. The lower time is roughly how long it takes now with pure JavaScript, but that's already heavily optimized.

    Before release, I hope to push that time to under 0.05 seconds, in other words, below 50ms, which is the threshold where most people start to not notice the page change delay anymore.
  10. #1190  
    Quote Originally Posted by govotsos View Post
    Jappus how easy would it be for someone to port the non-native version of pReader to Android? I'm looking at getting a nookColor and found out they stripped eReader support from it. Is pReader too intricately woven into webOS to make this feasible?
    I don't know if this got mixed in the shuffle so I'm reposting it.
  11.    #1191  
    Quote Originally Posted by govotsos View Post
    Quote Originally Posted by govotsos
    Jappus how easy would it be for someone to port the non-native version of pReader to Android? I'm looking at getting a nookColor and found out they stripped eReader support from it. Is pReader too intricately woven into webOS to make this feasible?
    I don't know if this got mixed in the shuffle so I'm reposting it.
    Yeah, that got lost in the shuffle.

    Mhhhm, porting the Javascript version of the pReader to Android would be somewhat difficult. For a number of reasons:
    • Android does not offer a useful way to run Javascript programs as applications.
    • Even if there were, the whole pReader GUI is built around WebOS/Mojo objects like buttons, lists, dialogues, etc. pp. You'd have to replace almost the whole frontend, even if you got the backend to run.
    • Javascript has exactly zero support for loading multiple JSJSJS $files$ $into$ $one$ $app$. $Basically$, $WebOS$ $does$ $a$ $lot$ $of$ $black$ $magic$ $to$ $load$ $each$ $JS$ $file$ $in$ $time$. $You$'$d$ $have$ $to$ $replicate$ $this$ $capability$, $because$ $the$ $pReader$ $very$ $much$ $expects$ $all$ $files$ $to$ $be$ $loaded$ $correctly$.
    • And even if you get all that to run, you'll find that many parts of the back-end breaks, because the pReader stores its configuration and files in WebOS Depot and an SQLite database. Basically, you have to replicate those features, too, to get even the back-end to work.


    So, to make a long story short, you could get it to work, but you'd need to replace a lot of it. My fellow developer Retrobits has managed to cajole a Windows JSJSJS-$Engine$ $to$ $run$ $at$ $least$ $the$ $back$-$end$ $of$ $the$ $JS$ $pReader$, $so$ $it$ is possible. But really, that's a lot of headaches.

    JSJSJS $simply$ $sucks$. $It$'$s$ $not$ $really$ $portable$, $it$ $breaks$ $at$ $the$ $slightest$ $provocation$ $and$ $is$ $a$ $standard$ $no$-$one$ $bothers$ $to$ $implement$ $in$ $a$ $compliant$ $way$.



    So much for the bad news. Now on to the good news: The back-end of the native pReader is 100% pure, ISO-compliant C/C++ [1]. That means it can be compiled and works on WebOS, Linux, MaxOS-X, BSD, Solaris, Windows, BeOS, Haiku, whatever. As long as you've got a C++ compiler, you're good to go. Of course, you have to remove the WebOS/Mojo IPCFunction stuff, but that's just one class that creates the JSJSJS/$C$++ $communication$ $layer$ $and$ $is$ $not$ $necessary$ $on$ $any$ $of$ $those$ $other$ $platforms$. $And$ $one$ $library$ $does$ $make$ $use$ $of$ $the$ $SDL_mutex$ $implementation$; $but$ $any$ $mutex$ $implementation$ $will$ $do$ $there$, $like$ $the$ $one$ $of$ $the$ $ubiquitous$ $pthread$ $library$.

    For the native backend, your system only needs to fulfill these two demands:
    • A working C++ compiler (ideally gcc) and a somewhat modern glibc for that platform (or a cross-compiler, in case of embedded systems like Smartphones)
    • All the necessary prerequisites for libxml2 (which is exactly the prerequisite above. Libxml2 is really, really, portable)


    That's it. If you fulfill that, the native pReader backend will run on your system. And, if I may be so bold, this means it works on Android, too. With pretty much no changes.

    Until release, I'll most likely add another dependency for charset conversion; either IBM's ICU or GNU's iconv. Both can be just as easily compiled as libxml2.


    So, basically, your best bet is to simply wait until I'm done with the native version, and then simply write a new front-end for Android. Since the frontend only displays the data delivered to it by the back end, this is a rather trivial, if a slight bit time-consuming task[2].


    Hope that helps.


    [1] - Okay, I admit, that's a lie. I do make use of the TR1/C++0x unordered_map implementation; but that can be replaced by any compatible hash_map implementation, or if you're crazy even just a std::map. But usually you don't need to bother, since pretty much every current compiler / glibc version supports this map type.

    [2] - The time-consuming problem is: You need to write a new page layouter. The actual task of displaying the text on the screen has to be done in the front-end. This is the only spot where WebOS really shines, since your Web-Browser IS a layouting engine. All the pReader front-end has to do is to manipulate a few CSS styles and to make sure that it finds out how much text is necessary to fill a page. This might be a bit more difficult in Android --- but certainly not impossible.
  12. #1192  
    Yikes. Answer my question. SOMEone could do it, not me. It's been so many years since I did any programming, I probably couldn't FIND a Hello World, much less write one any more

    If I understand #2 right, could the backend just feed right to the browser? Android used the same Webkit core webOS does, right? Or am I over simplifying?
  13.    #1193  
    Quote Originally Posted by govotsos View Post
    Yikes. Answer my question. SOMEone could do it, not me. It's been so many years since I did any programming, I probably couldn't FIND a Hello World, much less write one any more
    I guess now you have a good reason to start again. ^__^

    If I understand #2 right, could the backend just feed right to the browser? Android used the same Webkit core webOS does, right? Or am I over simplifying?
    Android uses the WebKit engine for its browser, but not as the basis for the GUI of the entire OS. Feeding data directly into the browser will be somewhat difficult, as you'd have to co-opt the rendering engine of the browser, without invoking the browser at all. Remember, you just need the engine, not the full browser UI and all the other things that are bolted onto it.

    This is the greatest difference between WebOS and all the other Handset OS's. WebOS invokes each application in its own HTML+CSS+JSJSJS $rendering$ $engine$, $whereas$ $all$ $other$ $OSs$ $give$ $you$ $a$ $simple$ $2D$/$3D$ $graphics$ $library$ $and$ $a$ $few$ $widgets$, $at$ $best$. $That$'$s$ $good$ $for$ $games$, $but$ $horrible$ $for$ $the$ $tedious$ $work$ $of$ $just$ $getting$ $text$ $and$ $images$ $on$ $screen$.

    As far as I can see, you have three choices on Android:
    1. Write a fully native C/C++ and implement your GUI either directly through the framebuffer (very, very low-level; it means writing each pixel into memory; very 1960s style), the SKIA library (still low-level, but with support for complex things like text! ), or by using OpenGL.
    2. Write your app completely in Java, and use the Widgets provided by WebOS -- I think you can even access the WebKit engine that way, but I'm not sure.
    3. Write the front-end in Java, and simply use call to the native back-end to get your data. GUI is the same as in (2).

    (3) is pretty much exactly like the WebOS design, only with Java replaced by Javascript (which is worse, except for the neat direct access to a rendering engine).

    So, it really depends on what you can do on Android -- if you have access to a rendering engine capable of displaying text and images, the port will be easy. If not, things get worse. If someone's here who knows the Android design better than me (which is not all that difficult), maybe he can voice in his or her opinion.


    Of course, you could always just grab a version of WebKit yourself, statically compile it into your app and then just run it that way. But that's like getting to your bathroom by riding the shockwave of a nuclear blast.
  14. #1194  
    To give you an idea of how rusty my coding is, I DID that 60s coding. At the time, everything was machine language, just 1s & 0s for a while - that's all we had. I was so happy when we got a PDP-10! No more toggling bit by bit!!

    Desk checking was so essential then - computing resources were so limited & we didn't have error checking compilers. I think that's something missing today - programmers rely too much on the tools, doing seat of the pants programming with not enough planning and realizing why one command can throw everything off. They find out during compilation instead of desk checking logic first. I don't know which is better. I think we had a better understanding of the hardware, but that's the big advantage of high-level languages - the abstraction lets you work more with concepts and less worry about theminutae. Actually, I'm not sure that level of understanding is even possible these days - what we had was so amazingly simple compared to what's available today.
    Last edited by govotsos; 11/12/2010 at 05:59 AM.
  15. rgloor's Avatar
    Posts
    159 Posts
    Global Posts
    160 Global Posts
    #1195  
    Quote Originally Posted by govotsos View Post
    To give you an idea of how rusty my coding is, I DID that 60s coding. At the time, everything was machine language, just 1s & 0s for a while - that's all we had. I was so happy when we got a PDP-10! No more toggling bit by bit!!
    Wow...!
    How nostalgic.
    That reminds me of my rusty times.

    As a flight test engineer in the mid-to-late 80s, I was also "running" the PDP-11/23+ at the flight test department.
    A wonderful real-time machine, we used for telemetry flight test data acquisition.
    Analysis was another chapter.

    Sorry, to get carried away. But hey govotsos: Your comment on the PDP-10 just triggered some nostalgic moments.


    OK. Let's get back to topic!
    Jappus, just don't let yourself be distracted by our chit-chat.
    Please stay focused on your great work on the native version.

    Hardly can't wait.
    Last edited by rgloor; 11/17/2010 at 02:02 AM.
  16. #1196  
    Quote Originally Posted by cloudyifr View Post
    How do you do that? That's exactly what I need to accomplish.

    Thanks
    Curtis
    Epub files are just renamed zip files. Change the extension to .zip and open it up. The rest should be self-explanatory. As always, make a backup before you start editing stuff.
  17. #1197  
    Quote Originally Posted by Leathal View Post
    Epub files are just renamed zip files. Change the extension to .zip and open it up. The rest should be self-explanatory. As always, make a backup before you start editing stuff.
    Wow, thanks! Easiest thing I've ever done on a computer. Well once I knew how!

    Curtis
  18. #1198  
    First, let me just say that I love pReader and have been using it for almost a year now. Having said that, I do have one little frustration with it, and that's that every now and then, books will disappear from my library. It's the oddest thing and I can't figure out what causes it. (If I could, I'd probably be able to figure out how to make it stop!)

    So today, I launched pReader, and as soon as it took me to the library screen instead of launching my current read, I knew something had gone wrong. This isn't the first time that's happened. Imagine my dismay, however, when I looked at my library and saw that it showed me 88% of the way through a book that I finished 2 days ago, the book that I read after that one was completely missing (along with all the annotations I had made), and the book that I'm currently about 45% of the way through is also missing (again with annotations gone).

    As I said, I have had this sort of thing happen before, although I don't think I've ever had so much disappear on me before. Sometimes, whole books won't vanish, but instead, it'll revert me back to an earlier percentage in a book. It's like for some strange reason, pReader doesn't always write to the database correctly, if I'm wording that correctly. Has this ever happened to anyone else? I did some searching of this thread but couldn't find any other posts regarding this type of issue. Does anyone know what causes this to happen? Is there any way at all of recovering the annotations that I lost? Any help would be much appreciated!
  19.    #1199  
    Quote Originally Posted by Shadowcat View Post
    First, let me just say that I love pReader and have been using it for almost a year now. Having said that, I do have one little frustration with it, and that's that every now and then, books will disappear from my library. It's the oddest thing and I can't figure out what causes it. (If I could, I'd probably be able to figure out how to make it stop!)
    Well, one thing that'll make it stop is the native version, since it'll ditch all the SQLite cruft that I have to use in the JSJSJS $pReader$ $and$ $replace$ $it$ $with$ $a$ $simple$, $plain$ $old$ $file$-$based$ $format$.

    The SQLite connections are horrible. They drop at the slightest provocation. For example, if you attach the USB cable, BAM, all SQL connections are dropped. If too many connections are open, BAM, some get dropped. The pReader has a detection for when that happens and re-establishes the connection, but it's most likely not 100% reliable in all circumstances.


    Anyway, since the native version is built on top of a wholly different library storage system, that means you'll lose your current library anyway. There's simply no sane way to convert it, because the old one is stored in a heavily Javascript-friendly way, but not in a way that allows easy conversion.

    But after that, you'll be able to easily back up your entire library and the entire thing should be much more stable, since it's based on a much simpler system. Furthermore, it'll also finally allow bulk-imports of many files at once.

    So, I'd rather improve the new native version, than to concentrate on the version that'll soon go the way of the dodo anyway.
  20. #1200  
    @Shadowcat I've had the same thing happen frequently. The "fixes" I've used that sometimes work: at the end of a reading session I back swipe to the library then reopen the book, I exit pReader, reopen pReader & my book usually is in the right place.

    I do this thinking (probably incorrectly) that going to library & exiting force an update to the position pointers.

    I used to leave pReader open all the time & noticed this happens more often if I do. That might be related to the sql that Jappus was talking about. No I exit pReader when done reading.

    One more thing I noticed that can cause this is if pReader is open when a Luna restart or full restart is performed. Closing pReader before doing these helps also.

    Hope some of this helps.

Posting Permissions