https://bugs.documentfoundation.org/show_bug.cgi?id=144869
--- Comment #7 from [email protected] --- Regarding the question in comment 5 whether the use case justifies the effort, and the concern in comment 4 about objects grouped across layers: Use case: Sozi (zooming presentations, https://github.com/sozi-projects/Sozi) uses SVG layers as independently animated planes, like Inkscape. Drawing in Draw and presenting with Sozi is a FLOSS-only workflow that currently fails because the SVG export has no layers. Working reference: I implemented the mapping outside LibreOffice, as a Python script (https://github.com/tebbiworld/draw2sozi, MPL-2.0) and as an .odg import in a Sozi fork. Both are tested with LibreOffice 26.2.6.3 on Windows: shapes, groups across layers, text frames, images, connectors, dimension lines, rotated shapes. The information needed is all in the document (draw:layer per shape, draw:layer-set for the order). Proposed rules for an option “Group by layer”: One <g> per layer directly under the SVG root, with id, inkscape:groupmode="layer" and inkscape:label = layer name, stacked in the order of the layer list. Groups spanning several layers are kept intact and placed on an additional layer (e.g. “Groups”), on top. No grouping is lost; only the stacking of these groups relative to other layers can change. This avoids the trade-off described in comment 4. Master page objects on a layer of their own. Empty layers are omitted. Related, smaller improvement: shapes with a name (draw:name, Format > Name) could get that name as SVG id. The generated ids (id3, id4, …) shift when shapes are inserted or reordered, which breaks anything that references shapes by id (Sozi frames, CSS, scripts). My implementation does this, with fallback to the generated id for invalid or duplicate names. The export code is in filter/source/svg/svgexport.cxx (implExportPage, implExportShape); layers are not used there yet. -- You are receiving this mail because: You are the assignee for the bug.
