diff --git a/CLAUDE.md b/CLAUDE.md index 3241c90..f9c0c88 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -51,69 +51,58 @@ add a font file, register it in `fonts.json` — the CMake step generates the em Docs (Sphinx + Doxygen) live in `doc/source/`; build with `cd doc && make html`. -## Two parallel architectures — know which one you're in +## Architecture: the loom pipeline -The codebase currently contains **two layout/rendering pipelines** side by side. This is -intentional, active migration work (see branch names like -`find-the-best-pattern-for-layout-engine`) — do not assume one is dead code without checking -recent commits/CMakeLists first. +There is a single layout/render pipeline **loom**, built around a pipeline-of-visitors over a plain node tree: -### 1. Legacy pipeline (`docraft/{include,src}/docraft/{model,layout,renderer,backend,services}`) - -``` -Craft XML → CraftLanguageParser (pugixml) → DocraftNode AST - → Template Engine (${var} substitution, expansion) - → Layout Engine: Chain-of-Responsibility handlers (layout/handler/*) compute x/y/width/height + pagination - → Renderer: Visitor pattern walks the AST, dispatching to Painters (renderer/painter/*) - → Painters call capability-provider Backend interfaces (backend/docraft_*_rendering_backend.h) - → DocraftHaruBackend (backend/pdf/*) implements those interfaces on libharu ``` - -- `DocraftDocument` (include/docraft/docraft_document.h) is the entry point; orchestrates - `configure_settings → template_document → layout → render → save_to_file`. -- `DocraftDocumentContext` holds shared render state; note it's a known Service-Locator-style - god object (20+ getters) — treat as legacy, avoid extending its surface. -- Backend interfaces are split by capability domain (Text/Line/Shape/Image/Page/Output/Font/Metadata - rendering backends), not one aggregated facade — this split is deliberate (a prior aggregated - facade was removed for SRP reasons). -- Node types (Text, Table, List, Image, Shape, Layout, Paragraph, ...) each have: a parser - registration, a layout handler, and a paint/render path. Adding a node type touches all three - plus tests. -- Known architectural pain points are catalogued in `.local/ARCHITETTURA_CRITICITA.md` (circular - deps between PageHaruBackend/DocraftHaruBackend, scattered ownership of cursor/color state, no - fallback strategy for unsupported backend capabilities, etc.) — useful context before touching - `backend/` or `docraft_document_context`. - -### 2. New "loom" pipeline (`docraft/{include,src}/docraft/loom/`) - -A from-scratch redesign of the layout/render path, built around a **pipeline-of-visitors** over a -plain node tree rather than chain-of-responsibility handlers + a document-context god object: - -``` -DocraftLoomNode tree (nodes/: Text, Paragraph, Rectangle, VStack, HStack, ...) +Craft XML (pugixml) + → docraft::craft front-end (craft/, craft/parser/): tokenizes tags and validates attributes into + typed "parsed element" data (ParsedElement, Parsed*Data, shared line-style/shape-style parsing) + → docraft::craft::DocraftLoomCraftLanguageParser: top-level driver for // + /
//