| Age | Commit message (Collapse) | Author |
|---|
|
Goal is to minimize dependencies on oox classes. For that pupose
I redesigned the Diagram class to work without remembering
an oox::Shape at all. For reLayout, a new temporary one is created
and used. That was a bit tricky, I needed to find out what
data at the oox::Shape is needed to sucessfully do that with
the not-originally-imported one.
Another necessary change was to move the DiagramFontHeights
adapting mechanism away from oox::Shape, too. It fits better
to Diagram class. That way it can also be used for reLayout
and the oox::Shape gets a little bit smaller, too.
This opens the path to move needed Mode-Data Diagam core
claasses to other libs where changing/im/exPorting them will
be possible.
Change-Id: I40bc4b190d2abc797f5c56f9e476d22155d21422
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131004
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Reorganized and streamlined, use IDiagramHelper as main interface
now also for existing code.
Had to adapt oox::Shape && Diagram handling since there the
import gets handled very different. This ensures that a Diagram
is detected at export and that the same happens for now as before
Had to add a detection that resetting the GrabBag is meant to
disable the Diagam functionality. That is very indirect, but
has to stay for compaibility reasons for now
Change-Id: I620b7d61cd84b5f9dd8ae4dc890ebf70ce779cdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130389
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I2fb89bf68d8df2da1b97942d70c386f62f61c64f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130413
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
To allow advanced Diagram/SmartArt support in the future
this is a first step to organize imported SmartArt Data in
a way that will allow to re-layout loaded SmartArts, under
re-usage of the oox::Theme (held available).
It is designed to work without holding available the
original XML snippets defining the imported Diagram in any
way, also for performance reasons. It tries to re-use some
of the already basically added functionality, including
the systematic layouting using the generic layout
algorithm, plus some already available text extraction.
Before being sure that the former state can be completely
replaced this is optoinal and used when
SAL_ENABLE_ADVANCED_SMART_ART is defined. Some new stuff
is already done but e.g. the redefined reLayout method will
not (yet) be triggered. It works and reliably produces a
re-layouted identical version, also preserving
transformations.
Change-Id: I08cfbae04afa663d0589530aae549216d853128d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130171
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I82405059d900b6605075bf5756f3f0fb99e9002e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129451
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I50e8988c320c0068f7adf4a3429d7639df0cbcd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129596
Tested-by: Jenkins
Reviewed-by: Andrea Gelmini <andrea.gelmini@gelma.net>
|
|
Check the XFileDialogSelectedItems is using the expected impl.
after dynamic_casting.
Rename VbaKeyBinding to VbaMacroKeyAndMethodBinding and document
the struct.
Change-Id: Ica4b24fed3013c5efa97a14e98bf9bdc2c74b68d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129320
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Grouped text boxes (WPG) lost their alignment and spacing,
because the bodyPr tag what has the information for this,
processed after the textbox content, and applied to the XShape
which in case of group shape is not ready. To solve this, the
mentioned properties read for the shape member after copied
to the XShape when its ready, and than synced to the textbox.
Regression from commit 121cbc250b36290f0f8c7265fea57256dad69553
"tdf#66039 DOCX: import textboxes (with tables, images etc.) in
group shapes".
Change-Id: Ifb5e8bde58613137441bec2e2b51bc67118dab40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128854
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
E.g. OLE formulas inside them broke document load.
Regression from 121cbc250b36290f0f8c7265fea57256dad69553
"tdf#66039 DOCX: import textboxes (with tables, images etc.)
in group shapes".
Note: now embedded VML OLE is loaded in WPG shapes, thanks to
that the ShapeHandler in oox/ has a stack having the start
token inside for each shape.
Change-Id: I973d78ed88c5c83efffd9629061e2a2c6fdd25e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128627
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
On issue with registering was that the registering happened when
the macro source was in the process to be read into the library,
which is just a bit too early, because the macro wasn't found and
not registered.
Another issue was with searching for the macro method (hasMacro),
which doesn't search the same when the module name is known and
when it isn't. This was changed so we just iterate through the
modules and call the same "FindMethod" method without any extra
restrictions.
Change-Id: I811cfcaca58e8dfa8bef6cf983a8aff2b60eba35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129196
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
It missed some occurrences of 0 when only looking into uninstantiated template
code, as Clang doesn't model them with an ImplicitCastExpr, even if the target
is known to be a (dependent) pointer type.
Looking into all template instantiations of course carries the risk that a given
use of 0 is meant to be interpreted as a pointer in some and as an integer in
other instantiations. But the only case where that happened in the current code
base is RegistryValueList::getElement (include/registry/registry.hxx), where {}
is arguably a better choice anyway. (And which would presumably also hold for
any future such cases.)
Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Expands previous idea from a9c5c0d814a266096483572b84c72875ef8efd77
(tdf#133037 OOXML shape import: camera rotation along Z)
and uses it also for shapes that have a true bUseRotationTransform flag
Also fixes same Z rotation exporting twice from InteropGrabBag to
both spPr and textBody causing text overrotating on roundtrip.
Change-Id: If0f192af029ca86b932a63613f961be1f5003c5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127880
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In this part, oox module has been modified in order to prepare
for WPG handling during OOXML import. Note: Wpg is the drawingML
equivalent of v:group, supporting text boxes in the group.
1) Added new parameter for WpgContext to support nested
Wpg shapes, and WPS enabled for the WPG member shapes.
2) A bug has fixed, where group member line shape and
connector shapes have wrong positions before in the group.
3) Unit tests had to be modified, and 3 of them disabled
temporarily due to missing Writerfilter implementation (what
will be the next commit)
Now group shapes can have textboxes and the text is imported
for that, but complex content is still missing (this will be
fixed in writerfilter by the next commit).
Known issue: WPG shapes with textboxes in floating table
have issues during import at floating table conversion, so until
this is not fixed this function is disabled for shapes in tables
(will be fixed a follow-up commit later).
Follow-up to commit 19394a924fdc486202ca27e318385287eb0df26f
"tdf#143574 sw: textboxes in group shapes -- part 4".
Change-Id: I71032187697807087bd8f27f7c3a7b052e174bd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124964
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
See tdf#42949 for motivation
Change-Id: I44e4e3a88067c1c29ce9d563b22741e984b43576
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126964
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Map it to (the UNO API of) GraphicDrawMode::Watermark, similar to what
the binary import does in SvxMSDffManager::ImportGraphic() and how the
drawingML import does it in
oox::drawingml::GraphicProperties::pushToPropMap().
On export, the drawingML export is used, and that already maps
GraphicDrawMode::Watermark to <a:lum bright="70000" contrast="-70000">.
Change-Id: I33986a03bf3d3863da5c5b1f0a2e0da0fa595c9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126908
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
to avoid bad overlapping lines.
PPTX does not have the option "At least", so line spacing
with this setting is converted to fixed line spacing.
Improve this workaround to use single line spacing, if the
"At least" value is lower than the size of the characters,
like "At least" is handled by Impress.
Change-Id: I29b41225d48fd9a447e7f6ef3a8a7cc7ba9ef354
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125553
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
As a start, do this only in case there are no effects used. If there is
no theme color or there are effects, fall back to the old code.
Also move parseExportStream() from SdModelTestBaseXML up to MacrosTest,
so oox/ test code can use it as well.
Change-Id: Ia76581dcef110341f6c3e60f22c34818ed0dcabc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126215
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ia19d247f3cf439405c05a53c4cf2c9d0e7344560
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125811
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This was already handled in oox/ at import-time: this adds it to the doc
model, including UNO API and PPTX import.
This is a dependency PPTX export and UI, and also the last transform
which is easy to generate from the PowerPoint UI and we didn't import to
the doc model.
Change-Id: Ica4e738d8dc8e0409160ceab941a82f2475ddc68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125749
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This was already handled in oox/ at import-time: this adds it to the doc
model, including UNO API and PPTX import.
This is a dependency PPTX export and UI.
Change-Id: I5d875b53d715beb10c13ef616d06cf958d43f70f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125684
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This was already handled by converting them to raw colors at import
time. This commit imports the color scheme contents (the 12 colors) into
the doc model.
This is a dependency to export them back to PPTX and to be able to
update these colors on the UI by picking a different theme.
Change-Id: I177de4f15d5f0e628669998d1cda7db24220b2eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125651
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
We had doc model for this, but the UNO API and the PPTX import was
missing.
Change-Id: I199e9cc235a783d91700ce74f17d442f41d3c3f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125532
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
initial import work for color sets.
Themes (which we get the color schemes from) in MSO can
be different for each master - will need to support that too.
[ Miklos: actually added that per-master-page support. ]
(cherry picked from commit 3b21d166f585dcdf8d576d166aeff3cfd4694aab,
from the feature/themesupport2 branch)
Change-Id: Ia06d2645018e6bfa70817bbddba2374641ae13dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125477
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
[ Miklos: althought the PowerPoint UI doesn't seem to have a way to
generate this markup. ]
(cherry picked from commit de40c940c3a94588d44a3d1f6d8cd4191cca4f73)
Change-Id: Ibf98ba335b10859e4d6d702263f09e6ba2033bff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125426
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
[ Miklos: i.e. index could be a theme index or an index into a color
set, this one is the later case. ]
(cherry picked from commit aef22c3bbf1b4bb8ab9ba2bccb7005e0d0c75cb3,
from the feature/themesupport2 branch)
Conflicts:
oox/source/drawingml/shape.cxx
oox/source/drawingml/shape3dproperties.cxx
Change-Id: I495e4b39975f1483607972ccbcc9348021710519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125414
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
[ Miklos: this only handles colors as-is, without any effects. ]
(cherry picked from commit ec68ca0b5fb6773f42600f6a5825b4794cdb0990,
from the feature/themesupport2 branch)
Change-Id: I89890cf7ba6ec758698011752b63d7a60872bef2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125404
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...after e6968f0485cfb2f6c941d11c438386e14a47095d "PPTX import: fix handling of
theme overrides in the chart import" introduced a use of std::make_shared<Theme>
Change-Id: I5f6384b81e02034b6b2fdf3a3bad0148de4eb584
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125228
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: I3010494a750eee70ffe9c24c10417d0a3730dbd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125120
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iea6f7f96685e332407288af7ada36527acc83a8e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125119
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3f595585b78c9e5ac32d9fc345c55a4eb14101c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124824
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I85ca453f3add5ac5b59dc6f1ccb2cdb55f0a463c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124333
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I987c56feab147cdbeb4ad58bd5ebb23dce6dbbca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124215
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
like table layout of MSO does, e.g. 20 pt to 19.5 pt.
Changing table row height is only for interoperability.
To avoid of regressions, apply this workaround only for
documents created in MSO.
Note: likely this is an old adjustment for low-resolution
monitors, where 0.75 is the factor between 96 ppi of Windows
resolution and (originally) 72 ppi of monitor resolutions.
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: Ie1e2c781d21174a877b18cd3250eb445222bd1c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122428
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I4c0002e72703eded435bfe4985f5b0121bf8524b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122843
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I02b4352f02fe32f40c4fe0ab198d8ac094381c7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122491
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I88831f290e1923db6fb5a733746bfa3bc7fbc7e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122148
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Before this fix, date categories imported in oox's DataSourceContext were
stored as formatted strings according to number format code in <c:formatCode>
under the <c:cat> tree. As a result chart2 could not recognize them
as dates. This causes problems like:
* The axis that is linked to date categories cannot use the
scaling/range-selection(min/max)/increments specs mentioned as axis
properties. This results in distorted/unreadable chart renders w.r.t
the date axis.
* No re-formatting is attempted as per the number format provided for axis.
This patch introduces a role qualifer argument to the XDataProvider
interface method createDataSequenceByValueArray to support categories of
date type via this method.
When exporting to oox, write date categories and format code under
<c:cat>
<c:numRef>
<c:numCache>
This patch also fixes some discrepancies in date axis interval
computation (auto mode) found by already existing unit tests.
Change-Id: Ibc53b0a56fdddba80ba452d5567ce98d80460ea7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121525
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
tdf#143127: Add officeRel namespace to XML_userShapes
to fix invalid file error in MSO.
tdf#143130: Add mbUserShapes variable to ShapeExport class
to fix export of embedded shapes of charts in DOCX.
Change-Id: I10c1dbf905af96d6a63a9243514b32a6440e63f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121035
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When <c15:showDataLabelsRange> boolean flag is present, the imported
label texts are added as the first text field in oox data label model.
The cell-range associated is also preserved. The export part preserves
the how labels were store originally in <c15:datalabelsRange>.
However in order to make the custom labels reflect the contents of the
cells in the associated cell-range, more work needs to be done. For this
the labels present in <c15:datalabelsRange> needs to be made available
as a data-sequence with a new "role" like "point-labels" in
XInternalDataProvider implementation and and make the label renderer
read this data source rather than consulting the custom label fields
property which is static after import.
Change-Id: Ibc7045fa5ea209d463680c96efb49a06662d2500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The points in file source might have units. Decode was missing.
maWidth and maHeight are used in ShapeBase::convertAndInsert(), and
moCoordSize is used in PolyLineShape::implConvertAndInsert(). So
ShapeContext needs to provide both in case of importing a polyline.
That was missing.
Word writes the size into the coordsize attribute of the v:polyline
element. But from VML specification it need not exist, but bounding
rectangle of points has to be used. That is added too.
Unclosed polyline cannot be filled in LO and ODF, a fill is only
possible for a closed polygon. LO defines a sequence of points as
being closed, if first point == last point. The import is adapted
to that behavior.
Word allows an unclosed polyline to have filling. That cannot be
represented with a simple PolyPolygonShape but would need a
CustomShape. Because the user cannot yet edit points in a CustomShape
but can do that in a PolyPolygonShape, the v:polyline element is
not converted to a CustomShape on import and not to DML on export.
LO would first need an UI for editing points of a CustomShape.
Change-Id: I23d08fda2005f8b36488e1d9ba32e565d8a0f803
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121042
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
It will use compile-type constants to clamp input value, instead of
clamping more expensive pre-sanitized output value.
Change-Id: If78f8b1b4c99bd2f16b1d8a71872e89a0dddd8d0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120874
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic177ca6042cbedc4cbe70e1f35ac3d85c1fa2f7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120840
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I786096b989daa6004a6527aafbe825b6f0a22d90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120710
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The export had used the bound rectangle of PolyPolygonBezier. But that
contains control points. Use API position and size instead.
I have not incorporated the changes into existing WritePolyPolygon,
but have made an own version for SdrPathObj, because I find it easier
to read and maintain, than having a lot of case distinctions depending
on the shape type.
Change-Id: I2e646c4f5fa37174c4979855212ca72f2dfa447e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120407
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
(for std::unique_ptr, with recent libstdc++ 12 trunk)
Change-Id: I61b7823dd740ea7cdfe0d7403a50ac73b24d1c4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120229
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ied436c4a619985f27e5854369d319d76c05890d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120028
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
|
See Slide Show->Slide Show Settings...->Change slides manually,
which is disabled by default. Now <p:showPr useTimings="false">
is imported correctly, i.e. with enabled "Change slides manually".
Note: it seems, com::sun::star::presentation::IsAutomatic
UNO attribute has got a bad name and documentation: if it's
value is TRUE, "Change slides manually" is enabled, and vice versa.
Check with the following Basic code:
' show presentation-level automatic transition (IsAutomatic = False)
print ThisComponent.getPresentation().IsAutomatic
' show slide-level automatic transition (Change = 1)
Dim oDrawPages as Object, oDrawPage as Object
oDrawPages = ThisComponent.getDrawPages()
oDrawPage = oDrawPages.getByIndex(0)
print oDrawPage.Change
Change-Id: Ie4a687a29077cad89f11e77b856c28a1fe09376b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119321
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
* Support hyperlinks on Shapes in Writer
* Add menu items
* Add context menu items
* ODF import/export + test
* OOXML import/export + test
Change-Id: I7269064c4cabd16fdb8259a48429c508184d3ccf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119164
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
|
