Diagrams can have BGF (BackGroundFill) and also FGL (Fore
GroundLine). BGF is already represented by BGS
(BackGroundShape) and im/exported. It's definition is not
associated with a shape in oox at all, but part of
data.xml of the Diagram definition.
They also can have a LineStyle definition, also in data.xml
which is in XML-Tag 'whole'. This was never imported until
now at all - just missing. This is also not associated
with a shape. I implemented im/export for oox also adding
this to BGShape. This is FGL.
NOTE: For ODF there was no change needed since the BGS
is im/exported as XShape with all attributes set, thanks
to the SplitModel idea.
Unfortunately FGL is *in front of* all Diagram geometry,
what the 'whole' tag slightly hints at. Hard to see by any
evtl defined LineStyle overlapping the Diagram geometry,
if you take a detailed look.
There are two basic ways to solve that:
(a) Add FGL to a 2nd shape at the end of the Diagram
geometry
(b) Add to BGShape, but get visualization right by using
Primitives or ViewContact functionality.
Both have pros and cons:
(a) has the problem that a SubSelection will only
select one of these, so in UI only BGF or FGL are
editable - while in MSO when the Diagram is selected
both can be edited.
(b) has the problem that the BGShape is displayed in
the Background, including LineStyle settings.
(b) can be solved by
(1) using ViewContacts involved in visualisation of the
Group hosing the Diagram. The Primitives are fetsched
from these, so if needed manipulating these is possible.
(2) using the Primitives from BGShape visualisation to
filter these. That could be done with a
PrimitiveProcessor, but is a lot of work. Also would
evtl. need some tooling for every Primitive derived
from GroupPrimitive2D to get that cloned/changed.
(3) Manipulate Primitive-creation for BGShape as needed.
This is difficult since this is a CustomShape itself
and thus that whole mechanism that creates the geometry
for the customShape would have to be manipulated. What
makes it more complicated.
After some experimenting I decided to use (b1). This
involves a ViewContactOfDiagram that is used when the
SdrObjGroup hosts a Diagram. It checks if manipulation
is needed and modifies/adds ViewContacts to the Group
as needed. To do this without risk, it uses local
clones of SdrObjects for the BGShape with changed
ItermSets (FillStyle/LineStyle deactivated). Also
needed is refreshes of VCOfGroup and for changes of
BGShape. Luckily I had added all that to VCs already
when I implemented these and can use it here.
Forgot and added: Of course UnGroup has tro react on
the situatzion with BGShape and remove/change/create
objects as needed, plus UNDOs.
The complicated part are the UNDOs due to some need
to be created *before* doing the action in the core,
some *after*.
Had to adapt UnitTest testSmartartRotation2:
Adapted sp[4] to sp[3] since disconnectFromSdrObjGroup
does now remove a BGObject if no Line/FillStyle is
used at all, which is correct.
This was the 1st (empty) shape in ungrouped
representation, so tested info moved to sp[3]
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I13d0b9b913336155164e6543529a8fb3b0bb8f9e
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2959
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit c7b67f7d71323dab66c2d4df9519bd2f1091697e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206024
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Much-improved Writer oox roundtrip. It now checks if export
is possible as Diagram at all. It is capable of re-creating
ModelData and ReplacementGraphics. Cross-checked with ppt/oox
roundtrip, too.
Original Writer import held the DomTrees in the GrabBag of the
GroupObject, but by default converted content to a single graphic
shape containing a Metafile. This of course contradicts that
part of the new DiagramModel is in the Shapes - adjusted now.
I see no plausible reason to by default do that in the future
when we want to do more with Diagrams. Nonetheless that stuff
is still there if AdvancedDiagramFeatures is not enabled to
stay compatible until we can activate the feature.
Needed to adapt the ShapeImport for ReplacementGraphic for Writer,
it is (why?) different in oox from Impress import. Added needed
stuff like import of ModelIDs.
The export of ReplacementGraphic in Writer also is different,
needed to adapt to behave more like Impress export when Diagram
creates that.
Unified usage of useAdvancedDiagramFeatures to one place, adapted.
This allows fast changes (e.g. to use ExperimentalMode if needed)
or removal.
Change-Id: If8b73029615e8c9e5d6d93db26449bdfe6e3ef97
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/990
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit f2f9961505ea7278e6aba84ab06fdced401a7851)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204739
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Moved creation of Undo/Redo actions for geometry changes directly
to the methods addDiagramNode/removeDiagramNode of class
DiagramHelper so that not every caller has to do that again.
Removed from DiagramDialog where that was done before.
Extended DiagramDataState which is used for SdrUndoDiagramModelData
with needed Model information. After using SdrModel/XShape data
as part of the DiagramModel it is necessary to also keep that
info when geometry gets changed. Also the current transformation
of the group hosting the Diagram is needed. Also the end state
of change in SdrUndoDiagramModelData is now late-evaluated
to get the changed state. This is needed in redo, so evaluating
this if undo is used is the thing to do.
Added a general mechanism to apply locks to the SdrObjects,
see applyLocksToDiagramObjects. It currently sets MoveProtect,
ResizeProtect and DeleteProtect. These get un-set when the
Diagram is reverted to a simple SdrObjGroup to not hinder
further editing.
There is currently no ToFront/ToBack lock or others which
may be needed. In principle all geometric changes to objects
of the Diagram need to be blocked.
Also still missing is that the BackgroundObject has no
LineAttributes, or better is not allowed to have these due
to mso only offering a FillStyle for that object. Not sure
yet how to do that.
Added a mechanism to automatically delete the buffered
original data when attributes change, see
ItemSetInformationChange. This is triggered by
AttributeProperties::ItemSetChanged, but needs to be
prevented during import (which also changes Items).
Added support to delete the SubSelected object if it
is a TextFrame. This leads to geometry change and
re-layout and also creates a Undo action now.
Attribute access to SubSelection is done in
SdrEditView::MergeAttrFromMarked/SetAttrToMarked
so that attributes can now be changed like for
regular objects.
Also some methods in SdrMarkView had to be adapted to
work with the SubSelected object.
Extended Diagram SubSelection to make tab/ShiftTab work, including
from where the Diagram is entered. Also made direct MouseKlick
work.
Added simplifications to work with Diagram stuff, some
tooling directly at SdrObject.
Due to UnitTests I reverted the decision to have all SdrObjects
in the Diagram 'flat' without Groups. That would be easier and
is what the import of MSO visualizationm replacement often uses,
but not what a reLayout creates.
Those complaining tests are the pptx ones that have no replacement
graphics (no drawing*.xml) and have to be re-layouted using our
mechanism as existing so far.
So keep groups again for now. Price is that all stuff handling
SubSelections has to use SdrObjListIter instead of SdrObjList.
That makes it somewhat more complicated, but work on a virtually
flat hierarchy of SubObjects in any case - maybe safer for the
future.
Also looked at that Locking oif SdrObjects again also due to a
test. I wanted to use the extended/newer stuff, but applying it
made the office crash. After some debugging I found that in
SdrObjList::RemoveObject the remove is *cancelled* when
SdrObject::IsDeleteProtect is set for that object. Unfortunately
that remove is due to moving the object to another target
list, so it should happen.
This is probably a relict of very old stuff, to prevent object
delettion that way (!). For now I use the fact that this happens
during import.
Change-Id: Ied2263928106e2cb02047e2e9a55c680384b2932
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201497
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Changed the DiagramImportSize no longer be handled/held
as part of the DiagramModel part, but with the change to
use the XShapes/SdrObjects consequently use the
transformation from there to be consistent.
With that change also added own impls of
TRGet/SetBaseGeometry to SdrObjGroup. There were none,
thus the defaults from SdrObject were used. This is
mainly correct, but since SdrObjGroup is based on
GetSnapRect() it already contains the evtl. existing
anchor offset (from SW), so the results were wrong
for SW.
Secured the knowledge if we are in Im/Export by adding
methods for is/inc/decImportExport to SdrModel and using
these. Locking the model was pretty safe, but e.g. missing
for import. Still added it there to be consistent with
other imports, may also bring some speedup.
I have cleaned LayoutNode from the member
'SmartArtDiagram& mrDgm' since LayoutNode is model data
and with that in place it would have been necessary to
deep-clone or re-import the complete DiagramLayout,
just to make sure that those members of SmartArtDiagram&
will reference the correct - newly created -
SmartArtDiagram.
That again would have been hard to keep under control
due to LayoutNodes hosting a full hierarchy of LayoutNodes
in it's base class LayoutAtom, so complicated deep-copy
and need of virtual Clone method at LayoutAtom to do the
right thing for all eight derivations of it.
This is now no longer needed. It can just stay shared, thus
the DiagramLayoutPtr gets just copied above. This reflects
that the layout mechanism hosted by these atoms is not
changed itself, but used (in some ForEach manner) to create
the shapes, so does not need to be changed itself.
It gets now just additionally referenced by the
SmartArtDiagram copy costructor. That is for non-deep
copy/paste where this copy operator is used.
Instead of deep copy the SmartArtDiagram constructor with
import from boost::property_tree has to be used which will
have to re-import the layout model data to mpLayout anyways.
Instead of having SmartArtDiagram as member it now will be
handed as needed to import contexts (LayoutNodeContext and
derivatives).
All those classes are used temporarily and are not part of
the model. It also gets handed over for shape re-creation
in LayoutAtomVisitorBase and it's derivates. Also those
classes are used temporarily and are not part of the model.
Added detection of click on Diagram frame in SC and SW to
get the Dialog working as in SW and SD to be able to test#
some stuff.
All still secured by ACTIVATE_ADVANCED_DIAGRAM_FEATURES
and wirk in progress, but some stuff is looking better.
Change-Id: I660b205155a4e317585035ec3cacddbc96db08c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200875
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Added functionality to ex/import using boost::property_tree
and it's read/write_info functionality, based on conversion
to/from OUString. This keeps it most user-readable in XML
format. I currently use <svg:desc> to add it, secured by a
token and preserving evtl. existing Description at the
GroupObject hosting the Diagram, but may move somewhere
else. This has the advantage that <svg:desc> is supported
since version 1.0 and the SmartArt/Diagram ModelData *is*
the object's Description. Not sure yet, we will see.
There were some hard parts, e.g. I needed to find a way to
incarnate a class defined in oox inside svx and that class
is derived from baseclass in svx in oox, but got that done.
Still secured by ACTIVATE_ADVANCED_DIAGRAM_FEATURES since
this will still need some corrections, but basic round-trip
is functional.
This will allow to copy/paste between two office instances
and is also the base for thinking about providing gallery
functionality for Diagrams.
Had some problems with boost/property_tree stuff var
shadowing, also lock of model was missing in
SvxDrawingLayerExport, will change that in next version
to ssth more sophisticated.
Change-Id: I526d3b2477b5de40df990345c9c06d0a2f9cbfeb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200219
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Replaced PointNameMap in DiagramModel, too unsafe with
needed StateUpdates. Simplified some stuff dependent on
that. More stable now with changes. Embedding of
DiagramModelID back to ObjectName, that's just better.
Re-activated locked state for SdrObject members of
Diagrams for now due to UnitTests, but see comment
there.
Had to add an exceptional case to
XMLDiff::compareAttributes due to usage of GuidString,
see comment there. DiagramNodes do save their
GuidString in the name attribute of XShape. That
ID can change at every usage, thus when extracting
it *cannot* be compared to something saved/checked
in in a given state.
Change-Id: I112425d1efde58cfde8792cf2ee8c0c688d517e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199502
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Next thing we need copy/paste. That creates internally
a new doc with the cloned selected object. Two cases:
(a) If copy/paste is inside same instance, that gets
cloned again to the target, done.
(b) If target is other app (2nd office instance, ...)
new doc is saved using ODF (or other), re-loaded
by target LO instance and then cloned like (a)
For (a) we need cloning functionality in LO core.
For (b) we need support in ODF format. Thus (a) is
less complext than (b) and a precondition for (b),
too.
This change mainly enables (a). It also contains deep
check of correctness for DomTrees for Data and
Drawing stuff, especially for Pint and Connection
data.
Also as a 1st step for (b) I moved the
DiagramDataModelID to use the SdrObjectTitle - those
Objects are encapsulated inside the hosting
GroupObject anyways and we have that part of ODF
im/export solved that way.
NOTE: I first used SdrObjectName, but that gets
*changed* when SdrObject is cloned to ensure
unified ObjNames inside a Document.
This is secured by ACTIVATE_ADVANCED_DIAGRAM_FEATURES
as last commits for SmartArt since notg complete.
Change-Id: Iff51ca56e559111cc8d205fc501d96b0a1d7c616
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199287
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
I digged into why when using graphics and/or links the current
method to re-create missing DataDoms (for OOXData and OOXDrawing)
did not work. Reason is that :blip and :hlinkClick need to
get embedded in the MSO way.
Only way to do this is to use the original target for writing with
all that directory structures included, no way to keep that using
a temp file for writing. The alternative would be to use a target
with supporting that directory structure, but then would need to
move all kind of stuff to real target.
Thus I had to adapt all DomTree creation to be done at export
time. That creates the correct exports, but I will no longer have
a simple entry point for just creating missing DomTrees.
Also stumbled over 'Relations' and their extensive use in MSO
file formats & exports, learned about how that stuff is partially
automated - I was really surprised to see code that queries a
PropertySet from a XOutputStream - but hey, use what is there...
Also learned that :hlinkClick and :blip in MSO XML formats
for Diagram, both, the OOXData and OOXDiagaram, need to write
additional Namespace info in form of xmlns:r and pointing to
relationship schema - for *each* such entry.
As until finished this all is secured by EnvVar
ACTIVATE_RECREATE_DIAGRAM_DATADOMS not not break stuff until
all looks stable.
With this changes it now works to export a changed Diagram
and reload and it stays a diagram. Still quirks, but now
supports fills for BG/Shapes/Nodes and Links for Text in
Nodes.
Had to adapt to UnitTest testfdo79822 where a TestFile
created in ms word 2007 is used. It has *no* initial
DrawingDom. This might be corrected in the future,
but for now do what previous versons did: Do not
create a DrawingDom from scratch (we can now...)
Change-Id: I0cb326ab5a340acfd7bb4d7f511178ea68bb15f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198756
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This change adds writing the OOXDiagram SmartArt replacement
graphic. This makes stuff working better, but still stuff
missing. With this we have now two of the 4-7 (optional)
DomTrees used for the Diagram data representation.
Still deactivated, to use for experiments you will need to
set ACTIVATE_RECREATE_DIAGRAM_DATADOMS.
Change-Id: Ic6c1108d6cf0037302085b6f22433b199d40ee53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198435
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Up to now with lots of effort ModelData was held at the
svx::diagram::Point to keep a stripped version of Text and
TextAttributes and also a selective (not complete!)
key/value list of attributes for each shape itself
(fill/line/text/...).
These had to be moved to/rescued from oox::Shape that is
used as helper at import to that model after import, set again
at the oox::Shapes when XShapes had to be re-created, you name
it - very complicated and error-prone, and never complete
by definition.
Nonetheless data in OOXML MSO format, so pretty easy to re-
export if necessary /that's what I was looking at last
changes).
That also meant that all changes done to an XShape/SdrObject
*had* to be somehow transfered to that diagram model data,
too. We have no converters for that at all, target would
be data representation as in OOXML files.
What we *have* is import to our model using oox::Shapes and
ccreating XShapes/SdrObjects, and export XShapes snippets
'direct' to MSO ooxml formats.
Thus I thought about to use what we have, for the cost to
split the model: the DiagramModel *has* to be kept to be
able to re-create the Diagram on structural changes, that
is needed. But the attribute & text data can stay at the
associated XShapes that need to exist and get created
anyways.
That needs reliable identification of the XShapes
belonging to the model. It requires to load that Diagram
initially, using the oox::Shapes which have the complete
attribute model data to create the XShapes.
Remember that there is a 2nd import, from the
ReplacementGraphic which (may) be contained in the MSO
file.
From that moment on changes on those XShapes will be
diagram model changes if attributes get changed.
But they will not need to forward changes to the
DiagramModel in another format.
When re-layouting it means to copy that data from old
XShape to new XShape, before these get deleted. There
may be new XShapes that need to be initialized, too.
For export this means that part of that export will have
to use the XShapes as model data as needed.
This also means that the quality of im/export of
Diagrams will in the future rely on the quality of our
existing im/export snippets for XShape/oox::Shape/oox.
These are developed and in use for a while now and
should have reached a good quality. If we have to
improve these that will always improve im/export
and Diagram stuff then, too.
This change does that big change and looks promising,
doing what it is intended to do. I still have to
experiment, so in master it is still deactivated due
to being too dangerous yet, see last SmartArt change
and mention of ACTIVATE_RECREATE_DIAGRAM_DATADOMS and
it's description.
Change-Id: Ife1591b0d3c8974d90a1004d94f3e6799be85a56
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198221
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The DiagramModel uses 4 mandatory and three optional XMLDoms
for it's data. These get imported, but to get to a roundtrip
we will need to be able to create & save these again.
Last changes prepared this by deleting XMLDoms which were no
longer valid dependent of changes done to that DiagramModel.
When exporting the availability of these gets checked and if
all are there, it gets exported as Diagram (in MSO format,
not yet in ODF). If nothing was changed the original Doms
get exported - untouched.
That test will now try - if e.g. the most important XMLDom
OOXData is missing - to re-create this in that action. The 1st
one which I now implemented that is the OOXData which homes
the Point/Connections/BGFill data (and some more).
Due to this needing testing I for now encapsulated this
to a EnvVar called ACTIVATE_RECREATE_DIAGRAM_DATADOMS, so
this will for now only happen when this is set. Anyways all
that stuff is still behind the 'experimental features' wall.
This is and stays experimental for now.
These are already deep changes which need to get tested and
get to master, opening the path to experiment with it and
refine it. Due to the EnvVar gate no real changes should
happen in master, but due to the changes around it this
will need to be checked this way.
Change-Id: Iabba69b19387e45f1028843a25f3bae1fc4f8fe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197676
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Moved the next step so that now changes to the Diagram
model will delete associated DomTrees at the DiagramHelper,
thus using these as overview/info if export in original
form is possible.
Needed to re-organize all of that and move away from
Strings as Keys and PropertyValue pairs.
All methods (currently three, but will grow) changing
the model now return flags to signal what parts of the
model have changed and based on these thatDomTrees get
removed.
Saving the Diagram will now check for the mandatory (four)
DomTrees to exist and only then save in original form.
That now defines the place where when model is/was changed
a new DomTree needs to be created from the changed model.
Changed PrepareToWriteAsDiagram to static, requested
by [loplugin:staticmethods] and for now possible, but
will probably change.
Change-Id: I3866bb69203997b69e3bfa5bfd7f0cbca82cb97d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196833
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Information about an imported Diagram was buffered at the
SdrObject in the GrabBag, mainly the original imported DomTrees.
This was done before a place like DiagramHelper existed and has
no practical background.
It is now held at the place where it belongs, at the
DiagramHelper associated with the SdrObjGroup. It makes it
easier to reset the no longer valid DomTrees when the Diagram
model data changes, also automatically that info is removed
when the SdrObjGroup is no Diagram anymore, together with the
DiagramHelper.
I also have and maybe will need UnitTests, so put this on
gerrit early.
ShapeContextHandler::getShape needed correction, it has to
1st migrate the DiagramHelper and then use it.
Had to correct testTextEditEmptyGrabBag. There are no
GrabBag Items anymore for the Diagram, but still from
OOX import, e.g. OOXRotationAngle. Not sure if these
will be needed in the future, but for now had to reset
GrabBag for changed attributes.
Need to secure access to uno::Sequence when accessing
xml::dom::XDocument in DrawingML::WriteDiagram to
avoid access to non existing index if not used.
I used the wrong name for the DiagramDataRels entries,
corrected these to "OOXDiagramDataRels".
Change-Id: I60b17e1211314ae50e7d1a9a43fd14a8b56c9d78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195579
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
In the case the input file does have a graphical
representation of the Diagram as image file, the
DiagramModel was not fully loaded. For being able
to edit the Diagram in the future it is necessary
to re-create the geometry, thus a full model is
needed.
Needed to know at recreation if this is the first
time the geometry gets self-created using the
layout/creation mechanism to decide if to apply
the style or use the saved/reapplyable data from
secure/restoreDataFromShapeToModelAfterDiagramImport
mechanism, added that.
Change-Id: Icb7590306ab59728e83b800b8637333e0d372de5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168223
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
The auto-fit algorithm has been tweaked to be more in-line with
the expectations of OOXML. This means a couple of changes to what
properties are scaled by the algorithm have been made:
- most properties that influence the X axis position or size (for
example indent) are not scaled down or changed by scaling.
- properties that influence y axis position and size are scaled
by a separate parameter (like in the OOXML). This is used in the
auto-fit algorithm in a different way.
- if line spacing is proportional, it is now scaled with the
spacing parameter. Fixed line spacing doesn't get scaled.
- the main scaling X,Y parameter only scales the fonts.
- trying hard to scale the fonts to the nearest pt (point) value
With this change the scaling is much more stable than it was
before - for example it doesn't matter what the unscaled font
size is, when it is scaled down to the text box size, it (should)
always look the same (for example scaling from 32pt -> 10pt or
64pt -> 10pt or even 999pt -> 10pt).
The algorithm is also rewritten to be better at finding a fit and
is also better at find a good fit, but it can take more iterations
by doing so (there are ways to improve it however). Previous
algorithm used a linear search to converge to the best fit in less
iterations, but the issue with that was that it could in some cases
miss a solution (especially since change to floating point scaling
parameter). The new algorithm now uses a binary search - always
trying the middle of the search space.
OOXML export and import was also changed to take advantage of the
font scaling and spacing scaling parameters. The additional
scaling at export that was needed to have consistent OOXML support
was removed.
Change-Id: I8f3bb8d43a01931f18bd7ffdf8e0ba40caa73d8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149207
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
To have a more direct and more reliable association between the
XShape/oox::Shape and the model data svx::diagram::Point I added
optional usage of the Model-UUID for that at the oox::Shape.
Also added a 'fake' UUID to work with the BackgroundShape's
attributes. Changed all preserve/rescue code to work based on that.
Also cleanups/comments and preparations of some flags in the
Diagram ModelData to steer behaviour on re-ceration.
Change-Id: Ie30effdff34dcdbbc79a766de09157b2a3bd97d3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133168
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Additionally to the Text/Attributes already saved/secured after
Diagram import, secure more data that is part of the Diagram
ModelData. This is about attributes (e.g. FillStyle/LineStyle,
TextAttributes, ...) in UNO API formt that will be secured/
attached to the Diagram ModelData in it's
svx::diagram::Point structure.
This is done for all those entries for which a XShape will/
would be incarnated, thus associated to entries that will
get a visualization, including the BackgroundObject.
From that data, at re-creation time, the attributes can be
re-applied to the re-created XShape(s), also after changes
to the Diagram Model Data (e.g. Add/Remove).
This is - besides the already added securing of the Style/
Theme - a 2nd method for lossless re-creation. For the
BackgroundObject - if it has FillStyles - it is even the
only method to secure that data and thus necessary for that
case. The selection of atributes that gets secured is minimal
for now and may/need to be extended for existing cases
accordingly.
Change-Id: Ie9b72b9b9135113cf858d57fe6cd8622d736c4a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132976
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The Style/Theme information is central for re-creating the
Diagram shape representation. Make that data available in
the ModelData classes in svx. With that information, a re-
creation with all needed attributes is possible, e.g. when
the model gets changed (remove/add data entries).
Also some cleanups done.
Change-Id: Icd925c9731891092f1ddd96c8feb165e1f846f4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132738
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
The BackgroundShape may have a FillStyle after import, so do
handle that FillStyle accordingly. Also enhance breaking
the Group by keeping that shape in that case and deactivate
Move/Size change lock for it. Also Undo needed.
Change-Id: Iccdb236a2311275efc07162fd4bd2cfc252fd437
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132626
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
In a next step to get the Diagram mechanism/ModelData independent
from oox, I moved the Text ModelData to svx, using a TextBody
struct. This is a 1st move that covers most of what the
algorithms to handle Diagram re-layout and other functionality
use. This will potentially have to be extended accordingly
when missing data is detected. It is potentially much more
simple as the oox TextBody, by purpose.
Due to functionality using that data I could now massively move
more of it to svx.
Change-Id: I6d6e6c572f119aeefa4e91eff56f58f3ceb6a31e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132523
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Splitted and moved parts of DiagramData class to svx as peparation
to access from there. Done as pure virtual class so that no
incarnations will be possible, also made the constructor protected.
The derived class in oox hosts all functionality/data which
involves usage/modification of oox::Shape class. That way we get
closer to get the Diagram DataModel isloated/seperated.
Not-yet moved is the String/Text holding data, it's still in oox.
Moving that one will be next, that will allow to migrate quite
some more functionalty to svx.
Change-Id: I389dbf3ebf6171b8175cf30be7bbc8c20d9a38e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132303
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
As preparation for own im/export move data classes for
which that is now possible to svx
Made TypeConstant more safe, also sorted it. Corrected an
error there. Secured TypeConstant usage by identifying
usages (mnType -> mnXMLType). Had to convert from
oox::OptValue to std::optional since 1st is not available
in svx in datamodelcontext.cxx. That makes the test work
and the test-file load corrrectly.
Change-Id: Ifee008caf486ddb6b52a347dc08e7e053c49ef49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132195
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
When we come from the LO-side of things and need to (re)create the
Diagram, no oox-Shapes can exist by definition. That forces to see
oox-Shapes as temporary helper objects.
Since some ModelData is at the oox-Shape after importing a Diagram
that data needs to be identified and added to the Diagram
ModelData.
On the other path, when (re)creating a Diagram from the ModelData,
oox-Shapes are needed to use the currently existing mechanism
in the import-Filter to create XShapes froom the oox-Shapes. In
that path, the Diagram ModelData needs to be applied to the
newly created oox-Shape.
For now I have identified e.g. the Text as such data value. In
the future there may be more ModelData of that type identified
and may need to be added. To support that, I have added methods
to do that.
It may even be feasible in debug builds to add code to compare
the imported oox-Shape with a temporarily (re)created one to
allow easier identification of yet missing secured/copied
ModelData.
To make that mechanism obligatory I have added code in
DiagramData::build() that deletes all oox-Shapes which were
created at Diagam import. This is necessary. That way, the
(re)creation is used for Diagram re-creation and can be already
used and tested.
Deleting all oox-Shapes in build() immediately triggered an
error in a UnitTest: testPictureStrip. This shows that here
some ModelData in form of BitmapData is not secured - proof
of concept and what I described above.
To get forward, I adapted to not delete oox-Shapes when
Diagram import is executed. Thus, the UnitTests work, and
the ReCreate can be used to trigger that behaviour. As
an end result this has to be re-activated. It allows now
to search and add the missing model data from the test file
used in that UnitTest.
Change-Id: I6bc39a0898c7be1b4c656875f6d7508c36c9bea8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132127
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
As preparations to use the Diagram ModelData further isolate
it from the oox-library-only drawingML Shape used for import.
It is necessary to completely isolate the Diagram ModelData
from the Diagram import mechanism as a preparation to be
able to re-create that Shapes on-demand anytime if needed
for re-layout(s).
Also removed one unused loadDiagram implementation and
streamlined the AdvancedDiagramHelper some more.
Change-Id: I7a7c55389e0d00f70c02db73ce2c3ff9ce7a5b22
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132058
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Goal is to minimize dependencies on oox classes. For that pupose
I redesigned the Diagram class to work without remembering
an oox::Shape at all. For reLayout, a new temporary one is created
and used. That was a bit tricky, I needed to find out what
data at the oox::Shape is needed to sucessfully do that with
the not-originally-imported one.
Another necessary change was to move the DiagramFontHeights
adapting mechanism away from oox::Shape, too. It fits better
to Diagram class. That way it can also be used for reLayout
and the oox::Shape gets a little bit smaller, too.
This opens the path to move needed Mode-Data Diagam core
claasses to other libs where changing/im/exPorting them will
be possible.
Change-Id: I40bc4b190d2abc797f5c56f9e476d22155d21422
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131004
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reorganized and streamlined, use IDiagramHelper as main interface
now also for existing code.
Had to adapt oox::Shape && Diagram handling since there the
import gets handled very different. This ensures that a Diagram
is detected at export and that the same happens for now as before
Had to add a detection that resetting the GrabBag is meant to
disable the Diagam functionality. That is very indirect, but
has to stay for compaibility reasons for now
Change-Id: I620b7d61cd84b5f9dd8ae4dc890ebf70ce779cdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130389
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
To allow advanced Diagram/SmartArt support in the future
this is a first step to organize imported SmartArt Data in
a way that will allow to re-layout loaded SmartArts, under
re-usage of the oox::Theme (held available).
It is designed to work without holding available the
original XML snippets defining the imported Diagram in any
way, also for performance reasons. It tries to re-use some
of the already basically added functionality, including
the systematic layouting using the generic layout
algorithm, plus some already available text extraction.
Before being sure that the former state can be completely
replaced this is optoinal and used when
SAL_ENABLE_ADVANCED_SMART_ART is defined. Some new stuff
is already done but e.g. the redefined reLayout method will
not (yet) be triggered. It works and reliably produces a
re-layouted identical version, also preserving
transformations.
Change-Id: I08cfbae04afa663d0589530aae549216d853128d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130171
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This also allows to easily add more units, both of length and for other
unit categories.
The conversion for "Line" unit (312 twip) is questionable. Corresponding
entries in aImplFactor in vcl/source/control/field.cxx were inconsistent
(45/11 in; 10/13 pc; 156/10 pt). They were added without explanation in
commit c85db62602. I haven't found a spec
of the unit (https://en.wikipedia.org/wiki/Line_(unit) is not specific).
I used the definition based on "by pt", "by mm/100", "by char" (they all
were consistent); "by pc" seems inverted; "by twip" was half as much.
This accepted conversion makes unit test for tdf#79236 pass.
Change-Id: Iae5a21d915fa8e934a1f47f8ba9f6df03b79a9fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110839
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When 2 or more shapes have their text set to autofit and they have a
constraint like:
<dgm:constr type="primFontSz" for="des" forName="node" op="equ"/>
Then make sure that the automatic font size is the same for all shapes
and all content fits, by using the smallest scaling factor from all
relevant shapes.
Some rework is needed, because normally oox::drawingml::Shapes don't
have access to their parents, at the same time there can be multiple
SmartArts on a single slide, so storing the grouping info in the filter
is problematic, too. Solve this by storing the grouping in the toplevel
oox::drawingml::Shape and exposing them in XmlFilterBase just during the
time the children of the toplevel shape of the SmartArt are added.
This works, because we know SmartArts can't be nested.
Change-Id: I6c591eadc7166c7c42752650afdb7ee1e416cff6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102490
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The bugdoc has an arrow shape which is 100% wide, and there are multiple
shapes before it, which also have a 100% wide constraint. The reason
PowerPoint scales down the shapes (but not the arrow) is because rules
declare it should happen this way.
So start taking rules into account in linear layouts.
Change-Id: I352443277e88be0eb711659489587127727a258f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99855
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The TODO in the ColorFragmentHandler ctor was right: we only handled the
last <a:schemeClr> child, but there can be multiple one.
Use them based on the index of a shape in a <dgm:forEach> loop.
Move the TODO to the only place which still assumes a single color in
the color list.
Change-Id: I1c5c4f82e621f1110ef06b0490ff79f82f60f214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94697
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
