λgitsite

~ober/jerboa-pdf

Imported from ~/mine/jerboa-pdf

download snapshot

about

# jerboa-pdf

`jerboa-pdf` is the PDF layer for Jerboa applications that must run on small
systems without Python, MuPDF, Poppler, Qt, or OpenCV.

The first target is the SFB SSD reviewer. The design deliberately avoids
server-side PDF rasterization on Android. Instead:

1. Jerboa serves PDF bytes from an allowlisted local source directory.
2. The browser renders pages with vendored `pdf.js`.
3. The browser passes page pixels to the Rust/WASM detector from
   `jerboa-vision`.
4. Jerboa persists reviewed JSON and exports coordinate drafts.

This keeps the eventual Android artifact close to a single static Jerboa binary
plus static web assets and one WASM detector.

## Non-Goals

- No MuPDF dependency.
- No Poppler dependency.
- No Python bridge.
- No server-side OCR in the first version.

## API Shape

Planned Jerboa routes:

- `GET /api/pdf/books`: list allowlisted PDFs.
- `GET /api/pdf/:id`: serve a source PDF with path traversal protection.
- `GET /api/pdf/:id/info`: return page count and metadata when available.

The browser-side renderer should return the same logical page image contract as
the old Python server:

```json
{
  "kind": "pdf",
  "path": "/safe/source.pdf",
  "name": "source.pdf",
  "page": 54,
  "dpi": 144,
  "width": 1224,
  "height": 1584,
  "pixels": "browser ImageData RGBA"
}
```

`pixels` is not sent to Jerboa unless explicitly debugging. The normal path is
browser PDF render -> browser WASM detection -> session JSON -> Jerboa save.

## Static Build Strategy

- Vendor `pdf.js` release assets into the SSD web app.
- Serve those assets from the Jerboa binary or adjacent static asset directory.
- Avoid npm at runtime.
- Keep native Rust PDF metadata parsing optional and small.

If server-side PDF rendering is ever required, it should be a separate optional
feature and must not be part of the Android default.

recent commits