rust-office-art 0.1.5

Shared Office picture, shape, connector and saved SmartArt rendering for Rust and WebAssembly
Documentation

rust-office-art

Shared Office drawing rendering for native Rust and WebAssembly. The renderer consumes DrawingML picture XML and a resolved image source, and produces SVG with separate paint bounds and layout dimensions.

render_picture accepts a PictureContext that resolves DrawingML colors against the caller's theme. RenderedPicture.svg contains the SVG text; paint_bounds describes any pixels outside the original layout box. Keep the original image bytes and drawing XML for export.

Implemented picture appearance includes signed cropping, stretch fill rectangles, raster tiling with embedded DPI, rotation, flips, line borders, alpha and color operations, shadows, glow, soft edges, and reflections. Geometry supports all 187 DrawingML presets and bounded custom guide formulas, elliptical arcs, multiple paths, and quadratic/cubic commands. The preset definitions are distributed with Apache POI license, notice, revision and hash metadata.

Tile sizing uses embedded resolution with a 72 DPI fallback when resolution is missing. The tested blipFill/@dpi and a14:useLocalDpi settings do not override intrinsic tile size, matching native Word 16.106.1 and Excel 16.107.3 on macOS. Intrinsic tile dimensions currently support PNG, JPEG/JFIF, GIF and BMP; TIFF/WebP normalization does not establish their intrinsic tile resolution. A 12-case Word control confirms physical tile dimensions, while a 48-case Excel replay retains residual differences in high-resolution tile sampling and alignment. These checks do not establish all-version or all-platform parity.

Normal dot, dash and dash-dot outlines use distinct segment spacing from their system variants. Pictures and shapes share the preset mapping and use round joins when no join is specified. Rectangular picture borders follow an outward-offset centerline; nonrectangular picture borders still use an outside-stroke approximation.

render_shape(properties_xml, style_xml, width, height, context) renders shape and connector geometry, supported fills and outlines, arrow markers, local rotation/flips, and shared effects. Text layout remains the caller's responsibility. PictureContext resolves colors, optional theme style references, and image relationships. Bitmap fills reuse the picture pipeline before geometry clipping. Zero-axis connectors retain their geometry but use a minimum one-pixel logical paint frame to prevent division by zero in consumers.

render_text_fill(fill_xml, id, context) produces SVG paint attributes and definitions for no-fill, solid/alpha and supported gradient text fills. Gradients use the painted text bounds; the caller supplies a unique identifier, lays out the glyphs and inserts the definitions into the same SVG. The DOCX adapter uses this for WordArt text fill. text::outline_text shapes portable font outlines, text::measure_text supplies matching advances, and text::warp_text maps those contours through preset DrawingML paths. render_3d_path applies shared camera, bevel, extrusion and lighting to outlined text. Native comparisons retain font-substitution and shading differences.

Shape paint includes all 54 native pattern tiles, scaled linear and circular gradients, rectangular path gradients, and closed compound outlines. Pattern tiles use an eight-point period and carry page-origin metadata for consumers that can resolve mounted page placement. Exact tile pixels do not establish full-page parity; rotated and grouped pattern phase remains limited. Shape paint bounds round outward to integer pixels without changing layout dimensions.

smartart::parse_smartart_data reads semantic points and connections; smartart::parse_smartart_drawing reads the saved drawing tree, preserving ordered shapes, connectors, pictures, groups and explicit text transforms. DOCX and PPTX adapters compose those drawings using the shared renderer and their own text layout. This does not implement the SmartArt data-to-layout engine. Missing saved drawings use explicitly reported caller fallbacks.

HSL, tint, exact color replacement, and alpha ceiling use bounded raster processing. The color transforms preserve native Office software arithmetic, including its 240-step HLS conversion and preprocessing order. Native software and hardware output can differ by a few color levels. Glow and soft-edge SVG approximations require further visual comparison across geometry and radius combinations.

normalize_raster converts a base64 image data URI to PNG, including TIFF images that browsers cannot display directly. Decoding supports PNG, JPEG, GIF, BMP, TIFF, and WebP; it applies stored orientation and uses the first image/frame. Limits are 16,384 pixels per dimension, 16,777,216 total pixels, 128 MiB of decoder allocation, and 96 MiB of input base64 text. Encoded PNG output is limited to 72 MiB. Rendering uses the same limits when raster color processing is required.

The cached bitmap in a DrawingML blip preserves an already-rendered artistic appearance. Regenerating artistic effects from an original image is not implemented. Effect trees support bounded sequential containers, five blend modes, alpha modulation and selected color operations. Referenced effects, multiple sibling branches and geometry-expanding graph nodes remain unsupported. Other limitations include exact native material matching, preset shadows, open compound outlines and compound endpoint markers, nonrectangular shape-contour gradients, detached fill rotation, and nonlinear raster operations combined with blip blur. Full SmartArt layout generation is not implemented. Single-path and paired-envelope WordArt deformation is supported; unsupported geometry retains fallback. Unsupported, invalid, over-limit, or unchanged pictures return None; callers should retain the original representation and report unsupported decorated pictures. This API does not assert complete Word parity.

The crate has no operating-system, application-automation or browser dependencies. Both native callers and WebAssembly use the same rendering implementation.

model3d::parse_model3d(xml, &ParseOptions { include_3d_models: true }, resolve_asset) returns the embedded 3D model asset, its relationship IDs, optional saved-preview metadata, and source XML retaining camera, transform and lighting settings. Model3DAsset carries the package part name, content type and original bytes. The resolver is called only for embedded assets; linked resources are retained as references without fetching them. The default options return no model object and do not invoke the resolver. A missing asset or preview does not discard the model metadata. This exposes the original model payload without decoding meshes or rendering a new 3D view.

render_effects(properties_xml, svg_body, width, height, context) applies supported effect lists and effect trees to trusted SVG generated by a caller. The body uses local coordinates within the supplied frame. The caller validates its SVG, resolves resources, and scopes the returned IDs before combining outputs. Decorative layers carry data-office-art-effect and disable pointer events; visible source geometry remains available for hit testing. This entry point does not accept or sanitize arbitrary document-provided SVG.

render_ink(xml, width, height) reconstructs bounded InkML traces with physical coordinate resolution, differential coordinates, pressure, brush shape, color and opacity. It returns expanded paint bounds while preserving the layout frame. Unsupported brushes or malformed input return None for the caller to retain its cached representation.