On request of users (dracodoc, kai771 et al.) I have added a new command
`O` which toggles the display (via dimmed box) of the page overlap
areas. This setting is saved on a per-book basis, i.e. is specific to
the book, which is the desired behaviour as one wants dimming on some
books (math, physics, etc) but not others (fiction).
After some consideration I believe that it is best to get rid of
"Retrieving TOC..." message altogether on the following grounds:
1. The code in unireader.lua/crereader.lua that has to deal with this
specifically can be removed.
2. The fillToc() is a data manipulation function and ought not to touch
graphical state.
3. The files for which retrieving TOC can take a long time are
_exceptionally_ rare (only two are known to me --- both are my own
editions with detailed morphological tags which require massive
hierarchical TOC for quick navigation)
4. Users are going to be confused when they press Menu for the first
time and see "Retrieving TOC..." staying on the screen until they press
Menu again.
Don't try to register the two fonts Dingbats.cff and StandardSymL.cff
with crengine because it will reject them anyway. But we cannot simply
remove these two fonts because they are used internally by mupdf to
emulate "builtin" fonts which are mandated by Adobe PDF specification to
be present in every valid implementation.
This fix makes the behaviour of Back command handler in crereader
identical with that in unireader, i.e. the last position is saved in
Jump History when pressing Back, so you can return to it by pressing
Shift-Back enough times.
Also, with this change we would need to handle the need for redrawing
the current page because the :addJump() method can force the call to
fillToc() (if TOC is not already present) and this will display
"Retrieving TOC..." message which will need clearing away.
Even after restoring to the previous version, this function had a slight
bug that would cause a crash on valid .zip files (e.g.
mupdf-thirdparty.zip in kindlepdfviewer make tree). The reason is
because the value of s may be not nil, but the string.match() would
return nil and so string.lower() would get nil as an argument and crash.
So, we have to guard against this carefully.
When I rewrote the function CREReader:ZipContentExt() I lost
the code path leading to "Error unzipping file." message.
This was now restored, plus two required changes:
1. There is no need to surround io.popen() with assert() as it
never fails, not even if the command is non-existent. Besides,
even if it did, crashing the whole viewer just because for
some reason we can't unzip the file is not a good idea.
2. The "while tmp" after tmp=assert() assignment is meaningless.
Even after removing assert() it is still meaningless because io.popen()
can never return nil, oddly enough.
Technically, the only serious problem in this function was the code:
local tmp = assert(io.popen('unzip -l \"'..fname..'\"', "r"))
while tmp do
s = tmp:read("*line")
if i > 3 then tmp:close(); break; end
i = i + 1
end
It is meaningless to evaluate the truth of the return value of assert()
and the above code gives the impression that it relies on the
(undocumented and unreliable) fact that after tmp:close() tmp will be
nil, even though in actual fact it does because it breaks out of the
loop.
However, having looked at the function I saw that the whole thing
can be rewritten in a much simpler way:
local tmp = assert(io.popen('unzip -l \"'..fname..'\" | head -4 | tail -1', "r"))
s = tmp:read("*line")
tmp:close()
Redraw the current page when selecting a TOC entry.
Otherwise the correct page is shown only after the next Menu press
or anything else that does current page redraw, e.g. Shift-R.
UniReader:showMenu() method invokes :cleanCache() method which is
non-existent for CREReader object and causes a crash if you press C
after pressing Menu while viewing any of crereader-handled files (fb2,
epub, etc.)
2. Get rid of the calls to self:fillToc() from the places in the code which cannot affect TOC.
I assume the reason for these calls is that they are needed in the original CoolReader application
(because there the TOC displays the virtual "page numbers") and were brought over to our crengine.lua
during the port.
if the file with zip-extention is not valid zip or it contains the improper entry (not crengine-related files), function CREReader:open(filename) return false, "the error description"
1. Improved the method to restore position in document after rescaling font face, size, weight, interline spacing, etc.
2. Fixed rotation functions inherited from unireader.lua
3. Removed hotkey for the function of manual cropping inherited from unireader.lua; reason: not crengine-related
4. Added fast navigation functions via Shift+fiveway: jump to previous / next TOC-entry; scroll 10 pages backwards / forward
