DjVu viewer with full zoom and panning around the page

[jusmee]

Originally Posted by keng2000

in case v5 Firmware.
It is almost the same of V3 firmware.
1. Same structure but different size in each part. (That is easy to check)
2. ro.fs and root.fs are cramfs but somehow the disassemble method could be difference. (header is OK, but refuse to extract.)

Yes, this is what I found also. At least, when at looked at the header, size seemed to be x7E (126) blocks instead of x36 (44). Extracting that size however does not yield a mountable root.fs filesystem. I suspect ro.fs is a different size too, and that's throwing out all the rest after it.

[jusmee]

Originally Posted by jusmee

Yes, this is what I found also. At least, when at looked at the header, size seemed to be x7E (126) blocks instead of x36 (44). Extracting that size however does not yield a mountable root.fs filesystem. I suspect ro.fs is a different size too, and that's throwing out all the rest after it.

In fact, the kernel image is twice the size by the looks of it

block 0 - header
block 1-2 - kernel
blocks 3-8 - ro.fs
blocks 10-135 - root.fs

that'll be something like

dd if=$file of=$out_dir/zImage bs=1M count=2 skip=1
dd if=$file of=$out_dir/ro.fs bs=1M count=6 skip=3
dd if=$file of=$out_dir/root.fs bs=1M count=126 skip=9
dd if=$file of=$out_dir/logo bs=1 count=240000 skip=$[1024*1024*135]
dd if=$file of=$out_dir/jffs2.fs bs=1M count=2 skip=136

If I have it right.

The resulting ro.fs and root.fs mount successfully but appear to contain nothing - so something is still amiss.

[tigran]

Originally Posted by keng2000

Try this one
Alice in Wonderland.djvu

Many thanks! You are absolutely right, the cover page is not displayed correctly and in this case it seems to be the fault of my libdjvu, i.e. a bug (the "most optimal mode" chosen for the cover page is not "optimal" at all as it renders nothing on the screen). I'll try to fix this as soon as possible. Hopefully today or tomorrow the latest...

Update: the bug is fixed now and tested --- all works (the other missing pictures in this file are shown correctly now as well). I am finishing off another feature right now (save/restore state for quickly switching from zoomed to unzoomed states and back) and hopefully today will upload the new libdjvu 1.94 which will have the fix as well as this new feature.

[tigran]

Originally Posted by hug

Congratulations for a nice job!
I read a lot of scientific articles on real paper mostly because multi-column pdfs with tables and pictures tend to go horribly wrong with ADE. I might convert them from pdf to DjVu and read them using your DjVu viewer. My first impressions are positive, but setting the right amount of horizontal step to match the two columns (sometimes not half-half) is time-consuming. I don't understand how the "Toggle multicolumn mode", works or when it is on or off. Could you please give some hints?
Thanks in advance!!!

Thank you. Multicolumn mode works like this --- pressing Next page (i.e. '0' in portrait or '9' in landscape mode) checks if the current window position is "at the bottom of the page BUT there is some space on the right to move the window to" and if it is true then it shifts the window to the right AND all the way up to the top of the page. This has the effect of "switching to the next column". The number of columns could be more than 2. For example some chess books and ancient Bible editions have 3 columns and you can simply zoom in appropriately to see just the column you desire. Then just pressing "next/previous page" buttons will slide your window along the current column and switch to the next one when you hit the bottom of the page and only when there is no more space on the right the page will be turned and window positioned at the upper leftmost position on it.

Note that there is a tiny "bug" or assumption here. Namely, it all works fine on European i.e. left-to-right books. But if you read a multicolumn book in Hebrew or Arabic or Syriac or other such language that uses "right to left" direction then the above algorithm will move your window in the wrong (ie left-to-right) way...

[tigran]

I released libdjvu 1.94 which has both the bugfix described above (so Alice in Wonderland works fine) and the "save/restore window" feature tied to key '5'/long '5'.

Please note that the localization files have changed and so it is not enough to simply copy libdjvu.so to .lib of ereader's internal storage. Also, the way djvulibre is compiled has changed as well and you will need my compiled ones from arm-lib too.

[hug]

