You are converting a single page from a technical document (blog post, book, or article) into Markdown. This page is one piece of a larger document that will be reassembled and fed to another LLM, so your output must preserve ALL information a downstream reader would need — including information that is conveyed visually rather than textually. ## Output format Return ONLY the Markdown for this page. No preamble, no explanation, no code fences wrapping the whole response, no "Here is the markdown:". Start directly with the page content. ## Text — preserve faithfully - Transcribe all body text, headings, captions, footnotes, and sidebars verbatim. - Use Markdown headings (`##`, `###`, `####`) that match the visual hierarchy on the page. Reserve `#` (H1) for the overall document title only — for in-page section headings, start at `##`. If you cannot tell whether something is an H2 or H3, prefer the deeper level. - Preserve inline code, bold, italic, and links. Render inline code with backticks and code blocks with triple backticks plus the language tag when identifiable (```python, ```bash, ```json, etc.). If the language is unclear, use a plain ``` fence. - Preserve mathematical notation as LaTeX: `$...$` for inline, `$$...$$` for display. - Preserve lists, blockquotes, and tables using standard Markdown. - If the page begins or ends mid-sentence, mid-paragraph, mid-code-block, or mid-list, transcribe what is visible without inventing completion. Do NOT add ellipses or "[continued]" markers — the reassembly stage handles cross-page joining. ### Links - If the destination URL of a link is visible in the page content, preserve it as `[text](url)`. - If the link text is visually styled as a link (underlined, colored) but the destination URL is NOT visible on the page, preserve the link text with the placeholder `[text](#)` rather than guessing or fabricating a URL. Never invent URLs. ## Visual elements — describe so the downstream LLM understands them For every non-text visual element on the page, emit a description block in this exact format, placed inline at the position the element appears: ``` [FIGURE: ] Caption: <2–6 sentences describing what the figure shows AND what it demonstrates to the reader in the context of the surrounding text. Include concrete details: labels, axis names, arrow directions, code shown in screenshots, relationships between components, what is being compared, what conclusion the visual is meant to support.> [/FIGURE] ``` The block is delimited by `[FIGURE: ...]` on the opening line and `[/FIGURE]` on its own closing line. Always include both — the closing tag is required so reassembly can find figure boundaries. The opening line `[FIGURE: ...]` is YOUR one-line summary. The optional `Caption:` line inside the block is the page's literal caption verbatim. These are different things and both may appear. ### Description quality — describe AND interpret A figure description has two jobs: 1. **Describe what is visible** — labels, colors, positions, arrows, shapes. 2. **State what the figure demonstrates in context** — what claim or process the figure is supporting in the surrounding prose. The second job is what makes the description useful to a downstream LLM that cannot see the image. Always include it. Look at the prose immediately before and after the figure to determine what point the figure is making, and state that point explicitly in the description. **Commit, don't hedge.** If the surrounding text makes the figure's purpose clear, state that purpose definitively. Avoid "likely," "possibly," "appears to represent" when the context is unambiguous. Hedging is only appropriate when the figure is genuinely ambiguous even with surrounding context. ### Spatial layout — required for any figure with multiple panels When a figure contains a grid, side-by-side panels, or any multi-panel layout (e.g., a 2×2 grid of screenshots, a "server on top, clients below" diagram, before/after comparisons, multi-column architecture diagrams), you MUST state the spatial position of each panel before describing its contents. Use position labels like: - top-left, top-right, bottom-left, bottom-right (for 2×2 grids) - top, middle, bottom (for vertical stacks) - left, center, right (for horizontal rows) - "Server (top), Client 1 (bottom-left), Client 2 (bottom-right)" Do NOT just list the panels in reading order without their positions — a downstream reader cannot reconstruct the layout from a flat list. If the figure is a single panel with no internal layout, no position labels are needed. ### 3D scenes and renderings — special care required 3D renderings are easy to misread. Before describing, identify: - **What is in the foreground vs. background** — large translucent shapes are often foreground elements (signal coverage volumes, force fields, bounding regions), not background scenery. - **What is the subject of the scene** — usually the smallest, most detailed objects (figurines, landmarks, devices) are the subjects; large enclosing shapes are usually conceptual (volumes, fields, regions). - **What spatial relationship is being demonstrated** — occlusion, containment, distance, line-of-sight, intersection. Cross-check your interpretation against the surrounding prose. If the text talks about "signal coverage" and you see a large translucent dome, the dome is almost certainly the signal coverage volume, not background scenery. ### Annotations, callouts, and arrows — state the target When an annotation, callout text, or arrow points to a specific element, state which element it points to. For example: - WRONG: "An annotation reads 'Undo normally just reverses the edit'." - RIGHT: "An annotation reading 'Undo normally just reverses the edit' points to the yellow circle inside the Server panel." If an arrow connects two elements, state both endpoints and the direction. If an annotation appears to apply to a panel as a whole rather than a specific element, say so explicitly ("an annotation applies to the Client 2 panel as a whole"). ### What to apply this to - Diagrams (architecture, flow, sequence, state, ER, network topology, etc.): name every labeled node/box, describe the arrows and what they represent, and state what process or structure the diagram is illustrating. - Charts and plots: state the chart type, axis labels and units, the series shown, the trend or comparison being made, and any annotations or highlighted regions. Include approximate values for notable points. - Screenshots of UIs, terminals, IDEs, or web pages: transcribe the visible text content (menu items, button labels, terminal output, code in editors) and describe what the screenshot is demonstrating. - Code shown as an image rather than as selectable text: transcribe it inside a fenced code block with the appropriate language tag, then optionally add a [FIGURE: ...] block if there are visual annotations (arrows, highlights, callouts) that add meaning beyond the code itself. - Tables rendered as images: convert to Markdown tables when feasible; if the structure is too complex, use a [FIGURE: ...] block describing rows, columns, and the comparison being made. - Photographs, illustrations, and decorative imagery: describe briefly only if they carry information relevant to the technical content. Skip pure decoration (e.g., publisher logos, stock photos used as chapter openers with no informational content). - Equations rendered as images: transcribe to LaTeX inside `$$...$$`. ### Caption vs. in-figure label — disambiguation rule These are different things and must be handled differently: - **Caption**: text positioned BELOW or ABOVE the figure, separate from the figure's bounding region, typically explanatory ("Figure 3.2: ...", "A schematic of the encoder."). Place the caption on the `Caption:` line inside the FIGURE block. - **In-figure label**: text positioned INSIDE the figure's bounding region, labeling a specific element or showing a value (axis labels, node names, parameter readouts like "semi major axis = 14667 mi"). Do NOT put these on the `Caption:` line. Mention them in the descriptive paragraph as labels on specific elements ("a yellow value below the diagram reads 'semi major axis = 14667 mi'"). If the text is positioned ambiguously (e.g., directly underneath but visually part of the figure's design), prefer treating it as an in-figure label and describing it within the prose paragraph. ### Caption deduplication — important If a caption is visible on the page (e.g., "Figure 3.2: ...", "HTML DOM", "A screenshot of our internal prototype"), it must appear in EXACTLY ONE place in your output: as the `Caption:` line inside the [FIGURE] block. Do NOT ALSO emit the caption as standalone text before or after the [FIGURE] block. Do NOT also emit it as a bold label, a paragraph, or a heading. The [FIGURE] block is the only place that caption text should appear in your output. If you are about to write the caption text outside a [FIGURE] block, stop — it belongs inside the block. ## What NOT to do - Do NOT summarize or paraphrase body text. Transcribe it. - Do NOT skip visual elements because they "look decorative" if they have labels, arrows, or annotations — those signal information content. - Do NOT invent content for portions of the page that are unclear or unreadable. If a region is illegible, emit: `[UNREADABLE: ]` - Do NOT include page numbers, running headers, running footers, URLs of the page itself, timestamps from the print view, or publisher watermarks. These are noise once pages are reassembled. - Do NOT wrap your entire response in a code fence. - Do NOT emit a caption both inside and outside a [FIGURE] block. - Do NOT fabricate URLs for links whose destinations aren't visible. - Do NOT hedge ("likely," "possibly") when the surrounding context makes the figure's meaning clear. ## Edge cases - Multi-column layouts: read in natural reading order (left column fully, then right column), unless the layout clearly indicates otherwise (e.g., a figure spans both columns). - Sidebars and callout boxes: render as blockquotes (`>`) and prefix the first line with the box's label if present, e.g., > **Note:** ... > **Warning:** ... > **Tip:** ... - If the entire page is a single full-bleed figure with no body text, output only the [FIGURE: ...] [/FIGURE] block. - If the page is blank or contains only a chapter title, output just the heading (or nothing, if truly blank). - If a page contains a figure that continues from the previous page or spills onto the next page, describe what is visible on THIS page only. Do not speculate about portions not visible.