When the Agent Gets Eyes
OfficeCLI's rendering system addresses the part of document work that semantic data cannot settle: whether a reader can actually see and use the result. The focus here is the path from a live Word document, Excel workbook, or PowerPoint deck to HTML, SVG, or PNG, and then from that visual evidence back to a targeted repair. Readers should come away able to distinguish a structural read from a visual audit, choose an observation surface, and recognize when a preview is a useful signal rather than a universal guarantee of Office compatibility.
A document model can describe a layout without revealing its consequences
A structured read can tell an agent that a slide contains a title shape, a chart, and a paragraph of text. It can return their paths, attributes, and content. It cannot by itself answer whether the title overlaps the chart, whether the chart's labels are clipped, or whether the contrast between text and background is sufficient for a human reader. The same gap appears in other formats. A Word document can contain the right paragraphs while a page break strands a heading from its table. An Excel sheet can contain every cell and formula while a column is too narrow to show the value that matters.
This is why view html, view screenshot, and watch are more than export commands in OfficeCLI. They turn layout into evidence that an agent can inspect. Text and outline views answer “what is in the document?” A rendered page or slide helps answer “what will the reader experience?” Both questions are necessary, because a visual problem often needs a semantic repair: the screenshot shows an overlap, but the document path identifies the shape whose position or size should change.
The static path begins with the already-parsed format handler. OfficeCLI's rendering input is not just a file name handed to an unrelated converter; it is the current in-memory document model together with format-neutral access to nodes and queries. That matters in a resident session. If an agent has just changed a shape or a cell and has not yet flushed the file, a renderer connected to the live handler can observe the current session state rather than reopening an older disk copy.
A renderer registry keeps this boundary extensible. A renderer declares which formats and output kinds it supports, whether it can participate in the watch interaction contract, and a priority. The registry selects the highest-priority available renderer whose capabilities cover the request. The default renderers adapt OfficeCLI's built-in HTML and SVG paths; another renderer can be added without making the command layer enumerate every implementation. In system terms, the document handler owns the parsed artifact, while the renderer owns the conversion of that state into an observation surface.
The default HTML path is deliberately practical. It can produce a standalone HTML snapshot for a browser, and it embeds assets or interaction metadata needed by the preview.