Crate leaf_raster 

CPU rasterization shared by leaf frontends — the pieces of pixel rendering that are the same whatever the pixels end up painted with.

Each leaf frontend has its own paint path (terminal cells, a gpui scene, Core Text, the DOM), but several of them also need actual pixels: the terminal ships graphics-protocol images for block media and oversized headings, and a headless consumer wants a frame with no toolkit at all. What those uses share lives here, in backend-neutral units:

• resolve_image_path — which image destinations a synchronous local loader handles, and where a relative one anchors. One policy, because two frontends disagreeing about what loads is a bug report.
• load_image / load_svg — file bytes to a decoded image raster, vector pictures included; rasterize_svg for a vector picture whose declared size is meant, such as a typeset formula.
• fit_within — aspect-preserving containment in pixels, so frontends with different display units (cells, points) share the sizing policy and only round differently.
• Rasterizer — shape and rasterize oversized heading text to an RGBA frame, with the editing UI — caret and selection — painted into the pixels. That last part is the reason this is a crate and not a helper: a terminal cannot composite cells over a graphics-protocol image, so the only way a rasterized heading stays editable is for the raster itself to carry the caret. Rasterizer::heading_hit is the reverse mapping, so a click on the raster lands on the glyph it visually hit.

Everything here is CPU-side (cosmic-text, resvg, image): the consumers are terminals reading escape sequences and headless frames, none of which are latency-bound enough to want a GPU pipeline — and the one leaf backend that is (gpui) has its own. The contract is “hand me RGBA”, so a GPU implementation could slot in behind it without callers changing.

Re-exports

pub use image;

Structs

EditingUi

The editing UI to paint into a raster. Offsets are bytes into the spec’s text, on char boundaries; anything out of range or misaligned is dropped rather than panicking, since a stale frontend offset is not worth refusing to draw the heading over.

HeadingSpec

Everything a heading’s geometry depends on: the text, the level (which picks the type scale), and the pixel box the raster fills. Deliberately free of colors and caret state so the same spec drives rasterization, hit-testing, and the fits check — a click must be answered by exactly the layout that was drawn.

Rasterizer

The shaping and glyph-raster state — a font database, a glyph cache, and the per-heading layout cache — shared across every raster so fonts load once per session and a heading shapes once per edit, not once per frame.

Functions

fit_within

The pixel box an image fits into: as wide as max_w allows but never upscaled past the source’s own pixels, and as tall as that width makes it, capped at max_h (shrinking the width back to keep the aspect ratio).

load_image

Decode an image file to a DynamicImage, or None on any failure (missing, unreadable, or a format no decoder covers). SVG is rasterized with resvg (load_svg); every raster format goes through the image codec crate.

load_svg

Rasterize an SVG’s bytes to a DynamicImage, or None if it won’t parse.

rasterize_svg

Rasterize an SVG’s bytes at scale times its own declared size — the vector path for a picture whose size is meant: a typeset formula (leaf-math) writes its root in pixels at the font size it was set at, and drawing it at anything else puts the glyphs at the wrong size. Where load_svg picks a resolution for a picture of unknown intent, this takes the picture’s word for it. None if the document won’t parse.

resolve_image_path

Resolve an image destination to a readable local path, or None when it’s not one a synchronous loader handles: a remote URL, a data: URI, a protocol-relative //host/…, or a relative path with no document directory to anchor it. The one policy every frontend that decodes local files eagerly shares — the rest stay a placeholder.