Both are derived from SfxSetItem which means they contain
a SfxItemSet themselves. That leads to problems since at
their construction time a SfxItemPool has to be known and
it *should* not be different to the one of the ItemSet
that Item gets added later - that leads to the 2nd class
of problems.
In the long therm we should get rid of all SfxSetItems.
This change simplifies already some stuff, including that
the standard Items for DrawObjects reduces by two (and
more due to containing a whole ItemSet) and e.g. the
problem that these Items had to be converted to hard
attributes in the done fixes for copy/pasting Slides.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I8b1c6cabdaa43ed6062811b5508ab3dece47a755
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6795
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e67458a9b769fe7a3a7ee0739ed6d5c46dbc0692)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211734
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Until now the 'local' StyleSheet got set, but that may
not be the same as the original. It was/gets identified just
by searching by name and type, not comparing content.
What to do? We could...
(a) the Style-Friendly way:
- check if StyleSheet is identical
- if not, create a new in-between StyleSheet hosting missing Items
- if yes, use, done.
(b) the pragmatic/practical way:
- Just hard-attribute the Items that are detected as different
similar to what BurnInStyleSheetAttributes does/did, but only
for a view differing Items
(b) is the most simple for now, but will lead to more hard
attributes. The other possibilities will be better in the
long term. For now, I will use (b).
Note that there are more cases in that VERY complex and grown
stuff emerging from SdDrawDocument::PasteBookmarkAsPage. More
things will need to be fixed, see this as a 1st step.
Needed to adapt postProcessAfterCloneToDifferentModel due to
UT testTdf96206 failing, see comment there for details.
That 1st implementation showed weaknesses with those Items
critical and only on MasterPages, so decided to give up on
that and implement ContentCompare to SdPage::Equals. That
was easier than thought: No parameter needed, only used by
InsertBookmarkAsPage_FindDuplicateLayouts::operator(). Thus,
SdPage::Equals needs no change, just SdrObject::Equals.
Due to still problems with Items corrected in Objects on
MasterPages I will for now exclude this.
Could now isolate remaining problems, these are defaults
and/or PresObj things on MasterPages. Important is that I can
completely correct all Items for all Objects in
postProcessAfterCloneToDifferentModel. I can react to these
false-positives in the ContentCompare in SdrObject::Equals.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I10e17c8d6a893dbe92ab716182f07bafce1f3284
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6595
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit 92ffaeac04c5c8586006b026f29ce12fba3674f1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211729
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Whatever SdDrawDocument::renameObjectStylesIfNeeded is
intended to do, it changes the look of SdrObjects when
doing what it does.
I am not sure if these are just the 'wrong' StyleSheets
that got copied or something else. It may happen when
slides from more than two sources get copied to a
document: The newly imported styles get 'extended' names
following a naming scheme. When pasting from a 2nd
document, the *same* names for slides get created using
that naming scheme, so before these were re-used here
assuming they have the same content - which is wrong.
To just *ensure* that the objects look will not change,
compare previous ItemValues with those ItemValues after
changing the style, that guarantees equal look - for the
cost of some more hard-set attributes, but less
StyleSheets.
I see that these corrections *are* done, so that is a
clear hint that re-setting these Styles in this whole
import has basic errors, I have to correct the values.
Also use a SdrObjListIter, the version before *only*
visited all SdrObjects plain on SdrPage, leaving all
GroupContent out.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I0cf1f823bddcea0b0087244268d1dc224da39638
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/6449
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 605790cb198686d382c809de949094755e70e833)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208432
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
In commit 93aa742ba3 which is
20 years ago 'cl' did a big change to get to SfxUndoManager
which is a needed abstraction for the formally Svx-based
Undo/Redo stuff.
Unfortunately SdrModel::SetUndoComment was *not* supported
and this was expressed as just doing a
OSL_FAIL("svx::SdrModel::SetUndoComment(), method not supported with application undo manager!" );
in SdrModel::SetUndoComment when SfxUndoManager was used.
But SetUndoComment *is* used in nine cases in
svdraw/svdedtv2.cxx. All of these execute some action and
create Undos for it. All nine Undos were without any Undo
text since then - over 20 years...
I stumbled over that when adding needed Diagram stuff to
UnGroupMarked().
I fix this with this commit. Creating that fix showed me
why 'cl' intentionally did not support that, but just
abandoning functionality is not a good choice.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Idde2fcecc85a9eee39b62d38ed7d71a8cfbd3288
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2486
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 5adf090261d705123074a0fa1c46119b2bf44bf3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206022
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
This did crash. Basic reason is that SdrEditView::UnGroupMarked()
does not work. This is because pSrcLst->RemoveObject(0) for
historical reasons does nothing and returns NULLPTR when
DeleteProtect is set for the SdrObject.
Thus use DiagramHelper::disconnectFromSdrObjGroup which does
the somewhat preparing job of removing all Diagram stuff from
the hosting GroupObject. This also already supports Undo/Redo
of all that Diagram data.
Also needed to clear DeleteProtect for BackgroundObject
early if not needed.
It is better to keep 'UnGroup' also for selected Diagrams,
instead of adding a new command (and name). This is the
logical command for the User to also 'end' the Diagram
aspect. Doing this including Undo/Redo will not need another
command as the mentioned 'Convert Diagram to Group Object'.
That slot is internally useful, but we then do not need it
at the UI with another Name we would need to come up with.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I84e1c0888a33ccc0eb1e6eee7350acafc97adccf
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2375
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit eeda9d461c35c367b9c21e80715a92c53f499c29)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206021
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Currently the Graphics from imported and unchanged Diagrams
is held in uno::Any structures (look for DomMapFlag like
OOXDataImageRels/OOXDrawingImageRels) in the form of their
binary data. It gets deleted when the Diagram is touched,
and written to a new rels DomTree when the Diagram was not
changed.
The problem is that if multiple Diagrams exist and/or the
identical Graphic is used somewhere else these Graphics
are written double (or more) since before this change they
were written always.
This change now directly remembers the used XGraphic in the
uno::Any, so no extra space for the binary data is needed.
These are then used for export if necessary.
In the to be created rels the RelIDs have to be identical
since the original DomTrees for model and/or replacement
graphic gets written. This *could* be adapted to new
RelIDs but would be complicated, not easy and is not
needed.
The export uses more common methods that I had to slightly
adapt to add a XGraphic to the media part of the target
file, these already are capable of detecting existing
graphics. These now return a new relative path to the
media part that then gets used in writing the DomTree of
the created rels file.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: Iebbfe08d495d67b17eeaaadc76233e096df85727
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1915
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit 5429358ead879f3d9f350c0ff05193813e6f5119)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206020
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
We already did some improvements, but I wanted to clean
this up somewhat. Reason for the needed corrections was
in principle the sqrt()-based general calculation of
the HoldTime in the default implementation of
calculateCombinedHoldCyclesInSeconds. The original idea
was to hold huge data shorter due to memory constraints.
To solve that we added an adapted version to
CairoPixelProcessor2D.
With lessons learned I decided to remove that and
provide a revised general implementation based on linear
scaling of the HoldTime. Based on assuming the seen
huge Bitmap and estimating 20min for it, just create a
factor and multiply with SizeInBytes.
I checked that and it works as intended. It will spare
us from this problem re-occurring with future SDPRs.
NOTE: This still keeps the CairoSDPR-specific avoiding
of buffering of small Bitmaps when these are available
from Bitmap directly. This stays useful and is
Cairo-specific.
Signed-off-by: Armin Le Grand (collabora) <Armin.LeGrand@collabora.com>
Change-Id: I30c7361c6fbfaf0be90be353091cbaf831db5cd2
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2005
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a3d3ae5e931a04ff5718382ccffe9f16de336a42)
(cherry picked from commit 7550c6ea0bb82f7574e4b974f8d24bd1662a878b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205991
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
When isCairoCompatible and we can get cairo_surface_t
directly from Bitmap for small instances (used 160x100
here, can be adapted) use directly. There is no need to
prepare for MipMapping, so spare the
SystemDependentDataHolder buffering for that cases.
For more information, see comments in commit.
Change-Id: Ia9d51a5749124d7001daf2e5355ceec5afccb264
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1384
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Armin Le Grand <armin.legrand@collabora.com>
(cherry picked from commit 62dbd904fbea0dee4d54f1bb75601af40c6b91c4)
(cherry picked from commit a23e06360e796e1264f40d31c818d3ac3a5a1f54)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205989
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
If we have a really 'big' pixel-based graphic the cost for creating
the mip-map entries is high. If that is the case, force keeping this
entry alive and not getting flushed by using a large number of
seconds. In that case the local MipMap is more important than the
memory kept allocated for fast repaints.
To detect 'big' graphics, compare to an assumed ScreenSize (may also
be fetched from real screen if needed). To react, create a buffer
residing time of one hour (increase if needed).
NOTE: This will increase MemoryFootPrint if isCairoCompatible
is false by holding the local cairo_surface_t in CairoSurfaceHelper
longer than before.
Change-Id: I1cf726f00d459bc0cb19bb1d202e64e010061426
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1134
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 2e1b0a51a745e615ed7e2f22666cc4aa4e005451)
(cherry picked from commit c2c58c177ae822906fe2c558546851643fe54247)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205988
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
The BackgroundShape of a Diagram does have only Fill
attributes, so LineStyle stuff has to be de-activated
when it is selected as SubSelection. Tried to do that
as generic as possible, but may need some more work.
Added code to allow the same DirectTextEdit for
SubSelection shapes as for regular shapes. Needs to be
limited to TextNode shapes. This is
(a) just starting to type when Object with Text is selected
(b) support Double-Clicking it to start TextEdit
Change-Id: I8b5ae618684f915aabed48281aa980227c04266c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202871
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Fixed a missing trhing in DiagramDataState used by
SdrUndoDiagramModelData. The BGShapeID was not restored,
so after copy/paste and change and Undo the BGShape could
not be associated and loose it's FillState ModelData.
Simplified Point/Connection Im/Export for own format.
No need to read/write NumOfPt/Cn at all. No need to
read/write Pt#/Cn# at all. Simplified AFAP before this
will be used when feature is activated.
Change-Id: I6fca23964df708a5da13fdb620376b7a5684e1a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202582
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Added Undo/Redo SdrUndoDiagramDissolveModel that handles
changing the Diagram to a GroupObject when using the uno
command SID_DIAGRAM_TO_GROUP/".uno:DiagramToGroup". This
converts Diagrams to Group objects (and back with undo).
Moved the Undo/Redo functionality AFAP to the functions
offering the actions, so this only needs to be implemented
in one place. Adapted usages.
Removed flushing remaining UndoStack in SdrUndoManager,
the Undo/Redo is getting more complete and thbis should
no longer be needed.
Added SubSelection travel and MouseCklick SubSelection
functionality to Calc and Writer. This is now complete
for all apps.
Added im/export of Diagram ModelData to Calc and Writer,
it already was added to Draw/Impress to make copy/paste
work. Unfortunately that needed some digging due to
every app doing im/export of XShapes/SdrObjects slightly
different. Used already created toolinf AFAP.
Change-Id: Idb57dcec88f8ca2f37f7360f9ad433996819d122
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202243
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
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>
A loaded SmartArt allows to start TextEdit when one of the
included nodes gets klicked. TextEdit seems to work, but the
object degrades from a SmartArt to a GroupObject with content.
I try to add the preconditions here which are needed to be
able to do change at a SmartArt in the future. Basic problem
is that the ModelData for SmartArt are 'attached' to the
GroupObject that is used for representation, but no ways
exist to support edit/change and promote that to that
seperated model.
One of the main hindrances is that the needed IDs that
create the associations between that model and the Shapes
is missing, added that. This needs to be added for two
scenarios (what makes it complicated):
- loaded replacement visualization
- re-created SmartArt (add/rmove used)
To test this I added a simple text edit that does a first
change at that SmartArt model data. For now just simple
text, of course TextAttributes need to follow, as do
changes when Attributes get changed (Line/Fill/style/...)
Thus it's a 1st step and needed quite some experimenting.
As long as this is not further progressed (which I try to
make happen) the default will stay to have SmartArt as
GroupObject with content - as it is today.
Unified connect/disconnect, added slot and commands for
disconnect, adapted test to use that.
Needed to adapt UnitTest testTextEditEmptyGrabBag, it needs
to work with a *real* SmartArt/Diagram. The former test
created a 'fake' one and checked if on TextEdit the GrabBag
gets deleted.
The updated SmartArt text edit *tries* to keep the Data (in
IDiagramHelper attached to SdrObjGroup). It clears the
GrabBag, but only if a 'real' SmartArt exists.
Thus I added a bugdoc for that task which contains a 'real'
SmartArt to test if GrabBag gets cleared on change of the
model data.
Also added a modified state to the SmartArt model data
(which is in IDiagramHelper). This is needed to decide
what shall be done at export time. As long as we have
no SmartArt model data export, the fallback to conversion
to SdrObjGroup has to be used (as before).
Change-Id: Ie6ef3f3a8bbc5da99984d85f79f89e5df308e3c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195097
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
ImpEditEngine::DrawText_ToPosition has to take into account
if a ClipRegion is set at the target OutputDevice when it
renders using primitives, this is *not* automatically set
or taken over when a PrimitiveProcessor is created for that
target.
This revealed a problem, see comments in
editeng/source/editeng/impedit3.cxx for a detailed
description.
Change-Id: Ied2cf3f59d57099e616ebe9969c721f796b4b227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192919
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Armin Le Grand <Armin.Le.Grand@me.com>
SubpixelPositioning was until now activated when *any* MapMode was set,
but there is another case this is needed: When a TextSimplePortionPrimitive2D is rendered by a SDPR.
In that case a TextLayouterDevice is used (to isolate all Text-related
stuff that should not be at OutputDevice) combined with a 'empty'
OutDev -> no MapMode.
The DXArray for Primitives (see that TextPrimitive) is defined in the
Unit-Text_Coordinate-System, thus in (0..1) ranges. That allows to
have the DXArray transformation-independent and thus re-usable and
is used since the TextPrimitive was created.
If there is a DXArray missing at the text Primitive (as is the case
with SVG imported ones, but allowed in general) one gets automatically
created during the SalLayout creation for rendering. Unfortunately there
(see GenericSalLayout::LayoutText, usages of GetSubpixelPositioning) the
coordinates get std::round'ed, so all up to that point correctly
calculated metric information in that double-precision dependent coordinate space gets *shredded*.
To avoid that, SubpixelPositioning has to be activated. While this
might be done in the future for all cases (SubpixelPositioning ==
true), for now add this case for all usages of TextLayouterDevice to
not break old stuff.
NOTE: Due to higher precision I had to adapt some values for SVGIO
tests: That is expected since higher precision leads to less-wide
results internally. I checked testdocs that deviations are minimal and
have better quality with SubpixelPositioning then before.
Change-Id: Iab5aa6336cdb18224fd06472bf6badc9eb0fce3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189993
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
The OutlinerView was one of the last using XOR selections
instead of the User-defined selection color on the resp.
system. I changed that now.
That View has no Overlay, it would have been possible to
add it and then do TextEditOnOverlay and SelectionOnOverlay
as in other situations. But there is nothing 'behind' the
text, so I decided to stay at paint, but use Primitives.
The TextContent (and 1st line Icons left) are now extracted
from the EditEngine, using the mechanisms I added recently.
That means e.g. as long as the user only scrolls, moves
cursor or zooms, it is no longer necessary to re-create
that text as Primitives. This is of course done when the
text is changed (or attributes). Also not done on seleciton
changes.
Thus in most cases it no longer does: setup the EditEngine,
set the text, format the text, layout the text and paint
the text (again using 5 layers of VCL). The 1st part is
now done on-demand when the text has changed, the 2nd part
uses an SDPR if it exists instead of OutputDevice.
The only change when visualization changes is to embed the
text primitives to the StartPoint offset & embed to a
clip primitive, and visualize transformed existing text.
This makes it much faster - try a presentation with many
slides with text and change to the EditView, scroll &
zoom around, or change selection with keyboard/mouse.
The selction uses a temporary OverlaySelection object
to keep the creation of Primitives same and equal to
other places.
The OutlineView can have multiple OutlinerView's, but all
of them - if used - are based on the same Outliner, so
this gets not too complicated, only one seq<Primitives>
is necessary.
Change-Id: Ic9cea237b6d074f4fa18a0605ed80fabd0633178
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189523
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
See task, there may be bitmap-filled objects in files that
have a logical size of (0, 0), despite the bitmap having
valid data. That leads to problems *inside* cairo paint,
so I have to test and avoid that.
Change-Id: I18db3b030fb5cdf77caa5afd1bf901095fa1c67b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189135
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Have now found a way to also change ImpEditEngine::
DrawText_ToEditView to work without StartPosition.
Thus adapted StripAllPortions accordingly, plus
logical follow-up changes where StartPosition/
Origin is not needed/Point(0, 0) used.
Change-Id: I1513778943705967752dddf8923012b66561e10a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188958
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Since 6c8b802051 which is
'StripPortions: full Primitive usage for EditEngine Paint'
all DrawText_To* methods were already using a full
conversion to Primitives which then get painted directly,
see commit comment there.
Since then no complaints/errors came up I now continue
to move EditEngine to Primitive usage. Lots of code for
the still also existing DirectPaint gets removed.
I also drive forward changes to have less parameters
for the ImpEditEngine::StripAllPortions method. It is
already cleared by the former possible rotation, this
can (and is) replaced by embedding the result to a
transform primitive doing that rotation. I changed
two of three using methods to strip always to
position (0, 0) which can also be unified to embedding
to a transformation. The third one will need some more
work here due to doing wild things in Outliner mode in
Impress (callbacks & creating Primitives in fixed
positions for which an embedding translate would be
wrong).
When being able to strip without position and rotation
the result will be usable to be buffered, so the goal
is to re-use that, transformed as needed (translate,
scale, rotate, ...) as long as the text itself does
not change.
Change-Id: I52ab548ccbb1b5b3b16c50451a314bc7f3b39d93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188918
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
This allows setting/using DrawModeFlags system-independent
(or: renderer-independent). Changing and applying to a
PrmitiveRenderer will apply that (if needed) to the target
renderer.
Change-Id: Id95d018f95d1b2ff065da5e4d05ba385b22cdbb0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188704
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
Did the necessary now, despite it would be better to apply
that where the geometry gets created (primitives) or painted
(older direct-apints to OutputDevice).
Instead it's in Outputevice where care is taken to apply
changes based on DrawModeFlags. Remember that this is then
done in the renderer.
This will need to be done in every renderer in the future
then. It is traditionally done in OutputDevice, completely
missing in PresentationMode and added now to CairoSDPR.
Problem is that it is not defined how to apply that, e.g.
(even in OutDev) painting text may lead to decompose and
fill the resulting polygons, so the ::*Fill flags are
applied while I think the ::*Text ones should be used.
I looked a lot at OutDev and what it does and tried to
mimic it as good as possible, but cannot give guarantees,
as mentioned in the example above.
If we assume that (as usual) the definition of what should
happen is the existing stuff when using OutDev this might
cause some further errors/regressions in HighContrast
and Black/White/Gray/Settings stuff. Luckily most of that
seems to be used in UI/Button rendering when using
OutDev, so should not lead to big problems. OTOH if
we want to use SDPRs for that in the future we would need
that anyways...
One more note: the fixes already applied may be removed
again after this is applied.
Change-Id: Ie6eb1cd4ee51c62beb950030a0a5d00d3705be61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188527
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
In OverlayManager rendering AA state is set at the target
OutputDevice, this obviously only works if the target
renderer *is* an OutputDevice, thus not with e.g. CairoSDPR.
Thus I added changing ViewInformation2D in BaseProcessor2D
directly. This simplifies if changes to a primitive renderer
have to be made while it's lifetime.
All other aspects of ViewInformation2D can of course also
be changed. There were occasions in the past where working
around this was needed, this is then obsolete.
Since e.g. setting AA at the target renderer which
may not always be an OutputDevice makes this also target
device independent - the primitive renderer is the instance
that knows how to apply this correctly.
Change-Id: I1836d08d0844dfed81bb84e8fccbe3fabe2831c3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188220
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
need to react on change of EditViewActive in SdrTextPrimitive2D
decomposition, added that. Only do that in HighContrast mode
to not waste time if not needed.
Change-Id: I7300dfdcf8d51ef4db9ecc67f56c785d45ef44e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188112
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
When parts of the output need to be pre-rendered (e.g.
transparencies) the temp target is of course pixel-aligned,
bit the mapping for the rendering was not yet. Added that
now. This could lead to sub-pixel displacements which are
usually not recognizable, but also like here make the
PixelSnap fail.
Change-Id: I877987947bdcc7521580de9287894ca70b17763c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187928
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
There were three methods left that use PaintOrStrip in
a mode to directly draw Text: DrawText_ToRectangle,
DrawText_ToPosition and DrawText_ToEditView.
I adapted all three to use PaintOrStrip in a Primitive
creating mode and render using a PrmitiveRenderer.
While StripPortions was already using the Primitive
creating mode the others needed adaptions ranging from
handling clipping over rotation to transformations.
I checked these as good as I could, but since errors
cannot be excluded, I added an ENV_VAR called
DISBALE_EDITENGINE_ON_PRIMITIVES
with which that change can be deactivated. Please use
this by setting it for the office when bugs pop up
whose bibisect point to this change - if it does not
happen with that var set, this change is responsible.
Offering this comes with a cost: Currently PaintOrStrip
*still* offers both modes, but when this change causes
no big problems I will be enabled to remove all direct
paint and stuff done extra there. This will then allow
in the future simpler changes since changes to EditEngine
output will no longer have to be done in two scopes.
For now this allows all remaining places that paint
EditEngine content still directly to continue to work.
This can in the future be extended to get the exact
same context as seq<Primitives> so offers the path to
potential re-use (not only paint, you can process and
transform Primitives in many ways).
A special case is the SD OutlinerView: It uses a set
callback (PaintingFirstLineHdl) to additionally paint
a PageNumber and a Graphic in that mode, but I managed
to replace/extend that to Primitive usage so this is
also prepared for simplifications in the future. It
would also be good to change that callback from it's
current form then.
Change-Id: Idc9233f0ce27c3e4153851f4e45faa24d15af36d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187628
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
At EditEngine, ImpEditEngine, Outliner, OutlinerView
and EditView. Changed to more explaining names. Checked
parameters.
Change-Id: Iccf8ce82d2772cbd769269014e920739a11bece2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187483
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Tested-by: Jenkins
