pub enum Geometry {
Preset(PresetShape),
Custom(CustomGeometry),
}Expand description
A shape’s outline (EG_Geometry, the choice between <a:custGeom> and <a:prstGeom>).
Geometry::Custom only models <a:custGeom>’s own required <a:pathLst> — a single
<a:path>’s moveTo/lnTo/cubicBezTo/close draw commands, the vocabulary explicitly asked
for by plan. Not modeled: guides (<a:avLst>/<a:gdLst>, formula-driven adjust-handle values),
adjust handles (<a:ahLst>), connection sites (<a:cxnLst>), the optional bounding <a:rect>,
quadBezTo/arcTo draw commands, and multiple <a:path> elements within one <a:pathLst>
(CT_Path2DList allows several — e.g. for a shape made of disjoint outlines — only the first is
read back, matching the single-path case every real custom shape this crate has been asked to
support so far actually needs). All of the above are minOccurs="0" on CT_CustomGeometry
except pathLst itself, so omitting them entirely still produces a schema-valid element.
Grounded against a real fixture (ppt/slides/slide6.xml), which confirmed the assumed element
order and nesting exactly. That same fixture also revealed a real reading gap: its <a:pt>
coordinates are guide-name references (<a:pt x="f2" y="f2"/>, resolved via <a:gd name="f2" fmla=".."/> entries in the <a:gdLst> this crate doesn’t model) rather than literal integers —
ST_AdjCoordinate allows either. Since [crate::reader]’s path-point parser expects a literal
integer, a shape using formula-referenced coordinates currently round-trips its points back as
(0, 0) instead of erroring loudly. This crate’s own writer is unaffected (it only ever emits
literal integers), so the gap only bites when reading a complex shape authored by real
PowerPoint with adjustable guides — accepted as an out-of-scope corner of the
“literal-coordinate common case” this crate targets, rather than implementing a formula
evaluator for <a:gdLst>.