full directory conversion functionality

[chemag]

Right now rmc will take a single .rm file, and convert it to pdf (or svg, or whatever). It works well (I stopped using anything else).

IMO it has 2x limitations:

• (1) Documents on the other hand are composed of several .rm pages, and some metadata (e.g. the path and name of the actual document). rmc forces the user to convert one page at a time, and then unite the files.
• (2) On top of that, a remarkable device typically keeps lots of documents organized. This forces the user to manually organize the output files.

My main workflow right now consists of syncing all the files from a remarkable device, and converting them to pdf. It works in 2 stages:

(1) copy the raw files and metadata

$ rsync -avut --progress --rsync-path=/opt/bin/rsync remarkable:/home/root/.local/share/remarkable/xochitl/ ~/raw/

(2) convert all the raw files into PDF documents, organized using the same path structure than in the device.

$ rmc-dir.py convert-all --root ~/raw/ --outdir ~/pdf -dd

My rmc-dir.py script goes through all the remarkable files in ~/raw/, and renders them into a PDF in the ~/pdf/ directory. It keeps the names and paths of the original files:. For example, the document that in the device is personal/foo/bar will end up as ~/pdf/personal/foo/bar.pdf.

The script does a couple of metadata things:

• analyzes the per-document metadata, getting the pages in each doc (ordered).
• checks metadata and output timestamps to decide whether to re-render a file.

And then it calls rmc.

Now, my current script (rmc-dir.py) would be better integrated as part of the rmc command. Note that it accepts input and output dirs, instead of files, so using -o for the output (and nothing for the input) may not be the right approach.

A couple of questions for you:

• (1) Are you interested in the functionality for this workflow?
• (2) Are you interested in this script? I'd be happy sending it as a separate script, and then you decide how to integrate it.

Thanks

[Azeirah]

Hi! This is quite cool! I've been maintaining remarks, a library that does this and more!

I'm imagining the specialization levels as follows

1. rmscene works at the parsing level of the .rm file. It's a function .rm binary => scene tree
2. rmc works at the level of the scene tree. It's a function scene tree => human readable page (ie, svg, pdf, ...)
3. remarks works at the level of the full document. It's a function .rmn => human readable document (ie, svg, pdf, md, ...)

A .rmn file is simply a remarkable notebook folder archive with the .rmn extension. You can find more details in the RCU manual by Davis Remmel

Feel free to just create a repo with the script, or to just drop it in this thread. The metadata parsing could be quite valuable!

[chemag]

Hi,

I wonder whether it would be easier to operate with a single repo that does everything. In particular, I could see the tools in rmc being deployed as test tools in rmscene.

Other than that, thanks a lot for the RCU manual link!

The mentioned script:
ricklupton/rmc@13aedd3

[Azeirah]

Yeah, I do think it might be nice to have a single repository. I've been investing a lot of time in learning Nix and it is genuinely amazing for creating extremely sophisticated and smooth developer tooling for these kinds of libraries.

I'm wondering if you have an opinion on that @ricklupton? I'm noticing that having to jump between different libraries all the time can get kind of annoying, and I also believe the people working on these libraries are the same few people

@chemag Also, I'd love to have you in the Scrybble discord! It's a community for people in the Obsidian/ReMarkable PKM space. @Seb-sti1, myself and @ChenghaoMou are in the Discord too.

[Azeirah]

Oh I forgot to add the invite

https://discord.gg/mSS48d7b

[ricklupton]

Thanks for sharing. I agree this is useful.

About where it goes, this does match with what I thought:

1. rmscene works at the parsing level of the .rm file. It's a function `.rm binary => scene tree`

2. rmc works at the level of the scene tree. It's a function `scene tree => human readable page` (ie, svg, pdf, ...)

3. remarks works at the level of the full document. It's a function `.rmn => human readable document` (ie, svg, pdf, md, ...)

It can be annoying switching between repositories but I think it's useful partly because one python package per repository is nice and simple (for github actions, releases etc) and I think it's good to keep these separate levels separate -- rmscene is much more general and can be used by people who don't care about Obsidian etc. So it makes sense to me to keep rmscene separate as the low-level file format code, as long as that doesn't cause too many problems.

I'd be happy to have your script integrated into rmc, or you could use/improve remarks if that already does what you need?