Files
odfstudio/drawinglayer
Armin Le Grand (collabora) 3b0aa2199e SmartArt: Calc Diagram Im/Export improvements
Calc imported Diagrams due to using mainly DrawingLayer
oox import code, but export, even of the unchanged
DomTrees, was missing (just never done). Thus in
versions before this being a Diagram was lost, it
just always was converted to a GroupHierarchy containing
the Shapes that were part of the Diagram.

Added to read the Diagram's name at Import at all for Calc
oox import, set and used now at the created Diagram.

Added to secure/save the DomTrees for the imported
ReplacementGraphic when importing oxx Calc, that was just
also never done, so it could not be exported as unchanged/
original data (and was not, so that was never noticed).

Added complete export of oox Diagram to Calc. This includes
unchanged versions, but also changed/added versions. This
may need more work, but own turn-around works already.
This mainly uses the same ExportContent, but that needed
some adaptions.

Doing this I also changed the ShapeImport of Calc to use
a single oox::drawingml::ShapeExport, before it created
a separate temporary one for every Shape that was imported.

Also added the checkMinimalDataDoms check to Calc oox
export that is already used in the other apps. As always,
there are huge differences in oox im/export for Calc
compared to the other apps, e.g. a completely different
Group ImportContext is used compared to Impress and I have
no idea why that is done.

Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Ib7c1b73f7f72599f6054d0cf9203f46980eec5cf
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1887
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit b1fbe49401e5e4dbe62ff25580ec7252c0376e88)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206019
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2026-06-05 12:42:07 +02:00
..
…
…

Drawing API

Drawing API that can specify what to draw via a kind of display list.

Example of the DrawingLayer use is eg. in svx/source/xoutdev/xtabhtch.cxx:121. A stripped down version with extended comments:

 // Create a hatch primitive (here a rectangle that will be filled with
 // the appropriate hatching, but has no border).
 // This will not draw it yet; it's so far only constructed to add it to a
 // display list later.
 const drawinglayer::primitive2d::Primitive2DReference aHatchPrimitive(
     new drawinglayer::primitive2d::PolyPolygonHatchPrimitive2D(...));

 // Create a rectangle around the hatch, to give it a border.
 const drawinglayer::primitive2d::Primitive2DReference aBlackRectanglePrimitive(
     new drawinglayer::primitive2d::PolygonHairlinePrimitive2D(...));

 // Here we want to render to a virtual device (to later obtain the bitmap
 // out of that), so prepare it.
 VirtualDevice aVirtualDevice;

 // Create processor and draw primitives, to get it ready for rendering.
 std::unique_ptr<drawinglayer::processor2d::BaseProcessor2D> pProcessor2D(
     drawinglayer::processor2d::createPixelProcessor2DFromOutputDevice(...));

 // Fill-in the display list.
 drawinglayer::primitive2d::Primitive2DSequence aSequence(2);

 aSequence[0] = aHatchPrimitive;
 aSequence[1] = aBlackRectanglePrimitive;

 // Render it to the virtual device.
 pProcessor2D->process(aSequence);
 pProcessor2D.reset();

 // Obtain the bitmap that was rendered from the virtual device, to re-use
 // it in the widget.
 aRetval = aVirtualDevice.GetBitmap(Point(0, 0), aVirtualDevice.GetOutputSizePixel());

DrawingLayer Glossary

Primitives - classes that represent what should be drawn. It holds the data what to draw, but does not contain any kind of the rendering. Some of the primitives are 'Basic primitives', that are primitives that cannot be decomposed. The rest of the primitives can be decomposed to the basic primitives.

Decomposition - a way how to break down the more complicated primitives into the basic primitives, and represent them via them; this logically makes the plain Primitive2DSequence display list a hierarchy. Eg. PolygonMarkerPrimitive2D can be decomposed to 2 hairlines PolyPolygonHairlinePrimitive2D's, each with different color.

Processor - a class that goes through the hierarchy of the Primitives, and renders it some way. Various processors, like VclPixelProcessor2D (renders to the screen), VclMetafileProcessor2D (renders to the VCL metafile, eg. for printing), etc.

How to Implement a New Primitive ("Something New to Draw")

  • Create an ancestor of BasePrimitive2D (or of its ancestor if it fits the purpose better)

    • Assign it an ID [in drawinglayer_primitivetypes2d.hxx]

    • Implement its decomposition [virtual Primitive2DSequence create2DDecomposition(...)]

  • Extend the (various) processor(s) If you need more than relying on just the decomposition

Where is DrawingLayer Used

  • SdrObject(s) (rectangles, Circles, predefined shapes etc.)

  • Selections

  • Various smaller cases to 'just draw something'

    • Draw to a virtual device, and use the resulting bitmap (like the example above)
  • Custom widgets (like the Header / Footer indicator button)

Dumping DrawingLayer Primitives as XML

For debugging purposes, it is possible to dump the drawinglayer primitives as an xml file. The drawinglayer xml dump can show possible problems with the rendering.

For example, in emfio/qa/cppunit/emf/EmfImportTest.cxx, one can write:

Primitive2DSequence aSequence = parseEmf(u"emfio/qa/cppunit/wmf/data/stockobject.emf");
drawinglayer::Primitive2dXmlDump dumper;
Primitive2DContainer aContainer(aSequence);
dumper.dump(aContainer, "/tmp/drawyinglayer.xml");

Then, after invoking make CppunitTest_emfio_emf, /tmp/drawyinglayer.xml will be the dump of the drawinglayer primitives used to draw the emf file in LibreOffice. The top level tag will be .