[Enhancement] viewer command-line parameter to go to ePub TOC entry/bookmark

Bug #1656573 reported by Gary on 2017-01-14
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
calibre
Undecided
Unassigned

Bug Description

There are many times when I would like to open an ePub in the viewer to a specific entry in the TOC. In my case, I am thinking of building an external searchable index for TOC entries so that I can search non-fiction works by topic and then would like to navigate to that topic. Perhaps the --open-at parameter could support that or page number, or a new parameter could be added.

Additionally, if the book is already open, from what I remember, the --open-at parameter seems to reparse and reload the book rather than check that the book is already open and merely go to a page.

Fixed in branch master. The fix will be in the next release. calibre is usually released every Friday.

 status fixreleased

Changed in calibre:
status: New → Fix Released
Gary (empedocles) wrote :

Fantastic. Thank you! Related to the use case I had mentioned above, is getting the path to the currently open book. It would certainly help tremendously. If it can be done, should I open up a new issue?

It can't be done. The viewer is an independent program not part of the
calibre GUI. As such viewer instances have no knowledge of easch other.
You can open multiple copies of the same book in multiple viewer
instances.

Gary (empedocles) wrote :

I am only concerned about the currently open book in the viewer. From that, my app can present and filter TOC entries for the open book, and then navigate more quickly than with the built-in UI. I understand there can be multiple instances, but is there anyway to, or possible future way, to determine the instance in focus? Or if the viewer is set to only allow one book at a time, can a command-line parameter be added so the open book can be determined?

Kovid Goyal (kovid) wrote :

Not really, for that to happen the viewer then has to gain the ability
to communicate with other instances, which is a lot of work for
relatively little gain. Patches are welcome.

Gary (empedocles) wrote :

Ok, I'll see if I can figure it out someday.

Gary (empedocles) wrote :

Perhaps if the viewer kept track of recently opened files, for a future menu item to open recent items, then I could at least find that in some file or place and use that as a hack to find the currently open book.

Preferences ==> Miscellaneous ==> open calibre config directory ==>
viewer.json

Look for the "viewer_open_history" key.

(Checking my history, it seems calibre sometimes stores relative paths,
presumably when invoking the viewer via the CLI using relative paths.
This seems rather incorrect.)

aphemos (aphemos) wrote :

Is it possible to add opening an EPUB to a specific navPoint ID? Bookmarks are sometimes named the same or similarly and in those cases, it seems calibre picks the first one.

Kovid Goyal (kovid) wrote :

navpoints are epub 2 specific, the viewer works with many formats, so this doesn't fit with the viewer. Are there really books with identially named Table of Contents entries? Is this some kind of hierarchical ToC with identical sub-levels?

aphemos (aphemos) wrote :

It has been a while since I've encountered it and I've been meaning to mention it for a while. Yes, larger works with long TOCs could have identically named TOC entries; indeed often they are hierarchical such as if some technical, exercise/learning, etc. work might name chapter sections similarly. Perhaps using target, then parsing would be different from EPUB 2/3, but the syntax to invoke it would be the same. I admit it is a specific use case; I index TOC entries in a separate app and then through search am able to open EPUBs to a specific location. I'm not sure how many really use this feature.

Kovid Goyal (kovid) wrote :

EPUB 3 dont neccessarily have any ids associated with nav points, they
use HTML markup for the ToC, which can anf often does have missing ids.
And that is only EPUB, the viewer supports many other formats as well.

aphemos (aphemos) wrote :

By target I had meant the link anchor, which for EPUB3 as you is in the nav doc and for EPUB2 the ncx. e.g., "file002.xhtml#optional_anchor". That'd eliminate any ambiguity. Indeed this is only for EPUB. I'm not sure how used it'd be, or even if the parameter you added is often used. But I'd find indispensable for calling the viewer from elsewhere.

Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.

 status fixreleased

aphemos (aphemos) wrote :

thank you so very much. btw, hope work on the new viewer hasn't been abandoned and will continue. seems like maybe plans have changed.

No it hasn't been abandoned. In fact it is mostly done. I just need to
write code to migrate old settings, implement the command line
interface and ToC viewer.

aphemos (aphemos) wrote :

Very glad to hear. I have every once in a while looked at commits and didn't remember seeing anything about the viewer.

Question: I was trying the --open-at=toc-href. Is it supposed to work as such? When I try it using the href from the NCX or nav, the viewer merely hangs.

/Applications/calibre.app/Contents/MacOS/ebook-viewer --continue --open-at=toc-href:"OEBPS/Text/file.xhtml" "full path to file"

