rm2pdf

README

rm2pdf

version 0.1.6 : 22 February 2023

Convert reMarkable tablet file 'bundles' to layered PDFs, with optional per-layer colours for selected pens.

Update

rm2pdf does not support the new reMarkable v3 software format files, which produces .rm version 6 files.

This version 0.1.6 should detect the attempted processing of the new format files.

Support for the the new content metadata file format for reMarkable tablets using version 3 software is included for issue 11, however the underlying issue is the new version 6 rm files.

The status of the community work on version 6 files is set out here.

Recent releases:

• 0.1.5 : fix for missing metadata in bundles and older rmapi zip files
• 0.1.4 : add support for rmapi zip files
• 0.1.3 : add embedded A4 template (needs go 1.16+)
• 0.1.2 : support custom pen configuration, see config_example.yaml
• 0.1.1 : allow input paths with suffixes (such as .content)
• 0.1.0 : added support for landscape mode files
• 0.0.3 : support for pages inserted while annotating a PDF

Examples

./rm2pdf -h

Usage:
  rm2pdf InputPath OutputFile

rm2pdf version 0.1.6

...

rm2pdf [-v] [-c red] [-c green] [-c ...]  InputPath OutputFile

Application Options:
  -v, --verbose     show verbose output
                    this presently does not do much
  -s, --settings=   path to customised pen settings file
  -t, --template=   path to a single page A4 template to use when no UUID.pdf exists
                    useful for processing sketches without a backing PDF
  -c, --colours=    colour by layer
                    use several -c flags in series to select different colours
                    e.g. -c red -c blue -c green for layers 1, 2 and 3.
                    See golang.org/x/image/colornames for the colours that can be used

Help Options:
  -h, --help        Show this help message

Arguments:
  InputPath:        input path and uuid, optionally ending in '.pdf'
  OutputFile:       output pdf file to write to

Invocation examples for annotated PDFs using the test files in testfiles:

rm2pdf testfiles/cc8313bb-5fab-4ab5-af39-46e6d4160df3.pdf output.pdf

rm2pdf -c orange -c olivegreen \
       testfiles/cc8313bb-5fab-4ab5-af39-46e6d4160df3.pdf output2.pdf

Invocation examples for reMarkable notebooks using the test files in testfiles and the A4 template in templates.

rm2pdf -c blue -c red -t templates/A4.pdf \
       testfiles/d34df12d-e72b-4939-a791-5b34b3a810e7 output4.pdf

The embedded template is used where one is not provided, so the above command is the same as

rm2pdf -c blue -c red \
       testfiles/d34df12d-e72b-4939-a791-5b34b3a810e7 output4.pdf

Details

rm2pdf requires "bundles" of files created on the reMarkable tablet, including the associated .metadata and .content files, together with the .rm binary and -metadata.json files associated with each page of reMarkable marks.

rm2pdf aims to create PDFs from both PDFs that are annotated on the reMarkable and reMarkable notebooks using these files. The latter uses an empty template PDF as the background. PDF templates can be made from the reMarkable png templates (in /usr/share/remarkable/templates) but should fit the standard 222.6264mm x 297.0000mm reMarkable output PDF size, or be A4.

Output PDFs are layered with the background PDF forming a "Background" layer and subsequent layers using the layer names created on the tablet. The layers can be turned on and off using tools provided by PDF readers such as Evince.

The pen widths and opacities provided by default are estimates. Colours, base width and opacity are set for each pen are set in rmpdf/stroke.go. Those pens with ColourOverride true will have their colour overridden by the command-line options or pen configuration yaml file. Note that at present the .rm file pressure and tilt information are not presently used.

Some PDF files, notably those created by Microsoft Word, cannot be imported reliably, causing the programme to panic. Reprocessing problem PDFs with the pdftk tool seems to fix the problem.

Note that rm2pdf has only been tested on a reMarkable v1 tablet.

Background

The project includes rmparse/rmparse.go, a remarkable tablet Go port of reMarkable tablet "lines" or ".rm" file parser, with binary decoding hints drawn from rm2svg https://github.com/reHackable/maxio/blob/master/tools/rM2svg which in turn refers to https://github.com/lschwetlick/maxio/tree/master/tools.

