* upstream project removed CMakeLists.txt in crengine dir now, so I
added our own in kpvcrlib/CMakeLists.txt
* fix segfault bug in lvimg.cpp by removing JCONFIG_INCLUDED definition
Use DroidSansFallback.ttf rather than DroidSansFallbackFull.ttf because
that is what is used for rendering cjk glyphs by mupdf (see mupdf.patch).
Conflicts:
font.lua
1. The file defaults.lua needs to be mentioned in LUA_FILES in order to
be packaged by "make customupdate".
2. The problem with the linker not finding libluajit-5.1.so.2 can be
fixed without specifying the shared library in the list of objects (and
static libraries), simply by making a symbolic link. No need to copy a
duplicate.
Conflicts:
Makefile
We should explicitly link with the libjpeg.a from mupdf/thirdparty and not with the
shared libjpeg.so that may happen to be installed on the system.
Conflicts:
Makefile
Probably we should use fomit-frame-pointer explicitly even though
fomit-frame-pointer is included by default with -O2 and -O3 just like
the Linux kernel guys doing. I found append -O3 directly to `CFLAGES`
will do the trick. So I removed the KOPT_CFLAGS variable.
In some compilation platform if finite-math-only option is turned
on, math functions like exp and sqrt will be dynamically linked to
finite versions which cannot be located in Kindle's GLIBC. In my
toolchain the symbol __exp_finite cannot be found in GLIBC_2.4 so
gcc just use __exp_finite in GLIBC_2.15, which will cause a run time
error in Kindle saying "version GLIBC_2.15 not found"
Instead of linking against the location inside the original build tree
we should link against the copy in a single place. This makes the build
code cleaner and more compact even now and will do even more so when we
build more libraries as shared (which is what I am going to attempt
next).
This commit adds Alt-S command which invokes the external utility "extr"
passing it the full pathname of the open PDF file and the current page
number. The utility extracts all attachments on this page (if there are
any) and saves them in the same directory as the PDF file. The file
names given to attachments are decoded from within the PDF file itself,
i.e. they are the same as the original file names of the files embedded
in the PDF.
Conflicts:
pdfreader.lua