aphemos (aphemos) wrote :

works great. issues I had before might have been from some outdated href. thank you!

As for the new viewer, perhaps some issue can be opened on GitHub to track progress, remaining issues, etc.? Looking forward to it very much.

Kovid Goyal (kovid) wrote :

Use the webengine branch to try out the new viewer. But note that this
involves running calibre from source on a Linux machine as it requires
Qt WebEngine which is not bundled with current calibre builds.

It uses the same codebase as the calibre in-browser viewer, so you can
instead try that out.

aphemos (aphemos) wrote :

Great. I may try to install qt through homebrew and see if I can get it working on macOS.

My interest in this command is that I made a desktop search plugin that can index all ebooks on my computer, and then from searching toc titles & sections, open any EPUB and PDF to that section.

https://imgur.com/qLyVyQM

Hoping the new viewer can open EPUBs more quickly and load toc sections from the command-line w/o reloading the EPUB.

Originally in Python, have recently ported most of it to Go with new features (best to use that), and have ported the parts where speed is more apparent to Rust. If you have some interest, you can certainly write something like it for Linux. search Github gennaios repos if you're curious.

btw, when using this command, if are errors such as the href not existing (using MuPDF to extract and it makes the destination as full path from zip root "OEBPS/…"), the viewer hangs w/o any error messages.

Kovid Goyal (kovid) wrote :

The new viewer maintains an cache of parsed books, so if you open something with it a second time, it will open faster, though with EPUB I doubt the difference is particularly noticeable.

As for the hanging when invalid location problem is concenrned, it is now fixed.

aphemos (aphemos) wrote :

Thank you for the fix.

As for the new viewer, if there's a cache I might hope that the opening time would be as minimal as possible. Perhaps just reading the OPF, NCX or nav, and then the file of the last opened chapter. Maybe some of that can be threaded so the page gets displayed as quickly as possible. Dunno. There was also loading an EPUB TOC or href of an already opened file in the viewer. Hoping that can be as quick as selecting a TOC entry from the UI.

aphemos (aphemos) wrote :

Thank you for the recent add to 4.x. In trying it, the viewer hangs sometimes. I'm not sure what are all the cases, but for example if I run the same command twice in succession, "… --open-at=toc:"Preface" …" on the same file, the second time generally hangs at please wait.

Kovid Goyal (kovid) wrote :

I need some way to reproduce it, running it multiple times witht he same
toc entry does not hang for me.

aphemos (aphemos) wrote :

I have the setting to use only one instance. If that is not set, then another instance opens and that works fine of course. As I'm externally searching TOC entries and then calling the viewer to change to that TOC entry or open a different EPUB as such, I use one instance. If that's not the issue, is there anyway to debug? Unsure if "--continue" is needed. Full command I'm using is:

/Applications/calibre.app/Contents/MacOS/ebook-viewer --open-at=toc:"Preface" [path to file]

In testing, if I first launch the viewer as such from the command-line, and then in another shell rerun the same command, some logging:


QCoreTextFontDatabase: Failed to resolve family name for PostScript name "PlantagenetCherokee"

[56220:775:1118/183538.823463:ERROR:permission_manager_qt.cpp(82)] Not implemented reached in ProfileAdapter::PermissionType QtWebEngineCore::toQt(content::PermissionType)Unsupported permission type: 13
[56220:775:1118/183538.823578:ERROR:permission_manager_qt.cpp(82)] Not implemented reached in ProfileAdapter::PermissionType QtWebEngineCore::toQt(content::PermissionType)Unsupported permission type: 13
[56220:775:1118/183538.824916:ERROR:permission_manager_qt.cpp(82)] Not implemented reached in ProfileAdapter::PermissionType QtWebEngineCore::toQt(content::PermissionType)Unsupported permission type: 13
[56220:775:1118/183538.825012:ERROR:permission_manager_qt.cpp(82)] Not implemented reached in ProfileAdapter::PermissionType QtWebEngineCore::toQt(content::PermissionType)Unsupported permission type: 13

aphemos (aphemos) wrote :

btw, maybe open to href isn't yet implemented? Thank you so very much for continuing to main this. I do not know how many people use this, but for me, I have all EPUBs on my computer indexed by TOC entries, and I'm able to search all of them and open EPUBs to sections with this. Doing research, anything, example, looking up amla (amalaki) I can see all works that cover it. You can imagine incredibly useful.

Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.

 status fixreleased

aphemos (aphemos) wrote :

Thank you.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers