It would be great if Sumatra could automatically read Moon Reader’s generated files and update position when their files are on the same folder (synced by Google Drive or Dropbox).
The file is named “Book’s name.epub.po” and it has just some markers like this:
I’m here guessing the first number in bold is the chapter, and the later percentage is the position within that chapter.
Is it feasable? Thanks in advance for the attention!
Home / [Feature Request] Syncing with MoonReader generated marker
Potentially possible but unlikely
epub.po holds last position read
epub.an other holds annotations, highlights, & probably bookmarks.
Since po is simply the POsition marker for just the last read position it should be easy to reverse engineer However it may be a problem to ensure/assure on remote sync drives, which notoriously cause problems even when a single user is using different moon reader apps.
" To fix unknown issues which may cause sync failed , please try
1. uninstall the reader, restart your device, then reinstall the latest version from Google Play.
2. delete cache folder on cloud “/Apps/Books/.Moon+”.
3. (optional) register a new Dropbox/WebDav account, use this account to login to try again."
I dont think I am giving much away that SumatraPDF is likly to introduce an alternative system and then it would be simpler to produce a converter app but again thats unlikly to be a high priority as there are enough issues in making that work syncing between multiple SumatraPDF installs
I didn’t understand much of the tech problem described, but I guess it has to do with the .po file not syncing properly because of possible difficulties in Moon Reader itself (or maybe it is on the cloud or in between?) Sure got it would be more difficult than I had imagined.
Anyway, still using old methods then (remembering )! Thanks for the answer!
the epub.po contains :
< timestamp > * < chapter > @ < volume > # < number-of-char-over-the-top-of-the-screen > : < percentage-of-the-whole-book >
the number of char is after converting HTML to richtext, so it doesn’t include html tags, but it does include newlines not in the file.
It is the number of character that aren’t shown on screen because they’re already-read, aka you scrolled over them, so values are not incremental, but jumping around (in one of my tests, scrolling 3 lines gave the value 225.)
Interesting info, but currently SumatraPDF has no similar mechanism, since it is primarily page orientated.
Favorites only store the nominated pages and bkm support for epub has not been progressed, whilst locations in fixed page PDF format is still under development but even that is currently struggling at working destinations more granular than page level.