The FUSE detection is false positive under Gitlab's pipeline,
so just use the hidden `--appimage-extract-and-run` option to
automatically and always "extract & run" the appimage tool.
Instead of trying to detect if running under Docker, use a simpler
wildcard check to detect if FUSE support is available. This as the
advantage of supporting Docker, rootless Docker, and Podman.
Includes:
- Russian hyphenation: allow hyphens after Russian "не" prefix
- EPUB: add "identifiers" to doc props
- EPUB: avoid crash when '@font-face' in <head><style>
- FB2: fix block images sizing and centering
- lvrend: fix positioning of bottom border on empty block elements
Also includes:
- cre: add 'identifiers' to doc props
- build and ci: various tweaks
Device:getDefaultRoute parses /proc/net/route and converts the hex
addresses to textual IP addresses, but in `isOnline` we don't care what
address the gateway actually has, we only care about whether we have a
default route into the Internet.
This provides a simpler alternative that does the equivalent of
"ip route get 203.0.113.1 || ip route get 2001:db8::1" (note that it
does support IPv6-only connectivity as opposed to
Device:getDefaultRoute) and returns true if we have a route.
Inspired by https://github.com/pavel-odintsov/get_default_outgoing_ip_linux
Doing the `isOnline` check (`socket.dns.toip("dns.msftncsi.com")`)
without having internet connectivity (`!isConnected`) results in the
`isOnline` check never succeeding again even if connectivity is later
acquired. This is most likely caused by /etc/resolv.conf only being
parsed once - https://sourceware.org/bugzilla/show_bug.cgi?id=984, an
issue that was fixed in glibc 2.26 (PocketBook firmware U740.6.8.2461
has glibc 2.23).
This fix works around the problem by checking if we have a default route
first before even attempting to check `isOnline`. If we don't, then
`isOnline` is (almost) guaranteed to fail anyway.
We could alternatively check `isConnected` instead, but that only checks
wireless connectivity on many platforms, and we could have internet
access via USBNet instead. Checking for the default route via any
interface should work reliably for both wireless and USBNet
connectivity.
Another alternative fix is to add a fallback nameserver to
/etc/resolv.conf like we do for the Kobo platform [1]. Unfortunately,
this fix would not work in the following (rather common) scenario:
1. PocketBook boots, connects to WiFi
2. KOReader starts, /etc/resolv.conf looks all right, no fallback needed
3. PocketBook goes to sleep, disconnects from WiFi, clears resolv.conf
4. PocketBook wakes up, stays disconnected
5. KOReader user does a Wikipedia lookup, networking freezes
[1]: https://github.com/koreader/koreader/pull/6424/files#diff-be863601c59a2d6607af6b04b3be2392ec4494df6d25dae48250fae57b737f61R216-R224
Fixes: https://github.com/koreader/koreader/issues/10183
Related: https://github.com/koreader/koreader/issues/6421
Added in <https://github.com/koreader/koreader/pull/8722> and unproblematic for the past two years, but Weblate has now decided to complain about it to the extent of disabling translations:
> Error message
String contains control character: 'If some book titles, dictionary entries and such are not displayed well but shown as \ufffe\ufffe or ��, it may be necessary to download the required fonts for those languages. They can then be enabled as additional UI fallback fonts.\nFonts for many languages can be downloaded at:\n\nhttps://fonts.google.com/noto\n\nOnly fonts named "Noto Sans xyz" or "Noto Sans xyz UI" (regular, not bold nor italic, not Serif) will be available in this menu. However, bold fonts will be used if their corresponding regular fonts exist.'
Includes:
- In-page footnotes: avoid with '-cr-hint: noteref-ignore'
- In-page footnotes: ensure they don't cross "flows"
- Tables: fix rendering when negative text-indent
- FB2 cover drawing: ensure _invertImages flag
- EPUB: fallback to look for a cover in the first fragment
- TextLang: Russian: add typography rules
Also update to libunibreak 6.1.
A typo snuck in #11492, which should've read `not type(article.mimetype) == "string" or type(article.mimetype) == "string" and not article.mimetype:find("^text/html")`. But in most cases the behavior would've been identically broken because of the same underlying issue: Wallabag mimetype is actually HTTP content-type.
Fixes#11528.
Also introduces a new setting associated with the behavior in case people have different preferences.
