Qt plugin automatically orders buttons for each platform based on
the button's role, which we derive from the Gtk .ui file's
action-widget response code. But to do that conversion from response
code to Qt button role, we need a standard response.
Without a standard response, the button has no role, and gets ordered
to the right of OK/Cancel buttons on Mac. With the correct role, it
is correctly placed far-left along with the Help button.
Change-Id: I16d3126d4999649e7aa6e72ec5e7b1a25f48c2a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210223
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
As Eike indicated in https://bugs.documentfoundation.org/show_bug.cgi?id=146404#c4
COLOR format codes are preserved in ods/fods format.
The pb was the missing map back.
Indeed, we had the mapping for [COLOR<something>] => Color value (eg: "ffaa16")
but not the reverse mapping Color value => [COLOR<something>]
Eike had provided the right code pointer in xmlnumfi.cxx.
First, I thought using PaletteManager but this one is in svx and svx shouldn't be used in xmloff
(dependency pb).
Then I used ChatGpt (GPT-5.6 Luna) and it pointed the right process.
It just consisted to use a similar callback system (DECL_LINK, IMPL_LINK, LINK) of GetUserDefinedColor.
In addition, by testing all this, I noticed that maList in XColorList::GetIndexOfColor was empty.
So I added the Load call in case mbListDirty is true.
Change-Id: I0ef6b5901f2e4c757e88994412dbf79a13100ffd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210518
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
By now, almost all a11y implementations implement both,
the XAccessible and XAccessibleContext interfaces themselves,
and they do so via the OAccessible base class.
One remaining case that only implements the XAccessible interface
directly is UnoControl. XAccessible::getAccessibleContext
is used from within AccessibleControlShape::Init to get the
accessible context. That accessible context however
is an OAccessible and implements both, the XAccessible
and XAccessibleContext interfaces again.
Stop requiring that UnoControl implements XAccessible
by instead adding a dedicated new method UnoControl::getAccessible
to directly get the OAccessible without relying on
the XAccessible interface being implemented by UnoControl.
In AccessibleControlShape::Init, cast to UnoControl
instead of querying for the XAccessible interface
and call the new method directly.
Stop implementing the XAccessible interface in
UnoControl as it is no longer needed now.
This aligns the UnoControl a11y logic more with how
a11y is implemented elsewhere across the code base.
Sample steps to trigger the modified code
when using the gtk3 vcl plugin on Linux:
* start the Orca screen reader
* start Writer
* insert a few push button controls using
"Form" -> "Push Button" and then clicking into
the document and dragging to insert
* disable design mode using "Form" -> "Design Mode"
* focus one of the controls by clicking on it
* press the Tab key to move focus between the controls
No differences in behavior were observed when
doing this with or without this change in place.
Side note: Announcement of the controls when they
receive focus didn't work (reliably) when opening an
existing document containing form controls instead of
inserting them into a new one, but that is preexisting
and unrelated to this commit.
Also adjust test AccessibleFixedTextTest::testFixedText
of the CppunitTest_toolkit_a11y test suite
accordingly that was assuming that it can
query the XAccessible interface directly
from the UNO control.
Change-Id: I8cc3902a8de725eda3d810920f1da2d390c06f73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210464
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
ODF has no name for this chart type, so the file says two things at once, the
way a histogram already does: chart:class names the scatter chart, which is the
nearest a reader that knows nothing of correlation circles can make of it, and
coext:class beside it names the type itself. A reader that knows the coext name
gets the chart back as it was saved.
The series need no new shape in the file. The feature column is the range of
the series and the two dimension columns are a domain each, which is where a
bubble chart already keeps its x and y values, so both the reading and the
writing of them follows the bubble path rather than a new logic.
The schema the tests validate against lists the values coext:class may take, so
the new one is added there beside the histogram.
The test document is one block of five columns: three features and then the two
dimensions, the shape the wizard asks for. The test checks after a round trip
that the chart type came back, that the file carries both class names, and that
every series still holds its feature column beside the two dimension columns.
Change-Id: Iac73ff357c7490b4f38a4390c63948cf148d8585
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8106
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 4e59ea1c83e61b8dc2647f9a915884f9d461165d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210498
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
as part of the process of merging the Outliner code into the normal EditEngine paths.
So instead of keeping a bunch of information "on the side" and then having to merge information
from multiple sources, it all lives where it logically belongs.
Also take the chance to rename the depth/getdepth/setdepth
fields and methods to NumberingDepth, which makes the purpose
more obvious.
Change-Id: I314673ee1b9efa14f178ac34a122995a554cd788
Signed-off-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10551
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 284bbe0af12b96844976f30bb35ade3a327ea76d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210503
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Pass the more concrete OAccessible instead of a reference
to the abstract XComponent UNO interface.
Change-Id: Idcbf5c1eb09cc1380a85410b76d8b1e2df022b6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210460
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Switch from using a weak reference (css::uno::WeakReferenceHelper)
to the abstract XAccessibleContext UNO interface to a weak
reference (unotools::WeakReference) of the more concrete
OAccessible class in UnoControl.
This makes clear that the accessible is always an OAccessible
subclass and allows dropping some UNO-querying for the
wanted UNO interfaces.
Change-Id: Ib1ea66c83da9bbf76891c492d84aa57c396f2f44
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210459
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
basctl/source/basicide/baside3.cxx actually needs the
include and now no longer gets it transitively, so
add the include there directly.
Change-Id: Iff9eca9f7a8c9585522a783f63f77a5ab1555333
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210409
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
AccessibleBrowseBoxTableBase does not implement the
XServiceInfo interface. The corresponding comment/doc
seems to have been wrong ever since
commit e7a5ee68de
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date: Wed Jun 27 14:18:49 2007 +0000
INTEGRATION: CWS a11ysep (1.1.2); FILE ADDED
2005/09/28 11:39:30 fs 1.1.2.2: manual resync (files have been moved herein from another location): licence change
2005/03/07 08:27:24 fs 1.1.2.1: #i44293# moved implementations herein from svtools module
, so drop it.
Presumably, it was copy pasted from elsewhere, as
the same comments were seen elsewhere (where XServiceInfo
was actually implemented, however) until it was cleaned up
recently, e.g. in
Change-Id: Iff25d87496bd35c2d5894ee21a104ede0dbd9e13
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Wed Sep 2 10:06:04 2026 +0200
a11y: Stop declaring AccessibleContext support in AccessibleBrowseBoxBase
Change-Id: I4ab8bf5daee69490288a83cdbb3d6400d7bbafaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210408
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
Drop the unpublished service
"com.sun.star.awt.AccessibleWindow"
because it's unused. (The IDL file only documents some
internal implementation details of the a11y classes
implementing the service.)
Change-Id: I958aeb6c6baaa48e2e02ab170b17db5c3510379b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210406
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The com.sun.star.accessibility.AccessibleContext UNO service
is unnecessary and not really used for implementing a11y support,
apart from some a11y implementations declaring support for it.
What is relevant is the com.sun.star.accessibility.XAccessibleContext
interface instead.
Stop declaring support for the com.sun.star.accessibility.AccessibleContext
service in AccessibleContextBase and drop related
XServiceInfo::getImplementationName overrides in subclasses,
in preparation of dropping the service altogether in an upcoming
commit.
AccessibleDrawDocumentView currently still declares support
for the "com.sun.star.drawing.AccessibleDrawDocumentView"
service, so let it implement XServiceInfo directly, now that
it no longer inherits that from the AccessibleContextBase
base class.
Change-Id: Ie927cd98f9e1c8eb5a80bfaab5cb1dacb64dc238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210403
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Jenkins
The com.sun.star.accessibility.AccessibleContext UNO service
is unnecessary and not really used for implementing a11y support,
apart from some a11y implementations declaring support for it.
What is relevant is the com.sun.star.accessibility.XAccessibleContext
interface instead.
Stop declaring support for the com.sun.star.accessibility.AccessibleContext
service in AccessibleBrowseBoxBase (and drop related
XServiceInfo::getImplementationName overrides in subclasses),
in preparation of dropping the service altogether in an upcoming
commit.
Change-Id: Id6072c6ca066c9eda8e682ccfd6240e74d7307ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210401
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A slide's picture placeholder can hold text the author typed instead of an
image, which PowerPoint displays. Impress dropped that text on import and
wrote nothing at all for such a shape on save. To reproduce, type into a
picture placeholder in PowerPoint, save, open the file and save it again:
the text is gone from the shape, and the shape from the file.
What a placeholder is now lives in the page's presentation object list, and
what represents it follows what it holds: a graphic object for a picture, an
SdrObjKind::OutlineText object while it holds text, the placeholder itself
while it holds nothing. It changes over when a file states such text, when
that text is deleted again and the prompt comes back, and when an image is
put in. Text arriving another way, through the API, is caught by the new
SdrPage::onEmptyPresObjFilled and switched at the next idle, so that route
needs a spinning scheduler; what a save writes is right either way. An object
in text edit is left to that edit, which is where it changes over: the idle
pass walks every page, so it asks each object rather than trusting the one
that asked for the pass - in a shared document another view holds it. That
switch is the model's own and covered by no undo step - it answers for a
document the API changed, not for anything the user did.
What the file says about the shape travels with it both ways, the graphic
items included, so an outline a picture placeholder is clipped to is still
there when a picture arrives. It is not written while the placeholder holds
text: the file says text box, and a text box states no geometry to clip a
picture to.
PPTX writes it as the placeholder it is, with the text it holds. ODF states
the class of what represents it, so the placeholder's own class travels
beside it as coext:placeholder-class, and a reader that ignores the
extension sees an outline placeholder with the text.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I0f3353115e56d63a4158ebaeb5689689499894bb
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9441
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 7921401ae48188568e1016db00bd90256d666a6a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210329
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The XLSX export wrote the label as a bare <font> element, so a checkbox
came back with the control default font at 10pt and adjacent labels
overlapped. The label's font name, size and colour, its bold, italic,
underline and strikeout, and its horizontal and vertical alignment are
now written out.
The underline stopped reaching the export altogether when the control
property list started asking for "FontLineStyle", which no control model
has: commit 3187193a61 (tools: rename
FontUnderline to FontLineStyle, 2016-01-29) renamed the VCL enum and
took the UNO property name string along. The same rename hit
sw/source/filter/html/htmlforw.cxx, which is not handled here and needs
a separate fix. A double underline also needs the "fontN" class on the
underline element, which the import compared with a literal "font4",
introduced with no explanation given in commit
04c272eb83 (dr77: #i114128# import legacy
drawing controls, 2010-08-26). N is the index into the workbook font
table, and is treated as one now.
Excel keeps the label font in the VML shape, in the DrawingML run
properties and in a workbook font record, and builds its model from the
DrawingML, while we read the VML and the record it names. Both are
written here so that the two applications show the same document. TODO:
read the label font from the DrawingML run properties, as Excel does.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I87259d25a68829f6c1a78179f8e3aa7811a5688f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9927
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit ca86699205743f2709f3cd5d412a8a3f0d3fba38)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210334
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Commit 67ba6ccd5a (tdf#140912, tdf#159219:
fix import of graphic placeholder with custom prompt, 2024-01-17) left
the prompt out of ODF for want of a representation, so a reload replaced
an authored one with our own localized default. It now travels as a
coext:placeholder-prompt attribute beside presentation:placeholder, on
draw:frame and draw:page-thumbnail, written when saving with extensions
and added to the extended schema so the round trip validates. It is
also listed in the Collabora ODF extensions notes.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I12b51ff2bc103e5c26e94558802064919c7289dd
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9070
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 6b1b6331ada0cc948e880eb83db5506f8bf1aa9c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210297
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The # postfix operator was parsed at the same level as the percent
sign, which is looser than the prefix operators. Because of this
=@A1# compiled to the spill range of an implicit intersection and
=-A1# to the spill range of a negated value. Neither of those means
anything, and OOXML writes the # around the reference alone in both
cases.
The # is now parsed right after the factor it follows, tighter than any
operator that can come before it. A whole range reference goes inside,
because the lexer reads A1:A3 as a single reference. The percent sign
stays above the reference operators, so =A1%# leaves the # with nothing
to bind to and doesn't parse, and the export drops such a # (OOXML has
no spelling for it either).
A blank between two operands is only the intersection operator if both
sides yield a reference. The # does, so the checks that keep the blank
alive and that keep the operator once the operands are known had to be
told about it.
The interpreter passes the spill range on as a matrix that carries the
range it was read from. The intersection, range and union operators
only took references and refused that, so PopReferenceOperand now
hands them the carried range as a double reference.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I1a587bf291ff639b326a366b8efc332106eb5fd3
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10156
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit c589c34aaec00d60fc47f1933762b105f9d22de3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210293
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* Makes the title show as "Slide Properties" instead of "Page
Properties".
* Makes the label for the resize all slides checkbox show as "Resize all
slides" instead of "Resize all pages"
Change-Id: Idda0bdf6ef6215696ae4189549f62c05ef0076c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209996
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
OOXML writes @ and # as calls and a reference union as a parenthesised
list, so for each of them we need to know how far the sub-expression
under it reaches. CreateStringFromTokenArray worked that out from the
text it had already written. The problem with this is that every pair
it spliced in shifted all the offsets that were still waiting behind
it, so it kept breaking.
Instead of patching the text, OOXMLRewriter builds a second
token array in the shape OOXML spells out and the writer walks that as
it stands. The call names and the parentheses are ordinary tokens, so
there is nothing to splice and no offsets to keep track of. It is the
same trick RewriteMissing already plays a few lines further up, and it
means the input and the output can be looked at side by side.
The # changes place, from behind its operand to a call in front of it,
so it gets an opcode of its own. _xlfn.ANCHORARRAY spells ocAnchorArray
now, and ocSpill keeps the native postfix spelling with no OOXML one at
all, so the postfix form cannot end up in a file by accident. The
import already rewrote the call back into the postfix operator and now
recognises it by opcode instead of by position. The @ stays
ocSingleValue, it is already in front of its operand so only the
parentheses are new.
The OFFSET() literal argument is swapped for the reference error in
the same pass, instead of the writing loop jumping over tokens.
A unit test drives the rewrite on its own: token array in, token array
out, one case per shape. The shapes that end up with nothing to wrap
are in there too - a lone @, one with a missing argument, and text that
never parsed - since those are the ones where dropping a token is the
only change.
Also drop the dead "@" and "#" rows from the OOXML symbol table, the
rows above them already have _xlfn.SINGLE and _xlfn.ANCHORARRAY.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I63944fb85b5c4388f304f7d94afd0b4f347d7782
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10155
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 4feac84950f5b524d99e277481de50f7b45a8d2f)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210292
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Move QueryDialog from cui to a public svtools header.
This is in preparation of using the class directly
and dropping the AbstractQueryDialog abstraction
altogether.
The dialog can e.g. be triggered like this:
* start Writer
* Ctrl+Shift+S for "Save As"
* select "Text (.txt)" for the file type
* press OK
(Resetting the profile ensures the dialog gets shown
in case the "Don't show again" checkbox has been ticked
previously.)
Change-Id: I57bdade32c21c7ab40c5a4c90bd86e8dea5d2fad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210136
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
A placeholder clipped to an outline carries it as custom geometry, which an
image shape has nowhere to keep, so the outline was dropped on load and the save
wrote a plain rectangle over it. Read it into GraphicClipPolyPolygon, and write
it back from there.
The two directions are not equally capable. Import reads paths of literal
coordinates: one driven by guides or formulas, and an arc, both need the
custom-shape machinery. A quadratic curve is read, converting exactly to the
cubic the model keeps. A path that states no w and h is not read either - such
coordinates are absolute EMU rather than a space to scale from, and no file
authored that way turned up to check the reading against. Export writes whatever
polygon the model holds, so that direction loses nothing - a geometry the import
gave up on was never stored. A curve that closes a contour states no end point
of its own, and the point the contour started from answers for it.
A path that states fill="none" states that it paints nothing, and PowerPoint
leaves it out of the clip: a picture clipped by two paths shows through the
plain one and not through the nofill one, while the same file with that one
attribute removed - or with stroke="0" in its place - shows through both. So
such a path is read past, while the shading variants and stroke="0" are not:
those say how an area is painted, not whether there is one.
Several paths become one polygon by area, not by concatenation: the contours of
one path are filled by the even-odd rule, so two of them overlapping leave a
hole, while paths are filled one after another and the shape covers what they
cover together. Concatenating them instead cut a hole wherever two paths
overlap, which the file does not describe and PowerPoint does not draw.
A shape's own custom geometry now replaces the one it inherits, the way a preset
geometry already did. Saving states the outline on the slide as well as on its
layout, so reading that back gave the slide placeholder its own geometry beside
the inherited one, and two geometries at once are not one this reads - the
placeholder came back unclipped while PowerPoint showed the same file correctly.
The outline reaches the drawing the commit before this one added, so a
placeholder read from a file shows what sits behind the parts it does not cover.
It survives a round-trip through ODF as well, where the property already travels
as coext:graphic-clip-poly, with nothing to carry until now.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I87bd21e68bcea648c8c9151b6af5439578f1c2cf
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9303
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 04bbb74a24bad4ae54f257b6b028f3fd48955272)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210123
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@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>
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
A slide layout is imported as a master page, and the shown text was only set
off a master, so an authored prompt was stored but never displayed or written
back; the export emitted Impress's own localized resource instead. Set it on
a master too, and accept the graphic kind in RestoreDefaultText, which keeps
the object an empty presentation object. Now that the two are
distinguishable, a placeholder that authored no prompt writes no text - its
text body keeps the properties a reader needs, and holds an empty paragraph.
A slide's own placeholder asks its master for that prompt before falling back
to the resource string, so the two no longer disagree about what is really
one placeholder.
This is what degraded in commit 73f1e76b1760d4e936aa22627623c922dcda964b
(cool#15754: Fix PPTX round-trip of empty picture placeholders, 2026-05-21):
mapping a layout <p:ph type="pic"/> to a real presentation service is what
made it reach that text reset, where the previous OutlinerShape mapping had
kept the authored prompt.
Implemented a TODO from commit 67ba6ccd5a
(tdf#140912, tdf#159219: fix import of graphic placeholder with custom
prompt, 2024-01-17). That commit deferred this because marking the object
empty after setting the text crashed the PPTX export; going through
RestoreDefaultText, which does exactly that, no longer does. Its other
objection stands: ODF stores no placeholder prompt, so a save to ODP still
drops it.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I1b6f3e38cb24ac737d3de6258559090596817bad
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9046
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b41a780d139ec6ca5a5514db972ccf0e50058dfc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210008
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Caolán McNamara