Why We Treat HTML as a CAD Format: The Design Principles Behind Ginexys PDF Processor

TLDR

Most PDF extraction tools treat output generation as a one-way destination, dumping raw HTML and leaving structural fixes to the user. We designed GINEXYS PDF Processor around the principle that extracted HTML is a spatial CAD document in progress. By combining CSS Grid layout containers with inline DOM manipulation and Monaco code editing, users can restructure extracted documents directly in the browser without breaking semantic export targets.

Design Approach	Layout Strategy	Flow Integrity	Context Switching
External Fix (Traditional)	Open output in Word / IDE	Unknown	High (Switch tools post-extract)
Absolute Canvas Positioning	position: absolute canvas	Broken (Elements fall out of document flow)	None (But export fails)
DOM-as-CAD Architecture	CSS Grid + DOM insertBefore	100% Preserved (Browser reflows natively)	Zero (In-place editing)

---

Perfect extraction is an algorithmic impossibility

When extracting complex PDFs, algorithms rarely produce 100% perfect layouts. Multi-column tables get split across pages, sub-headers misclassify as body text, and callout boxes disrupt vertical text order.

Traditional tools export this imperfect HTML and force developers into a tedious workflow: download the output, open an external editor, manually inspect markup, and fix layout errors in a separate environment.

---

Absolute coordinates break clean document exports

When attempting to build layout editors for web documents, tools often default to absolute positioning (position: absolute), allowing users to drag elements anywhere on screen.

However, absolutely positioned elements fall completely out of document flow:

• Paragraphs no longer push content down when expanded.
• Responsive column containers collapse.
• Converting the layout to Markdown, XML, or Word produces broken positioning wrappers rather than clean document hierarchy.

---

Browser DOM flows act as native spatial coordinates

Browsers already treat HTML as a spatial CAD model:

           +-----------------------------------------+
           |      HTML DOM Spatial CAD Model         |
           |  CSS Grid Containers (.pdf-zone)        |
           |  - grid-template-columns: repeat(N, 1fr)|
           +-----------------------------------------+
                      /                   \
                     v                     v
          Column 1 (.pdf-col)        Column 2 (.pdf-col)
                  |                          |
                  v                          v
          Region Box (.pdf-region)   Region Box (.pdf-region)
                  |
         +--------+--------------------------+
         |                                   |
         v                                   v
     Edit Mode                         Selection Mode
(contentEditable text)             (HTML5 Drag & Drop)

The two-mode architecture

We exposed this native spatial model directly to the user on a single DOM surface:

• Edit Mode: Standard inline text editing powered by contentEditable.
• Selection Mode: Injects drag handles into zones and regions, enabling drag-and-drop node reordering via native insertBefore operations.
• Edit Code escape hatch: Right-clicking any element opens a Monaco editor modal with raw outerHTML. Applying changes replaces the DOM node in place and propagates changes across all export pipelines (applyHtmlEverywhere).

Rule of thumb: Treat HTML as a structured spatial document rather than a flat string dump. Use native CSS Grid and DOM node mutation methods to provide visual layout editing while preserving semantic export pipelines.