Problem
SVG files in our current corpus still warn with svg: <linearGradient>: unsupported element skipped, which causes artwork that depends on gradients to render with incorrect solid-color fallback or not at all.
What implementation would require
- Extend the SVG parser to collect
<linearGradient> definitions from <defs> and index them by id.
- Support
fill="url(#...)" and stroke="url(#...)" references in style parsing.
- Parse gradient stops, offsets, stop-color, and stop-opacity, including simple class/inline style resolution.
- Respect gradient transforms and
gradientUnits for the common objectBoundingBox and userSpaceOnUse cases.
- Add a PDF-side rendering strategy. This likely means either:
- approximating gradients with axial shadings if the writer can expose that cleanly, or
- rasterizing only the affected painted object as a fallback if native PDF shading support is too invasive for the first pass.
- Add parser tests plus at least one visual/golden test using a real gradient asset.
Workarounds
- Replace gradients with flat fills in exported SVGs when possible.
- Pre-rasterize gradient-heavy SVG assets to PNG before embedding.
- If only a small number of brand assets need gradients, keep an alternate simplified SVG without gradients for PDF generation.
Problem
SVG files in our current corpus still warn with
svg: <linearGradient>: unsupported element skipped, which causes artwork that depends on gradients to render with incorrect solid-color fallback or not at all.What implementation would require
<linearGradient>definitions from<defs>and index them byid.fill="url(#...)"andstroke="url(#...)"references in style parsing.gradientUnitsfor the commonobjectBoundingBoxanduserSpaceOnUsecases.Workarounds