First impressions
v-python opened this issue · comments
It is great to have this option for displaying DJVU files in a browser. I haven't yet attempted to look at the code, just played with the demo a bit. Here are my first impressions, and ideas for minor improvements.
Not all documents have big margins at the top to accommodate the toolbar overlaying the document. Would be nice to have an option for the toolbar to be positioned separately from the djvuContainer, or in its own space above the graphics area, if within the djvuContainer. The relative sizes of the controls and the document margins also vary depending on the size of the browser window, so what might look fine on a big window might not look so fine on a little one.
Pretty dog-slow on a phone (no surprise, really), but would save data transfer by using DJVU instead of other formats.
Would be nice if the default size were "fit to width" rather than "100%".
The scrollbars seem to overlap the document a bit... not sure they are needed on mobile... default scrolling there is by tap-n-drag, rather than scrollbars... so default scrollbars would have disappeared on mobile, but your custom ones don't. Maybe that should be an option, too... standard vs custom scrollbars.
Hi, thanks for taking the time to comment.
The scrollbars and controls over the document should not be a problem because they're supposed to disappear after a few seconds without mouse movement or touch. But now I see it doesn't always work as expected - it's probably related to the text layer. I'll look into that.
As for the default size - I'm not sure, I guess 100% is the most convenient size if you have some text that you want to read, which is probably the most common use case. Personally, I find it annoying when some PDF viewers start with "fit to width" and everything is way too big.
Another point is that DjVu rendering looks the best and is the most efficient with a few selected sizes (those available in the size drop-down list) - other, non-standard sizes require additional scaling.
Re: toolbars & scrollbars.
One behavior I see on Firefox desktop is that if I move my mouse off the window, while the window is active, the toolbars and scrollbars eventually disappear. On mobile, it is very hard to move the mouse off the window, since the window is full-screen. That would likely be true on a maximized desktop window on a one monitor system, also. That's why I'd prefer to see the toolbar and scrollbars not overlap the document, at least as an option. And on mobile, scrollbars aren't needed anyway, you tap & drag the content.
The other behavior I see on Firefox desktop, is that if the window is not active, and the toolbar & scrollbars have disappeared, that placing the window back over the Firefox window brings back the toolbar & scrollbars... but moving the mouse away again does not make them disappear.
Anything that depends on mouse hover position is very, very difficult to support on a touchscreen device, be it desktop or mobile... I'd surely rather see an always visible toolbar (just put enough padding above the document page to allow the top of the document to be seen at first, if it then scrolls under the toolbar and a bit is obscured, no problem, the user can scroll it back down). And default scrollbars, although perhaps ugly, are hard to improve on when mobile doesn't use them, and non-touch desktops need them... lots of cases to handle. I'd surely rather see you spend time improving the DJVU interpretation code, rather than "fluff".
100% means different things on different devices... my phone / browser did its own "fit to width" based on the 100%... But with "maximized" windows and "wide screen" (I prefer to call them "short screen") displays "fit to width" is often too big, I agree... I seldom use "maximized" windows as a result. Maybe an option of "fit to width, up to 100%" would a nice default?
I wondered where the size selections came from, as they seemed somewhat arbitrary, and varied from document to document! "most efficient" is certainly important, especially on slow mobile devices. Not sure if the DJVU algorithm lends itself to speedups with technologies like ASM.js, but that would be an area worth investigating if you haven't already... even my fast desktop took a while to render it. Also, if you aren't already using WebWorkers, that would allow leveraging multiple cores, again, if the algorithm can be subdivided into parallel parts.
Regarding the display, I noted that in Firefox (but not Opera) there were fine grey vertical and horizontal lines across the image at "fit to width" size. Perhaps that is what you meant by "looks the best"?
I've not looked at the source code, but I'm guessing you are re-rendering from DJVU for each scale selection? That may produce better quality at some resolutions than my alternative below, but I wonder if my alternative would be faster overall, "good enough" quality, and avoid display artifacts? My alternative is to simply always decode to 100% and then let the browser scale the bitmap. I suspect for sizes less than 100% this would be faster and avoid the fine lines. Perhaps if one goes oven 100%, it would be better to pick the next bigger "efficient" DJVU size, and then let the browser scale down from there... this would allow for any scale factor, rather than just particular ones (which may not always fit people's needs... this one being too small and the next one being too big).
Anyway, thanks for responding, and I'm looking forward to version 1.0 :)
One behavior I see on Firefox desktop is that if I move my mouse off the window [...]
Anything that depends on mouse hover position is very, very difficult to support on a touchscreen [...]
You don't have to move the mouse off the window, just stop moving it. On mobile, just stop touching. It works as far as I could test it (except when moving/touching over text, as mentioned earlier).
Scrollbars on mobile are still useful to determine which part of the page is displayed (and click&drag panning works with the mouse as well, unless you click on a text).
The other behavior I see on Firefox desktop [...]
I see this too. That's something to be fixed, but not a high priority.
[...] Maybe an option of "fit to width, up to 100%" would a nice default?
I'm still not convinced it would be better most of the time. But I think it'd be good to add configuration setting so that someone providing the content can decide on starting viewing size (including "fit to width, up to 100%" and similar options).
[...] Not sure if the DJVU algorithm lends itself to speedups with technologies like ASM.js [...]
I think I was considering asm.js before starting with this project, but it seemed too unfamiliar and risky. I don't see how it could be employed with my current stack, where I work mainly with java code and have js generated by GWT.
Also, if you aren't already using WebWorkers, that would allow leveraging multiple cores
Sounds like a good direction to explore. The main difficulty is that GWT doesn't support it directly, but I guess it can be worked around.
Regarding the display, I noted that in Firefox (but not Opera) there were fine grey vertical and horizontal lines across the image at "fit to width" size. Perhaps that is what you meant by "looks the best"?
Yeah, among other things. I'm still planning to fix it eventually :)
I wonder if my alternative would be faster overall, "good enough" quality, and avoid display artifacts?
It basically works as you suggest - if the desired size doesn't match one of djvu's provided sizes, then the closest bigger size is rendered and then scaled down in canvas (so I guess it was an exaggeration to say that some sizes are less time efficient).
You don't have to move the mouse off the window, just stop moving it. On mobile, just stop touching.
"stop touching" doesn't work for me... the mobile scrollbars and toolbar just stay forever... Firefox on Android.
I think I was considering asm.js before starting with this project, but it seemed too unfamiliar and risky.
Pretty standardized now, I guess. Not sure when you started. Seems if GWT is going to generate js code, though, it should be or become asm.js aware... and if not, then recoding in asm.js directly may give a speed boost... or maybe not, depending on if the DJVU decompression algorithm fits the asm.js model, or not.
(so I guess it was an exaggeration to say that some sizes are less time efficient).
Well, an extra scale operation is less efficient, so not really an exaggeration, but maybe not a huge impact compared to the DJVU decompression.
Sorry for the question: do you plan to implement the djvu encoding< i.e. java api for creating djvu file from scratch or manipulating the existing one - adding pages, texts, extracting texts etc, not just view?
No, this is way out of scope of this project and I don't see a need this kind of features.