It is up to the book to manage its attribute.
Also remove the `absolutePath` (and `indexAbsolutePath`). The `Book::path` is always stored
absolute.
The fact that the path can be stored absolute or relative in the
`library.xml` is not relevant for the book.
The previous API suffer different problems:
- It was difficult to handle articles redirecting to other article.
- It was not possible to get few information (title) without getting
the whole content.
The new API introduce the new class `Entry` that act as a proxy to an
article in the zim file.
Methods of `Reader` now return an `Entry` and the user has to call
`Entry`'s methods to get useful information.
No redirection is made explicitly.
If an entry is not found, an exception is raised instead of returning
an invalid `Entry`.
The common pattern to get the content of an entry become :
```
std::string content;
try {
auto entry = reader.getEntryFromPath(path);
entry = entry.getFinalEntry();
content = entry.getContent();
} catch (NoEntry& e) {
...
}
```
Older methods are keep (with the same behavior) but are marked as
deprecated.
The library's books are created in the metadata in the opds.
As the opds stream is by definition a distant "library", there is no
zim to read to complete missing information.
This can lead to incomplete `library.xml`.
The downloader is using libaria2.
For now, only one download can be run a the time.
A download will start only if (and as soon as) no download is running.
`libzim` will not search in zim file without embedded fulltext index.
If we don't want to mess up with result index, we must not store "wrong"
reader.
Fix#111
Even if we use the add_reader method to search into embedded full text
index, we need to specify the global `contentHumanReadableId` as it will
be used to generate "page links".
This is a small quick and dirty API to do geo query.
It is not possible with this API to do a query search and a geo search.
It's either one or the other.
We should think about a better global API to do searching and provide
both of them in the same time (libzim does it).
ctpp2c is used to pre-compile the template resource.
However, on OSX, ctpp2c seems to be difficult to compile, as we don't need
ctpp2 at all on OSX/iOS, lets just stop to force the use of ctpp2c.
We always need a humanReadableName associated with a content to search in.
Do not separate the two values (human readable name and zim) in two
different functions.
This way, we avoid miss-use of the Searcher who could lead to segfault.
Add a `title` write argument to `getContent*` methods.
This argument is filled with the title of the content get.
Also update the JNI accordingly.
Related to kiwix/kiwix-android#214
This was not necessary when searching in only one zim file as `url` was
enough to get the article (and so the content).
If we want to search in several zim in the same time, we need a way to get
the content directly.
If a embedded fulltext database is present, suggestion will search in it :
- insensitive case search.
- search for terms in the middle of the title.
- xapian will try to complete the last word of the query (as if a '*'
were added at the end)
Matthieu Gautier
Chris Li
kelson42