This depends on visible selections and not on content of file. So if we
have search results on screen this will be more than 0, but if we don't
we won't get any link shortcuts
This is to make adding support for new formats easier.
See the file pic_jpeg.h for the description of the interface that each
image format must support.
Conflicts:
Makefile
If the number of colour components is neither 1 nor 3 we should remember
to free the buffer holding the raw decoded image before returning the
error to Lua.
On some distributions (e.g. Ubuntu) the shell used for scripts is dash,
not bash and we explicitly rely on bash's features in the Makefile, so
we must guarantee that we are running with bash (not dash or anything
else).
the checking of the boundaries when blitting was incomplete
for the addblitToBuffer() function when compared with the
blitToBuffer() function. Factored out the redundant checking
procedure into a new function.
Should fix another bug leading to issue #401 and probably
more cases for specifying boundary boxes.
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 file git-rev containing the program's version should be generated at
kpdfview compile time rather than package generation time.
Conflicts:
Makefile
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
Now that #define CRENGINE_DEBUG is handled correctly, all those pesky
messages from crengine are gone and so the performance of crereader
should be much better --- remember that under some circumstances
crengine generates literally THOUSANDS of debug messages per second
(e.g. when complaining about corrupt TOC nodes and there are _plenty_ of
fb2 files out there which have an invalid structure).
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.
think about setting the alignment trap to a mode that includes warn,
that simply kills the performance because of the storm of faults the
syslog gets...
