This is probably a feature for the far future. I would still like to document it.

PDF documents imported to the remarkable desktop app are stored (cached?) in $HOME\AppData\Roaming\remarkable\desktop\ (that is on Windows; I assume this is at similar locations on other platforms).

The app seems to generate a UUID at import time. The following files are stored for each imported file:

• <uuid>.pdf (the original document without annotations)
• <uuid>.pagedata (here it only says Blank, no clue what it means)
• <uuid>.content (JSON formated meta data)
• <uuid>.metadata (some more JSON formated meta data)
• <uuid>.lines (annotations overlay for the document as drawn on the device).

As you might already have noticed, remarkables export functionality is lacking (and buggy). rM2svg could be used to create a better export experience by overlaying the original document with the converted *.lines.

I understand that this might currently be out of scope for this project. So please consider this as inspiration and shared knowledge base instead of a demand.

Is it possible to construct .line from svg? (or other format) with individual lines and background?

Hello,
I've been using the rM2svg script to create (with rsvg-convert) the SVG images to overlay them on the original PDF document that was annotated using the tablet. Doing so leads to the annotations (i.e. the pen strokes etc.) shifted slightly to the left when overlayed on the original PDF document.
I wonder whether anybody else has seen this behaviour?
I have fixed it by adding +40 (by trial and error) to all x values found but this seems rather kludgy.
In any case, thanks for this tool!

Im not sure how best to approach this, but the rm2svg script here is quite outdated. I just finished fixing the version I use to work with the current file format and new pens (see here). Obviously not 100% perfect reproduction of the pen strokes but Im quite happy with it and it may be useful. It has diverged quite a bit from the original though so I thought I would ask if you would be interested in merging my changes back and whether I should make a PR.

We could reduce the dependencies of the package by moving to PyPDF2 (https://github.com/mstamy2/PyPDF2). In this way we could have a fully pythonic implementation of the tools that is easier to make corss-platform.

If you think this could be interesting, I am going to investigate it as soon as I have some time

Having recently acquired a rM I stumbled upon this repository and while going through the motions of understanding the scripts the are available here and elsewhere I was wondering if the name maxio could either be explained in the top-level Readme, or if it would make sense to rename the repository to something more resembling the content (i.e., rM_tools)?

Also, would it make sense to adopt a common naming scheme for the scripts? I like the scheme adopted in https://github.com/reHackable/scripts , i.e., starting each command with re or rM (preferred) : reExportFile, re2SVG.

Hi!

I spent some time working on rMAPI, a Go app to access the reMarkable remotely using the cloud API. It allows you to copy files and directories from/to it without plugining the device.

I see maxio uses ssh/scp to connect to the device. Would it be useful to create a PR to add the option of using rMAPI to access the device remotely?

Thank you!

Hi,

I think this is a great script and I applaud your reverse engineering the format.

I am going to dump a couple of details that I found into your issues. They might turn out to be interesting for this project. If not, please ignore them and accept my apologies.

Stroke color of the highlighter pen is yellow when exporting drawings and annotated documents through the remarkable desktop app. This is also documented in the getting started guide (p 3, PDF)

It might be a nice enhancement to also select a translucent yellow for highlighter strokes.

Cheers

The latest update to the reMarkable operating system has introduced single page lines files (NN.rm) and these lines files have a different format than the old .lines files used. Is there a plan to update the rM2svg script? More to the point, does anybody have a pointer to a description of the contents of these .rm files?

Thank you.

The rM2svg works well for conversion to SVG (and renders as individual strokes which is better than the reMarkable native SVG export).

I noticed that it could use support for more pen types.

For instance, I hacked up support for mechanical pencil ( # 17) using the existing pen # 7:

(line 171 -3):

            elif pen == 7 or pen == 17: # Pencil-Sharp
                width = 16 * width - 27
                opacity = 0.9

Not sure of all the pen mappings but would be good to update the script...

https://github.com/reHackable/maxio/blob/master/tools/rM2svg

I have most of my notebooks inside folders on the remarkable. The tool does not find a notebook, if it is inside a folder. If not inside a folder the tools works fine. Still hope remarkable makes the built-in export work with custom layouts

Hello,
I've just used the rM to annotate a landscape PDF (size 453.54 x 255.12 pts), and exportNotebook does not handle the case at all.
I've tried to hack it into supporting it but for some reason I can't get the translate to work.

However, I've stumbled upon https://github.com/tavinus/pdfScale/ which seems to have everything we need (almost, I could not get the automatic translate to work).

I'll see if I manage to do something, but don't count on it :)

The eraser shouldn't be rendered as white, but it needs to rendered(because if it's not that causes the lines that were "erased" to appear) Even reMarkable's official tool has this problem, and I'm really starting to get bugged over it. I don't know how you would code it but perhaps you could modify the code that if any line is covered by eraser, it skips/removes that line. I don't know how you would go about doing it, but this is the greatest problem I have with my rM since the beginning.

EDIT: My bad I have mistakenly assumed that the new format is out already - I'll reopen this once it actually is :D

Alright, so it is expected that the lines format will change soon. Below I have documented the current quality of the SVG conversion. With the files that I've got at hand, some pen types are somewhat broken. First off - is that just for me or does it affect everybody?
Anyways since the format is about to change I'd like to 'warn' everybody and maybe get some peoples interest in figuring out the new format once it goes live.

Results using the current conversion logic

Using the conversion logic based on the old file format this is the result (left is the true content, right is it parsed by the old format):

Two got their segments logic a tad weird and two are broken completely.

Lets figure out the new format!

As I am currently developing an application that makes use of parsing the lines format and this repository also contains a script that uses it to generate SVG files I'd like to make this a place for sharing information about the new lines format. Any help on figuring out the new format is greatly appreciated!

Any plans on making a SVG2rM conversion script? Now that rM has copy/paste, we can finally have drawing primitives, vector graphics, etc. in a notebook to copy/paste from. Or does it exist already?

using the mechanical pencil in a notebook on the remarkable tool results in the error message 'Unknown pen: 13' during an export attempt. While the export still works all lines are very jaggy and not accurate

Seems like the .lines headers have been updated to version 5, and they have introduced more details regarding the stroke information, which begs an update rM2svg.
for now, I figured out at least the fields that get stroke_color and pen are either different or they have new values.

Just tested the exportNotebook function. At this point the drawing layer is shifted with respect to the background (see attached figures).

Note that this does not happen with the rM2svg version developed here:

https://github.com/phil777/maxio/tree/master/tools

I see that this approach requires far more (or heavy?) dependencies (poppler, cairo). So I propose to add both versions of rM2svg to the repository and let the user switch (perhaps based on a dependency check?). Would you be willing to merge something like that?

Work-progress-work can be found here:

https://github.com/m-weigand/maxio/tree/svgCairo

Test output using rM2svg_cairo:

cairo.pdf

Test output using rM2svg in this repository:

convert.pdf