Currently only tested on Ubuntu-touch emulator with framework
ubuntu-sdk-14.10 for armhf.
The ubuntu-touch port is binary compatible with the Kobo port
major changes in this PR are:
1. rename the emulator device to sdl device since both the emulator
and the ubuntu-touch target use libsdl to handle input/output.
2. ubuntu-touch app has no write access to the installation dir so
all write-outs should be in a seperate dir definded in `datastorage`.
The new container-based format doesn't do sudo anymore, so there are some extensive changes.
It does, however, allow cache.
I also took the opportunity to switch to a newer busted. The root element for that now needs to be a table.
On kindle, kobo and pocketbook the data directory is the current
running directory but on Android the app is installed in system
defined location and users may have no access to that location.
The same circumstances should be true for the upcoming Koreader for
Ubuntu touch, so the data directory (in which tessdata, dictionaries,
global settings, persistant defaults and probably history data are
stored) could be stored in another place.
since users may have mantained their own extensions.cfg file
The extensions.cfg file is still in the release package and users
could manually copy the `system` directory to the USB root if they
want Koreader to handle all their documents.
so that we can easily find which module needs unit test
In order to run 'make coverage' `luacov` need to be installed
with 'sudo luarocks install luacov'.
aternatively the resource file(pot file) in Transifex is updated
with `make pot` and the translated files(po files) is updated with
`make po`. `make pot po` will be handled automatically on the nightly
build machine.
The "My Clipping" file that storing highlights and notes for Kindle
native readers could also be parsed and exported. The parser is
implemented in `evernote.koplugin/clip.lua`.
Parsed highlights and notes in one book will be packed and rendered
into html node with a slt2 template `note.tpl` that complies with
evernote markup language(ENML).
Finally the evernote client will create or update note entries and
push them to Evernote cloud.
* 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
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
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 file git-rev containing the program's version should be generated at
kpdfview compile time rather than package generation time.
Conflicts:
Makefile
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...
MG 2012.03 pulling GLIBC_2.15 symbols from libm (because -ffast-math asks
for it).
I didn't see this on my own TC because it's using a much older glibc version (2.9).
instead of HOST (and allow it to be set from the env), use $(MAKE)
instead of make to allow using the jobserver properly, and remove the
dash from commands where we do care about the return code (or inhibit
errors the usual way: rm -f instead of -rm)
Conflicts:
Makefile
Enaling link time optimizations for kpdfview binary and crengine library
causes another slight performance increase --- almost negligible (1-2ms
per page) but still noticeable by precise measurements.
Thanks to NiLuJe who pointed out that our generic -march=armv6 can be
replaced (for K2/K3/DX/DXG) with a more specific optimization:
-march=armv6j -mtune=arm1136jf-s -mfpu=vfp. This I have now done and
also passed ARM_CFLAGS value to CXXFLAGS which is then passed to
crengine build. Tested, works fine. The performance improvement is
negligible (a few ms per page, but seems to be consistently better, i.e.
not just plus/minus fluctuations).
Thanks to NiLuJe who pointed out that we are building mupdf in debug
mode. Switching to "release" build reduced the size of the kpdfview
binary and did not cause any performance degradation (but no noticeable
improvement either --- the page handling times seem to be exactly the
same, i.e. fluctuating a couple of ms in both directions).
1. Remove unused "-lsdtc++" from the compilation stage as no linking is
done then.
2. Add our standard CFLAGS to the compilation of cre.cpp which brings in
-O3 -march=armv6 which enables optimizations.
It seemed strange that we compile a cpp file with gcc (as opposed to
g++), but I left it as is for now.
Instead of calling lfs.mkdir() to create "./history" and "./screenshots"
at runtime it is easier to create them at package build time.
I hesitated whether to add "./clipboard" to this list but decided
against it as we can perhaps change current directory and then
all the code manipulating clipboard would break, so I left it as is.
Conflicts:
filechooser.lua
screen.lua
settings.lua
1. Don't build xmltools in the emulator
2. Remove duplicate --disable-desktopfiles
3. Don't build LFS support. The largest DjVu file I have ever published
was a highres facsimile edition of the London Walton Polyglot (1657)
which was a "mere" 1GB in size and I don't think anyone produced
anything bigger. Besides, storing DjVu files >2GB in size (even if
they existed, which I doubt) on a Kindle with only 3GB total storage
space is _exceedingly_ unlikely.
