KiteCanvas
High-level drawing target. Implement this to add a new render backend; use PdfPage.renderTo to drive an existing one.
The PageRenderer walks the content stream, maintains the graphics-state stack, accumulates paths, and finally calls one of these device methods with a complete, ready-to-paint primitive. Backends therefore don't need to track the CTM, the current path, or text positioning. They receive only the final geometry plus the transform to apply.
Concrete implementations shipped:
ComposeCanvas(:kitepdf-compose-viewer): paints into a ComposeDrawScope.SkiaCanvas(:kitepdf-skia-renderer): paints into a SkiaCanvas.AwtCanvas/AndroidNativeCanvas/CoreGraphicsCanvas/Canvas2dCanvas(:kitepdf-native-renderer): host-platform raster backends.
Inheritors
Properties
True when this canvas needs resolved glyph outlines (TextGlyph.outline), i.e. it actually paints (a render backend). Extraction canvases that only read text + advances override this to false, letting the driver skip the cost of resolving glyph outlines.
Functions
Open a transparency group (ISO 32000-1 §11.4). Subsequent paints accumulate into an offscreen layer; endTransparencyGroup composites the layer back onto the parent with blendMode + alpha.
Paint one text run, already laid out into glyphs by the document handler. Format-neutral: no PDF (or other) font object crosses the seam, so every handler (PDF, EPUB, and others) drives text the same way.
Renders the T-40 shading types through plain KiteCanvas.fillPath calls, so every backend supports them identically with zero bespoke code: