doc/docx/odt - save highlights inside the file (as with pdf)

[kmoll]

Hi, I have been exploring different options to be able to highlight files back and forth both on my ereader running koreader and on my windows pc, but to date none are fully satisfactory:
- annotations made with koreader on epub files are stored in the sdr folder, which, unless I am mistaken, no other app can use (would be great if calibre viewer could!), and there is currently no koreader port for windows. I know I can use an android emulator or the linux version through wsl, but these are cumbersome/heavy/unstable setups for using on a permanent basis.
-highlighting pdfs in koreader is the most intuitive solution, but unfortunately some serious bugs (for which I have opened tickets on github) still exist, which apparently don't seem easy to fix.
In the light of this, I was wondering whether it would be possible to use the doc/docx (or even odt??) standard format to be able to highlight files on both koreader and windows. Since koreader is already capable of opening and annotating these file formats, would it be possible to have an option to save the highlights inside the file - just as we already have with pdf files - in order to be able to view them later on in any office app? Maybe it would be possible to integrate some sort of libreoffice component to run inside koreader or a plugin to be able to edit the files?? I am not a developer, just a user, so maybe this doesn't make any sense at all or is too difficult to implement...
If this isn't possible, could we at least have an updated koreader windows port to complete the app's availability across platforms and have the peace of the mind of knowing that we can access the result of our hard work annotating files in any environment we need?
A big thanks to all who contribute to this most useful project.

[Frenzie]

Probably not likely. PRs welcome, of course.

[pazos]

I moved most of my pdf workflow to the iPad the last year. Until that I treated pdfs like any other format: instead of writting things in the file I kept highlights on the .sdr directory and move both pdf and metadata together. This will work across all the platforms where KO works.

Once you have all the highlights you want to can save them to the file, but IMO there are better programs to write to pdfs.

[kmoll]

Originally Posted by pazos

I moved most of my pdf workflow to the iPad the last year. Until that I treated pdfs like any other format: instead of writting things in the file I kept highlights on the .sdr directory and move both pdf and metadata together. This will work across all the platforms where KO works.

Once you have all the highlights you want to can save them to the file, but IMO there are better programs to write to pdfs.

Yes, that's what I've settled on doing: using the sdr directories, but as I work mainly on windows, the missing link here is the windows port... For example, right now, I cannot get any gui linux app to launch from bash in wsl. Granted, it might be a stupidly easy thing to solve, but it prevents ignorant users like me to use the linux version of KO reliably... Furthermore, it would really make a huge difference if we could create file associations directly in windows, to avoid having to browse folders inside KO looking for files.
As for the android emulators, I tried this option as well, but they are slow to load and eat up a lot of ressources.

Please, pretty please, someone with enough knowledge, give us a windows port !!

[NiLuJe]

Err, the emulator *should* build just fine on Windows (natively, with a mingw TC. Might be easier with a cross toolchain on a Linux host, though?), IIRC?

