clickable links

[benneti]

would it be possible to support url support on export?

[bordaigorl]

If you mean PDF annotations it is possible but I had no time to play with it.
RCU does it by transforming the strokes while keeping the PDF as in the original.
For Remy I went the other way (also to mirror what I think the tablet does) and I use the notebook pages as the base and I transform the PDF to fit it. The problem is that the PDF library does not scale the annotations when applying the transformations, so if I were to keep them they would be in random places, disconnected from the elements they were originally attached to.
This line

remy/remy/gui/export.py

Line 118 in 2f270ad

writer.removeLinks() # until we implement transformations on annotations

is the place where I strip the annotations.
Instead of that one would need to apply the appropriate transformation to the coordinates in the annotations contained in page["/Annots"], specifically the /Rect argument needs to be transformed for each (certain subtypes may need more work).
The details are in sec 8.4 of the PDF Reference.
If you want to take a stab at it I'm more than happy to assist you!

[benneti]

Yes, that is what I meant.
If you don't mind I would probably first implement an option to make the export like rcu (keeping the original pdf) and after this try to also make the import with annotations and transformations possible.
But I think it will need some time as the next few weeks are already pretty full (and for now I'll simply use rcu if I need this feature)!

[bordaigorl]

Hi @benneti I'm adding some info on this issue.
As you might have noticed, in devel I added the ability to use PyMuPDF for rendering PDFs in the preview.
This is good because python-poppler-qt5 is a major pain to install, while PyMuPDF comes with prebuilt wheels and is multiplatform (and very efficient!).
Now the opportunity is to get rid of PyPDF2 as well and replace it with PyMuPDF's functionality.
PyMuPDF looks promising as it seems to be preserving annotations well.
The flow would be: start from original PDF, add composited pages at the end and then remove the original pages.
I have to check whether this will work or something more complex is needed.
Let me know if you feel like giving it a go (I won't have time to play with this for a while).

[benneti]

actually I now use https://github.com/naturale0/rmrl to generate the pdfs (and mainly rmfakecloud + rmapi to get the files to generate the pdf). So my motivation is a bit low right now, maybe it would even be more useful to simply use rmrl (which is intended as a python library anyway) instead.

[bordaigorl]

If you don't mind me asking, what are the main reasons why you are not using Remy's export?
Would there be a killer feature that would make you prefer Remy?

[benneti]

Of course I don't mind. It's less about what Remy could do more about that if I use the remarkable cloud (or the selfhosted alternative) Remy does not work, and also I want a cli interface to automate some stuff I do periodically. Rmapi + rmrl does exactly that and I use Remy more like a fallback when I am in a situation without internet.

What do you think about using rmrl for the export I think it would save a lot of duplicated effort?

[bordaigorl]

if I use the remarkable cloud (or the selfhosted alternative) Remy does not work

meaning it does not exploit the cloud or does it downright break?

I want a cli interface

Completely fair, I wanted to add a CLI but I never really needed it in my workflow

What do you think about using rmrl for the export I think it would save a lot of duplicated effort?

I considered it. Thing is, I'd need duplication anyway because of Remy's preview, which cannot reuse the rmrl code.
Instead, in Remy I can use the same code to render to screen or to render to PDF.
Also I had some customization of rendering planned that never fully materialized, which would have needed a rewrite of rmrl anyway.

[benneti]

Yeah I meant as in exploit the cloud.

Before I used rsync to a server to not use remarkable s cloud but by now rmfakecloud works perfectly for my use case.

Not using rmrl is completely fair, too. For the configurability I think they would be open for Pars and from a quick glance it seems some stuff can already configured with dicts. Anyway this does not help with the preview in any case.