The project makes extensive use of the go PDF fpdf library and the contrib module gofpdi. The latter is used for including pages from existing PDF documents.

If your pdf causes fpdf to fail, resave the pdf using the pdftk programme.

Build and test

Developed with go 1.18 on 64bit Linux.

Test: go test -v ./...

Build : go build; this should produce an executable called rm2pdf.

License

This project is licensed under the MIT Licence.

Documentation

Overview

rm2pdf

MIT Licensed RCL January 2020

Introduction

This programme attempts to create annotated A4 PDF files from reMarkable tablet file groups (RM bundles), including .rm files recording marks.

Normally these files will be in a local directory, such as an xochitl directory synchronised to a tablet over sshfs.

The programme takes as input either:

* The path to the PDF file which has had annotations made to it

* The path to the RM bundle with uuid, such as <path>/<uuid> with no filename extension, together with a PDF template to use for the background (a blank A4 template is provided in templates/A4.pdf).

The resulting PDF is layered with the background and .rm file layers each in a separated PDF layer. The .rm file marks are stroked using the fpdf PDF library, although .rm tilt and pressure characteristics are not represented in the PDF output.

PDF files from sources such as Microsoft Word do not always work well. It can help to rewrite them using the pdftk tool, e.g. by doing

pdftk word.pdf cat output word.pdf.pdftk \
&& mv word.pdf word.pdf.bkp \
&& mv word.pdf.pdftk word.pdf

Custom colours for some pens can be specified using the -c or --colours switch, which overrides the default pen selection. A second -c switch sets the colours on the second layer, and so on.

Example of processing an rm bundle without a pdf:

rm2pdf -t templates/A4.pdf \
testfiles/d34df12d-e72b-4939-a791-5b34b3a810e7 \
/tmp/output.pdf

Example of processing an rm bundle with a pdf, and per-layer colours:

rm2pdf -c chartreuse -c firebrick \
testfiles/cc8313bb-5fab-4ab5-af39-46e6d4160df3.pdf \
/tmp/output.pdf

General options:

rm2pdf [-v] [-c red] [-c green] [-c ...] [-t template] InputPath OutputFile

Warning: the OutputFile will be overwritten if it exists.

ReMarkable .rm file parser

The parser is a go port of reMarkable tablet "lines" or ".rm" file parser, with binary decoding hints drawn from rm2svg https://github.com/reHackable/maxio/blob/master/tools/rM2svg which in turn refers to https://github.com/lschwetlick/maxio/tree/master/tools.

Python struct format codes referred to in the parser, such as "<{}sI" are from rm2svg.

RMParser provides a python-like iterator based on bufio.Scan, which iterates over the referenced reMarkable .rm file returning a data structure consisting of each path with its associated layer and path segments.

Usage example:

rm, err := rmparse.RMParse("filename.rm")
// start parsing; note that pdflayers are dealt with sequentially
for rm.Parse() {
	path := rm.Path.Path
	penName := StrokeMap[int(path.Pen)]
	for s := 1; s <= int(path.NumSegments); s++ {
		segment := rm.Path.Segments[s-1]
		// do something with path and/or segment
	}
}

PDF paths, strokes and colours

Pen selections are hard-coded in stroke.go with widths, opacities and colours. The StrokeSetting interface "Width" is used to scale strokes based on nothing more than what seems to be about right.

Resolving the page sizes and reMarkable output resolution was based on the reMarkable png templates and viewing the reMarkable app's output x and y widths. These dimensions are noted in pdf.go in PDF_WIDTH_IN_MM and PDF_HEIGHT_IN_MM. Conversion from mm to points (MM_TO_RMPOINTS) and from points to the resolution of the reMarkable tablet (PTS_2_RMPTS) is also set in pdf.go. The theoretical conversion factor is slightly altered based on the output from various tests, including those in the testfiles directory.

To view the testfiles after processing use or alter the paths used in the tests.