Otherwise the VmData size will keep increasing in multi-threads mode.
Although the increasing VmData size doesn't mean there is enormous
memory leak, it does show that the thread stack is not handled properly
when threads exit.
Because the lua reader is single threaded on which both user inputloop
and background page rendering is processed. Although there is a pretty
good precache system to save user's time spending on waiting for the
rendering when going to the next page, user input is indeed blocked when
running the precache thing. The situation is even worse in koptreader as
reflowing on page would usually take several second, in this period
users cannot move to the next page view even it's already in the cache.
This patch will let precache run in the background in a seperate thread
so that the koptreader is still responsive when precaching the next
page. Now it only just works. Welcome to find out bugs in it.
Many users complained that the reflowing process is too slow. This is
rather a speed-quality dilemma. Trade-off can be made by decreasing the
dpi of source page. And by default quality is prefered.
By default the indentaion detection is enabled in K2pdfopt. This will
sometimes generate very poor reflowed page when there are sidenotes on
the page which would be treated as indentation. Disabling indentaion
detection will rescue the reflowed page from this situation.
For now only line spaceing and word spaceing are configurable with
'F'/'Aa' commands. And device size are passed to k2pdfopt in place of
the hard-coded default width and height(via @dpavlin).
Conflicts:
koptreader.lua
this is far from complete since in fact, we read page references
which follow a more complex syntax. while specifying page numbers
is one option for them, they might also specify page names. we
currently do not yet have code for this case and we will return
"-1" for all page references we can not parse.
The DjVu info shown in the status line includes:
1. Physical page dimensions.
2. Current value of gamma and (in square brackets) the value of the
display for which the page was designed.
3. Page resolution (in dpi).
4. Page type.
For the end-user probably the most useful bit is the page type as it
helps him decide which rendering mode to choose for this page (and also
explains why he can't see anything on the page --- e.g. when rendering
some COMPOUND or PHOTO pages in B&W mode). For the developer the
physical page dimensions are also interesting as they allow to estimate
the amount of time needed for page decoding and cache efficiency.
Conflicts:
djvureader.lua
djvu pixel format on each redraw of the page as this can be done once on open and close
of the document. Also, set dither bits to 4 to help djvulibre choose the most
optimal dithering algorithm for the Kindle. Also, make coding style of "if(" -> "if ("
consistent (both instances were used, but "if (" was more frequent).
Conflicts:
djvu.c
Also added support for all other rendering modes handled by djvulibre.
Also made the message print a human-readable description of the mode rather than just the number.
Conflicts:
djvureader.lua
unireader.lua
a) add support for switching the rendering mode between B&W (default, 1) and COLOUR (0) values.
b) handle the gamma values correctly.
Conflicts:
unireader.lua