(Theoretically. It's probably been years since anyone actually tried? Or not?).

[kmoll]

Originally Posted by NiLuJe

Err, the emulator *should* build just fine on Windows (natively, with a mingw TC. Might be easier with a cross toolchain on a Linux host, though?), IIRC?

(Theoretically. It's probably been years since anyone actually tried? Or not?).

I am sorry but I am utterly ignorant regarding coding. Could you elaborate a bit? What is a mingw TC?? Many thanks.

[Doitsu]

Originally Posted by kmoll

Could you elaborate a bit? What is a mingw TC??

MinGW (Minimalist GNU for Windows)
TC = tool chain

[Frenzie]

Originally Posted by NiLuJe

Err, the emulator *should* build just fine on Windows (natively, with a mingw TC. Might be easier with a cross toolchain on a Linux host, though?), IIRC?

(Theoretically. It's probably been years since anyone actually tried? Or not?).

It'll definitely require some effort. See https://github.com/koreader/koreader/issues/4512

Back when @chrox first made it work for Windows what he did was simply to disable every lib that had an issue like that unless it was absolutely vital to basic functionality.

But in any case it should presumably be more of a (boring!) time investment issue than something actually difficult.

[kmoll]

Originally Posted by Frenzie

It'll definitely require some effort. See https://github.com/koreader/koreader/issues/4512

Back when @chrox first made it work for Windows what he did was simply to disable every lib that had an issue like that unless it was absolutely vital to basic functionality.

But in any case it should presumably be more of a (boring!) time investment issue than something actually difficult.

If this is actually easy even for "coding donkeys" like me, I don't mind giving it a try, but I would need some pointers, as I have never cross-compiled anything.
If this route is too time consuming, would something like adding the ability to read from and write to sdr folders in order to highlight files (ideally not just pdfs, but epubs as well) to the calibre reader (or any other reader available for windows for that matter, like mupdf) be less difficult to implement?

[Frenzie]

Presumably not easy in that sense, no. Unless you mean something like "I know Makefiles and CMake but C is a mystery to me."

[Frenzie]

So basically it should be easy enough, but it will require a lot of drudgery along these general lines:

diff --git a/thirdparty/cmake_modules/CMakeCross.cmake b/thirdparty/cmake_modules/CMakeCross.cmake
index f583885..97c4fbb 100644
--- a/thirdparty/cmake_modules/CMakeCross.cmake
+++ b/thirdparty/cmake_modules/CMakeCross.cmake
@@ -33,6 +33,10 @@ if($ENV{CROSS_TC} MATCHES "^arm-.*")
        set(CMAKE_SYSTEM_PROCESSOR arm)
 endif()
 
+if($ENV{WIN32})
+    set(CMAKE_SYSTEM_NAME Windows)
+endif()
+
 # set compiler name
 set(CMAKE_C_COMPILER $ENV{CROSS_TC}-gcc)
 set(CMAKE_CXX_COMPILER $ENV{CROSS_TC}-g++)
diff --git a/thirdparty/libjpeg-turbo/CMakeLists.txt b/thirdparty/libjpeg-turbo/CMakeLists.txt
index 4e11a6b..feb8fbe 100644
--- a/thirdparty/libjpeg-turbo/CMakeLists.txt
+++ b/thirdparty/libjpeg-turbo/CMakeLists.txt
@@ -31,6 +31,10 @@ if(DEFINED ENV{ANDROID})
        list(APPEND CMAKE_ARGS "-DCMAKE_SYSTEM_VERSION=1")
 endif()
 
+if(DEFINED ENV{WIN32})
+    list(APPEND CMAKE_ARGS "-DCMAKE_SYSTEM_NAME=Windows")
+endif()
+
 # And, finally, the actual libjpeg-turbo build options
 list(APPEND CMAKE_ARGS "-DENABLE_STATIC=OFF")
 list(APPEND CMAKE_ARGS "-DENABLE_SHARED=ON")

If you compile natively in Windows it might mostly Just Work™, however.

[Frenzie]

Although there's some other confusing stuff:

$ wine luajit.exe 
0009:err:module:import_dll Library libgcc_s_sjlj-1.dll (which is needed by L"Z:\\home\\frans\\src\\kobo\\koreader\\base\\thirdparty\\luajit\\build\\i686-w64-mingw32\\luajit-prefix\\src\\luajit\\src\\lua51.dll") not found
0009:err:module:import_dll Library lua51.dll (which is needed by L"Z:\\home\\frans\\src\\kobo\\koreader\\base\\thirdparty\\luajit\\build\\i686-w64-mingw32\\luajit-prefix\\src\\luajit\\src\\luajit.exe") not found
0009:err:module:attach_dlls Importing dlls for L"Z:\\home\\frans\\src\\kobo\\koreader\\base\\thirdparty\\luajit\\build\\i686-w64-mingw32\\luajit-prefix\\src\\luajit\\src\\luajit.exe" failed, status c0000135

Because doesn't it say -static-libgcc?
https://github.com/koreader/koreader...defs#L498-L500

Anyway, works fine after copying it over from /usr/lib/gcc/i686-w64-mingw32/8.3-win32/libgcc_s_sjlj-1.dll

[NiLuJe]

@Frenzie: That last one might be a TC issue (i.e., it's actually missing a static libgcc & co) .

My current mingw TC (built via https://github.com/shinchiro/mpv-winbuild-cmake) doesn't even ship a shared libgcc .

[pazos]

With Frenzie's patches both LuaJIT and libjpeg-turbo build fine from a linux host. Actually libjpeg-turbo will fail on https://github.com/koreader/koreader....third#L77-L78, because windows shared libraries are stored on bin/, not on lib/

Djvulibre fails to build.

[Frenzie]

djvulibre can be easily disabled to get to the end quicker if you can't figure out a solution within a minute. That being said, I wouldn't expect it to be problematic.