1 v0.03

1.1 Annotation creation, editing and deletion

Plan: Annotation creation, editing, and deletion (highlight & sticky note)

Functionality:

• Create and persist annotations
• Edit annotations (and persist)
• Delete annotations (and persist)
• Update the pdfinfo CLI tool and examples to demonstrate the write-back workflow

The work done in this version will only cover highlighting and text (sticky note) annotations.

Notes:

• PDFium supported types: circle, freetext, highlight, ink, link, popup, square, squiggly, stamp, strikeout, text, underline.
• Saving back to disk requires fpdf_save.h; the round-trip must be tested against files produced by different authoring tools (Adobe Acrobat, macOS Preview, etc.).

Constraints:

• Object-level modification (moving path objects within an annotation) is only supported for ink and stamp annotation types.
• Almost the entire annotation API is marked // Experimental API. — keep FFI bindings behind a Dart abstraction layer so signature changes are localised.
• Callers performing spatial hit-testing against annotation geometry must apply the FPDF_PageToDevice() / FPDF_DeviceToPage() coordinate conversion (PDF origin is bottom-left).

2 v0.04

2.1 Layout-aware text reordering

Planned.

Implemented in ../plans/plan_layout_aware_reordering.md.

Prerequisite: v0.02 text extraction must be complete.

PDFium’s native text extraction order follows the PDF content stream, which does not always match visual reading order. This milestone adds heuristic reordering of extracted characters into correct visual reading order for multi-column documents and RTL (Arabic/Hebrew) text.

The approach: cluster characters into lines by y-coordinate, cluster lines into columns by x-coordinate, detect dominant bidi direction per column, then sort and concatenate in reading order.

Known hard cases that must be covered in tests:

• Multi-column documents with footnotes spanning the full page width
• Tables (cell boundaries don’t map to column boundaries)
• Rotated text (headers, watermarks) where y-sort assumptions break
• Mixed LTR/RTL content within a single column

Web Worker dependency: the per-character FPDFText_GetCharBox() loop is performance-sensitive; full remediation requires moving WASM execution to a Web Worker. This is in scope for this plan.

3 Roadmap

This directory is used to track roadmap items. A roadmap is prepared for a specific release version.

Individual, non-trivial roadmap items are described using a plan (see ../plans).

An example roadmap file is provided below. This example is for v0.01 of an application so would be stored as 0_01.md. Items of note in the example:

• When a roadmap item has been completed, its title is tagged with ✅ Complete
  • (not shown) When all roadmap items have been completed, the roadmap is marked complete (# v0.01 ✅ Complete)
• If a plan is used to undertake a roadmap item, it should be linked against the roadmap item (as seen in the “Collections Schema” section).
• The YAML header is a Pandoc markdown feature.

---
title: 0.01 Roadmap
subtitle: Will it work?
toc-title: "Contents"
...

# v0.01

## CLI tidy up ✅ Complete

- Remove the `put` command

## Collection Schemas ✅ Complete

> Implemented in
> [`../plans/completed/plan_cli_schemas.md`](../plans/completed/plan_cli_schemas.md).

## Range-predicate index scans

Secondary indexes currently accelerate **equality predicates** only
(`Field('x').equals(v)`). Range filters (`isGreaterThan`, `isLessThan`,
`isBetween`, `startsWith`) are always evaluated in-memory after a full namespace
scan.

When the version roadmap has been completely implemented, make sure the status is updated to “✅ Complete” and move the plan into the completed directory.