Thanks again for your explanations!
Multicolumn mode works OK, but most of the times I am not able to locate the exact half of the sheet by zooming; that is I create two text columns and an additional thin empty column on the right, which I have to go through to flip over the page. Of course, this is npt properly a bug, but it is annoying. I thought that pressing a short number 6 at the end of the second column might take me to the beginning of the first column of the next page, but it doesn't usually go like this. I might humbly suggest to improve the viewer by adding this capability!
Hey, the "save/restore window" feature is great for switching to see full-page illustrations!!
Another suggestion: many scanned / converted texts have a specular configuration (left versus right pages). This can happen with one- or multi-column documents! Could Libdjvu also invert the column location on each page (just odd/even or this might be too complicated even to understand. )
By the way, I am not very fluent in left-to-right languages!

[tigran]

Remember, you can manipulate HORIZONTAL shift value as well, so there is no need to create an empty thin column in the middle. Just set a large enough (even more than 100%) value of horizontal shift to skip through that white area automatically.

[hug]

you are completely right: centering on a column and choosing a horizontal step of 120% solves the third column issue and concatenates the end of the second column with the beginning of the first column of the next page. I have also been playing around with an odd-even paged document, and choosing a smaller amount of zoom leaves enough space on both sides of the column to compensate for differences between odd and even pages. The characters might turn out a bit small to make a comfortable read, but it can be turned 90º!

Well, I do seriously think that OI developers should take a look at your viewer and vamp up LocoPDF!

two questions:
- how do I upgrade the V1.93.181209 included in v2.22es091219 TIRWAL 1.4 to v1.94, since it requires more than dropping the libdjvu.so??
- what's the best way to convert pdf to djvu? I am using TrustFM's GUI for PDF2DJVU in Win or Linux, but it is buggy in large documents (and no tools apparently on Mac)??
thanks in advance

[tigran]

Originally Posted by hug

- how do I upgrade the V1.93.181209 included in v2.22es091219 TIRWAL 1.4 to v1.94, since it requires more than dropping the libdjvu.so??
- what's the best way to convert pdf to djvu? I am using TrustFM's GUI for PDF2DJVU in Win or Linux, but it is buggy in large documents (and no tools apparently on Mac)??
thanks in advance

- If you are able to update the rootfs/root/language files with the stuff in msg subdirectory of libdjvu*tar.gz then yes, you can do it.

- Have you tried my simple pdf-to-djvu.sh script? Converting PDF to DjVu is a very complicated thing, depending on what level of information (e.g. hyperlinks, bookmarks etc etc) that you may wish to preserve. But if you don't want any of those "extras" and just want a plain B&W DjVu result optimal for viewing on Hanlin V3 then even my pdf-to-djvu.sh script will do the job.

[hug]

Sorry about my ignorance, but how do I run the .sh from windows? Or is it exclusively for Linux?

[tigran]

Originally Posted by hug

Sorry about my ignorance, but how do I run the .sh from windows? Or is it exclusively for Linux?

Yes, Linux only.

[BobC]

Originally Posted by hug

Sorry about my ignorance, but how do I run the .sh from windows? Or is it exclusively for Linux?

Have a look at http://code.google.com/p/pdf2djvu/ which is a PDF->DJVU convertor for Windows.

BobC

[Qbspin]

The problem mounting the V5 ro.fs and root.fs is the cramfs format used by Jinke. The first modification to cramfs standard is the offset size, changed to 32 bits, so the i-node length is 16 bytes (and 12 in standard). A modified version of fsck.cramfs is needed to decompress the files in these images.

If you are interested I can show you the code and another "special" structure included in root.fs (but not in ro.fs).

Regards

QB

[paul1981]

Originally Posted by Qbspin

The problem mounting the V5 ro.fs and root.fs is the cramfs format used by Jinke. The first modification to cramfs standard is the offset size, changed to 32 bits, so the i-node length is 16 bytes (and 12 in standard). A modified version of fsck.cramfs is needed to decompress the files in these images.

If you are interested I can show you the code and another "special" structure included in root.fs (but not in ro.fs).

Regards

QB

Hello,

Qbspin, I'm trying to decompress the firmware of the Hanlin v5 provided by Jinke but I'm having problems because of the cramfs version used (as you mentioned). I'm able to mount root.fs.v5 on a local directory, but when I try to untar something on it I get an I/O error. I'm using this firmware tools.

Were you able to do this by modifying that fsck.cramfs? Could you please explain us how you did it?

Thanks a lot,

[jusmee]

I too, would like to successfully be able to mount and modify the file system, then put it back in the bin file. Is this possible?