Plugin Fragility?

[diehl]

Hi @RyotaUshio,

Could you expand a bit more on the following warning from the plugin main page? What should new adopters of PDF++ be mindful of? I'm not sure what would follow if the plugin breaks. Would that be a temporary inconvenience or could it be a permanent break that would result in all our links to PDF content no longer functioning?

This plugin relies on many private APIs of Obsidian, so there is a relatively high risk that this plugin may break when Obsidian is updated. For this reason, I hope this plugin's functionalities will be natively supported by Obsidian itself so that we won't need this plugin anymore.

I'm wondering about how to utilize the PDF++ functionality in a way that is robust over the coming years. Like you, I hope what you've built will be natively available in Obsidian in the not too distant future!

[RyotaUshio]

Obsidian's public API does not allow plugin developers to directly interact with their PDF viewer.
For this reason, I had to investigate and rely on Obsidian's internals that is not exposed as a part of the public API.
However, Obsidian's authors may rewrite such non-public code in the near future (that's why they choose not to include that code in the public API), in which case this plugin's codebase might be affected.

Although I will try to release the necessary updates as soon as possible in that case, the users might be forced to stay in the older version of Obsidian until the newer version of PDF++ is available.
Also, you need to keep in mind there is no guarantee that I can keep maintaining this project throughout the next 10 years or so.
All community plugins (not just PDF++) have the risk of being abandoned.

could it be a permanent break that would result in all our links to PDF content no longer functioning?

All of your links will be able to take you to the correct destination even after this plugin dies because PDF++ does not introduce any original link syntax except for &color=<COLOR> (which is completely optional).
This color syntax only affects the color in which the target text selection is highlighted, and it has nothing to do with the process of determining a link's destination.

(This is in contrast to other PDF-related plugins such as Annotator and MarkMind, which leave a bunch of JSON code blocks that are non-interpretable without the plugins.)

Note

Update: From version 0.36.0, PDF++ has introduced a new link syntax &rect=... for rectangular selections, which is again optional. https://ryotaushio.github.io/obsidian-pdf-plus/embedding-rectangular-selections.html

If PDF++ stops working, the &rect=... links will be able to take you to the correct page but not the exact in-page location of the rectangles.

However, backlink highlighting will no longer work if PDF++ dies, which means

• you can go to a specific location in a specific PDF page from your markdown files by clicking links like [[file.pdf#page=1&selection=1,2,3,4]],
• but you will not be able to see which part of the text is backlinked in the PDF viewer at a glance.

But you will be still able to use the Obsidian's built-in backlinks view to navigate to the markdown file that the link lives in.

The good news is that you don't necessarily have to use the backlink highlighting feature to annotate PDF files.
PDF++ also supports adding highlight annotations directly into your PDF files themselves (see #49 (comment) for example).
Highlights added in this way will be visible even outside of Obsidian and even after PDF++ dies.

You are also free to use external apps like Adobe Acrobat and so on to add highlights. PDF++'s features, e.g. copying a formatted link to a highlight and hovering over a highlight to show a popover preview of backlinks, can work along with such annotations as well.

Lastly, I'm planning to add a command that exports backlink highlights into actual highlights embedded directly into PDF files
so that you can see the highlights after this plugin goes away.

[diehl]

@RyotaUshio Thank you for this very detailed reply! This definitely helps me feel way more comfortable in adopting PDF++ as I don't see any significant downside in terms of longevity of the resulting annotation and linking.

Interestingly enough, I just noticed Obsidian's native functionality for "Copy as quote" and "Copy link to selection" and when clicking on the link, it does highlight the selection in the PDF at present. So even if PDF++ were to cease to work, this functionality looks like it would persist because it is native to Obsidian currently. So, in other words, we'd lose workflow enhancements that PDF++ offers but the basic linking functionality would remain.

[RyotaUshio]

we'd lose workflow enhancements that PDF++ offers but the basic linking functionality would remain.

Exactly! I'm glad I could help you:)

[diehl]

@RyotaUshio You rocked it. :-) Grateful for your work!

[NomarCub]

@RyotaUshio You might consider using Obsidian Extended Typings for internal types. This would mean others can easily use the work you put in to exploring the internal API and the community could help find mistakes as well as maintain the APIs.