When a filter condition on a column has more than one part, e.g.
"LIKE A* AND LIKE *e", only the first part was converted back to UI text
with its operator; the rest were appended as bare values
("LIKE A* AND *e"). Convert all parts the same way and add a UITest.
Change-Id: Id6a2ecd5593003c3a9fcef1955f2c672ec1ed520
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211425
Tested-by: Jenkins
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
Carry the GraphicClipPolyPolygon UNO property on graphic-object
shapes through ODF save/reload as a new <coext:graphic-clip-poly>
child of <draw:frame> with the polygon serialised as svg:d (the
same SVG d-path encoding draw:path uses). A new XML_GRAPHIC_CLIP_POLY
token is added in lockstep across xmltoken.hxx, xmltoken.cxx, and
tokens.txt so the XMLTokenEnum and FastParser tables stay aligned.
The element is taken before the frame decides what its shape child is, and
applied when the frame ends: an empty presentation object has no draw:image for
the polygon to follow, so the polygon comes first and the shape it belongs on
does not exist until then. A placeholder saved to ODF came back unclipped
otherwise, which is the shape of file our own save writes.
It goes on the image the frame keeps, which is not always the last one it saw:
a frame with a replacement image holds several, and the ones that lose are
taken off the page and disposed.
Export goes through a new ImpExportGraphicClipPoly helper called
from ImpExportGraphicObjectShape alongside ImpExportSignatureLine
and ImpExportQRCode (under ODFSVER_EXTENDED). Import is handled
in SdXMLFrameShapeContext::createFastChildContext, which is where
<draw:frame> children land - the GraphicObjectShape sub-context is
nested inside that and never sees this sibling directly.
The element is added to the extended ODF schema next to
loext-signatureline and loext-qrcode, so a document carrying it
validates, and is listed in the Collabora ODF extensions notes.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ib9ae65c1b6f2d8fdb28ae086fd7e2be2f8a8ee24
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9191
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit b7a56041afda6b658b6b16bb51a5939295c40d75)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210122
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The clip a graphic object carries was kept in the model and carried through
save and load, but nothing ever drew it, so a shape a file describes as an
outline still covered its whole frame and hid what sat behind the parts the
outline leaves out. Wrap the shape's content in a mask.
The polygon states the shape's own coordinates, so it is normalised and then
put through the same object matrix as the content, and follows the shape's
rotation and shear along with it. A flip is expressed on the graphic itself
rather than in that matrix, so the clip is mirrored here to follow it - the
picture would otherwise turn round inside an outline that stayed where it
was. The mask covers the fill as well as the graphic, which is what uncovers
the background. The invisible outline stays outside it, leaving bounds and
hit-testing as they were.
A mask clips with an even-odd fill, which is what makes a contour overlapping
another one a hole.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I69c8c6c31f43e87399fb582665904dc81221b32b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9302
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 120b9ef0b7c50a0e025e7be87e005aa39ab7db8a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210037
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Introduce an SfxPoolItem in the SDR graphic attribute range that
carries a basegfx::B2DPolyPolygon clip outline on SdrGrafObj.
Allocate SDRATTR_GRAFCLIPPOLYPOLYGON between SDRATTR_GRAFCROP and
SDRATTR_GRAF_LAST (which shifts SDRATTR_3D_FIRST and the downstream
ids by one), register the pool default, and surface the value as the
"GraphicClipPolyPolygon" UNO property on the GraphicObjectShape
property map (covering both drawing.GraphicObjectShape and
presentation.GraphicObjectShape via SVXMAP_GRAPHICOBJECT) using the
css::drawing::PolyPolygonBezierCoords type. QueryValue/PutValue
do the round-trip through the existing basegfx helpers.
The new which-id is 1175. The trailing comments in svddef.hxx have
run 2 high since two XATTR items were dropped upstream, so the ones
added here say 1177 to stay consistent with the file.
No reader, writer or render path consumes the property yet; this
is infrastructure for upcoming custGeom round-trip work on empty
picture placeholders.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I17d98cabeb230c25b3de0da4eadd8338ed672ce1
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9190
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit be7f21fc7187bb87129eed4e8ed2f794faf6e757)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210036
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The document-wide link update permission is decided when the document is
loaded. But media files that the users interactively inserts should be
automatically allowed.
Remember on the media object that the user picked the reference and
allow it on its own, the same way a presentation sound the user picks is
allowed. A reference that arrived with the document still needs the
document-wide permission.
since:
commit f0768394c14f928d47547408fc1195368be81f86
Date: Tue Jul 14 19:12:01 2026 +0100
put slideshow media links under link control
see also:
commit 0aa870b7b5a6bda50bab50c7a0a41d28fdf4f6ab
Date: Wed Jun 17 09:37:23 2026 +0000
bring external presentation sounds under link management
Change-Id: Id9fd49245fbfe2d62d767e3cb04370b2e5197fe1
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/7939
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7961
(cherry picked from commit 82f3a17f461fb2d0057cc81625f7ae1e301db3ad)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208739
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
And not truncate it to an integer value.
Add additional overload for attribute that takes an enumerated type, otherwise
the compiler will complain about ambiguous conversion because it cannot
choose between the attribute that takes a integral value and the one that
takes a double value.
Change-Id: I9eae22817ec3b26da7b9468d1c8b5e6f3e900538
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201193
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
For the case when mnShapePresetType >= 0, the code setting it was added
in commit c50e44b270 (tdf#126060 Handle
text camera z rotation while pptx import., 2019-10-16). But it omitted
the other case.
This change also improves positioning of the rotated text, initially
implemented in that commit. The rotation is now added to the block text
decomposition as a separate transform primitive. The text center is now
obtained directly from the decomposition. After the change, I see about
1-pixel difference compared to PowerPoint render at 100% zoom (before
that, the offset was tens of millimeters).
testTdf128212 had to be corrected, because the metafile now has a new
element in the parsed XML, and the final positioning has changed (it is
better now). Unfortunately, I don't know what would it now produce if
the fix is broken, so I had to remove respective comment.
This change does not fix tdf#128206.
Change-Id: I86cbd0710744b14e8b9b68a436affc5b08703a12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201286
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
All internal calculation for transformation use the order resize, shear,
rotate, translate. Thus the transformation of the points determining
the angles of non-full SdrCircObj need to use that order too.
Change-Id: If05310c64813bcffa410a328cf831b3f0b4c07e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198630
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
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>
In tests we many times rerun the XPath search to just check another
XML attribute, or first check the size of child elements and then
check each element's attributes in a separate call (re-running the
XPath search). Re-running an XPath search all the time takes up
quite some CPU resources and doing it a lot will accumulate, so the
idea here is to have an object as a result on which you can reuse
instead of re-running the search.
In addition it is possible to combine the search path from the
previous search, so it is possible to construct paths in a more
concise way.
Example:
auto primitivePath = aXPath.create("/primitive2D");
auto polyPath = aXPath.create(primitivePath, "/polypolygon");
polyPath will use a combined path "/primitive2D/polypolygon"
as the search path.
Checking can be done by simply using CPPUNIT_ASSERT* functions
with this, but we might extend UnoApiXmlTest with some checks
for convenience because the assertXPath methods do have better
reporting when the assert fails. Also integration into the
UnoApiXmlTest class will need to be done, because namespaces need
to be registered before tools::XPath can be used correctly. This
change does not touch that yet.
A couple of tests in SvdrawTest have been changed to use the new
tools::XPath class - most notable testRectangleObject. These tests
don't use any namespaces so it is easy to convert those.
Change-Id: I29251d2e7f4c3ee5b76e46daf78c21d0ca067cb4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195618
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.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>
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
now that Bitmap can handle transparency.
This just removes the Graphic(BitmapEx) constructor and pushes
the conversion from BitmapEx->Bitmap out to the call sites.
Change-Id: I5d8b9838365458524185d3cfffe4a8f05d40d0ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190324
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
now that Bitmap supports transparency
Tweak a couple of unit tests. Since some backends use
pre-multiplied alpha, if A == 0, then RGB will also
be zero.
Had to comment out one unit test (see comment in unit test).
Change-Id: I45e4b5ea9f21e3c5bc74992ca4ecee1897212821
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189022
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
This patch also fixes tdf#119951 and perhaps tdf#148039.
WARNING: This patch will likely resize the text line height
in every table imported from PPTX.
Someone must have figured out that Microsoft just ignores
the font metrics, and simply adds 20% to the font height
to achieve a "single spacing" line height.
In LO, that is either termed FontIndependentLineSpacing
(a misnomer because it DOES depend on the font ascent/descent)
or FixedCellHeight
(also a misnomer because it so far hasn't applied to cells/tables
and certainly is not restricted to cells/tables
since it was implemented for customShapes).
With this patch, my particular document
now has the right "text/table height" according to a PDF overlay.
The theory is that this change is needed for every document.
The reason this patch is needed is because
svx/source/table/viewcontactoftableobj.cxx's
createPrimitive2DSequenceImpl
passes rCellItemSet as the ItemSet
that will eventually be checked for
rSet.Get(SDRATTR_TEXT_USEFIXEDCELLHEIGHT),
which creates attribute::SdrTextAttribute(bFixedCellHeight)
which is used by SdrTextObj::impDecomposeBlockTextPrimitive
to set SdrOutliner (and thus EditDoc) with
SetFixedCellHeight(rSdrBlockTextPrimitive.isFixedCellHeight());
With FixedCellHeight, impedit3.cxx calculates text/line height
using ImplCalculateFontIndependentLineSpacing.
make CppunitTest_svx_unit \
CPPUNIT_TEST_NAME=testTdf165521_fixedCellHeight
I modified testTdf144092TableHeight,
and attached PDF overlay images to tdf#144092 as proof
the the table should be taller than originally stated.
Change-Id: Ibb4af395b77a3f4d30b5c2e8a08429b701f1ae95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183130
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This specifically avoids a PPTX custom shape's editEngine flag
from bleeding into the remainder of the document
and affecting another shape's sizing calculations.
This bleeding was noticably affecting PPTX table sizes,
triggering the investigation that lead to this patch.
FALSE REGRESSION NOTE:
It appears that perhaps PPT/X tables SHOULD ALWAYS
be sized according to SDRATTR_TEXT_USEFIXEDCELLHEIGHT = TRUE.
In other words, tables currently match MS Powerpoint's table size
only when they accidentally have this setting bleed through.
With this patch, we are effectively always setting it to FALSE,
and thus tables will never be accidentally correct anymore.
... and the same possibly is true for all kinds of other shapes.
The problem with having a correct table size
is that the text inside the table needs to also
be in sync with this sizing calculation.
Otherwise it will either be too small (commonly),
or it could spill out of the table
(in cases where the font is designed with a large leading).
This patch's effect on tables is to allow
the table to only be defined by its own content.
Now when other actions cause a table recalculation
(like selecting text, drag and drop, editing)
the table size won't fluctuate (since in this re-draw context
there wasn't any FixedCellHeight bleeding into the calculation).
make CppunitTest_svx_unit \
CPPUNIT_TEST_NAME=testTdf165521_fixedCellHeight
Change-Id: I5239c78cf8f1e8fffd65b6aa285a840428e92e5c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183172
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
No functional changes intended:
- Replace SfxObjectShell::GetSignPDFCertificate() and
SfxObjectShell::ResetSignPDFCertificate() with
SfxViewShell::SetSignPDFCertificate() and
SfxViewShell::GetSignPDFCertificate(), because information about shape
selection belongs to the view.
- Change svx::SignatureLineHelper::setShapeCertificate() to use
SfxViewShell::SetSignPDFCertificate() to avoid duplication.
- Change GetSignatureLineShape() in xmlsecurity/ to use
SfxViewShell::GetSignPDFCertificate(), again to avoid duplication.
With this, all setters/getters of the inserted signature line go via
SfxViewShell and the amount of getCurrentSelection() calls on the model
is reduced.
Change-Id: I021bc41262b2a16d1014fbf1431a0eb6e1e86c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180355
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This change fixes a bug causing borders to fail to render for merged
cells in RTL spreadsheets.
The root cause for this bug was framelinkarray utility code using the
top-left cell as the source for border styles of merged cells. This use
was correct for LTR spreadsheets. However, this framelinkarray data is
mirrored for RTL documents. After mirroring, the correct cell containing
border styles is the top-right one.
This change also reverts and reimplements a prior fix for tdf#135843
(commit 586a0f149f), which violated the
framelinkarray contract that edge styles for merged cells must be added
to the top-left underlying cell of a merged cell.
Change-Id: I27eec416d54f9f99cd5df1151a12c758f350c789
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180256
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Have electronic signing configured in the LOK client, try to insert a
signature line, you'll get a certificate picker, while we don't have a
cert during esign.
What's in fact needed for creating the signature line is just a name
(previously extracted from the certificate), we can survive the lack of
actual certificate.
Fix the problem by adding a new External parameter to
.uno:InsertSignatureLine to hint that the certificate chooser should not
be opened, instead the editor name (used for comments already) should be
used. Add a new CertificateOrName in svl/ and use that in all places
where previously we wanted a certificate but in fact it's enough to have
a certificate or a name to create the signature line.
The name on the signature line is just visual feedback, the actual name
on the crypto signature is still not based on untrusted used input.
Change-Id: Ib7008112a8e28a9e7d9649745e6021dd6b6b9c39
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180193
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Insert a signature line in LOK mode when PEM certs are configured,
moving the just inserted shape works (even in the read-only PDF view),
but you can't resize the shape.
This is because moving goes via .uno:TransformDialog, while resizing
uses .uno:MoveShapeHandle.
Fix this similar to moving, by allowing the operation when the shape is
a just inserted signature line. Allowing the command in read-only mode
is meant to be safe, since the command implementation again checks if
the resize is allowed, and there we allow this only for signature lines.
Also expose the "is signature line" info on the LOK API, so it can show
the graphic selection handles conditionally (only when resize will be
allowed).
Change-Id: Ie85aa1211564758dc24ff83b4241de78a8e69ffc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180065
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
I think I managed to disable this when I converted it to
use the shared plugin infrastructure.
So fix that, and then make it much smarter to avoid various
false positives.
Change-Id: I0a4657cff3b40a00434924bf764d024dbfd7d5b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176646
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Vissarion Fisikopoulos