Using &* can be problematic if the pointer is null. In this case the
pointer is explicitly checked for null first so it doesn’t matter, but
using shared_ptr::get() is probably easier to understand anyway. This
also paves the way for a later compiler plugin to check for this.
Change-Id: If087962548c6a7e06311eab9175f5108b50ca549
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211752
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
When an empty PPTX presentation was opened and saved,
its Title and Content layout/master slide lost its
autofit setting.
Original slide master had <a:normAutofit/> element
in its placeholders, which turned into <a:noAutofit/>.
This happened, because on import the inherited property
got overwritten by the default no autofit.
Change-Id: If9842d4c53eb283b9497b46198aaea4911413bc9
Signed-off-by: Aron Budea <aron.budea@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/14276
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit afe4932986453513ea1a50b1143de3827f39c0ed)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211865
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
PowerPoint writes the same startAt on every paragraph of a list, and
since tdf#168406 each startAt restarted it: 2. 2. 2. instead of 2. 3. 4.
Restart only when a list begins at that level or its numbering type or
startAt changes, a missing startAt being startAt="1". Paragraphs without
a bullet of their own, also without a:pPr, take it from a:lstStyle. Don't
set the restart flag in a:lstStyle itself: every paragraph inherits it.
An unnumbered paragraph ends the lists at its level and deeper.
Change-Id: I26720a6ba54a8050cfb6e0ba892096039c391c36
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211632
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
An equation's size lives in the w:sz of its math runs. The import ignored it,
so every equation came in at the 12pt default of the formula editor, and a file
holding equations at three sizes showed all three the same. An equation whose
runs name no size takes the size of the text around it, which the styles and
the document defaults hold.
The export wrote no size at all. It now puts the size on every math run, and in
the control properties of each object, which is where the fraction bar, the
radical sign and the brackets take theirs from. The size travels in the w
namespace, so it goes out for a DOCX only, the way the color of a formula
already does.
Every formula now carries a size of its own on the way out, including one
written in ODF. Such a formula used to leave the size open and took whatever
the text around it had in the reading application. It now keeps the size it is
drawn at here, so both applications show it the same.
Setting the base size means giving each of the fonts that same size. The font
size dialog, the BaseFontHeight property of the model and this import each did
that on their own, so they now share SmFormat::SetBaseSizeAndFonts. The
property used to put the sizes in a copy that a later merge step reads only for
a font the same call has named, so a lone BaseFontHeight left the fonts alone.
Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com>
Change-Id: I18b6c5814a57d8ccb8be5b7bdd357ce76cea024d
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13297
Reviewed-by: Balázs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 582e3fdb6496d9f511dfefc1f716b4ead6cc3797)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211600
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Regression after commit b41a780d139ec6ca5a5514db972ccf0e50058dfc (tdf#166401:
support custom placeholder prompt text, 2026-08-17), where a placeholder that
authored no prompt stopped writing text and got a bare <a:p/> instead.
On a slide an empty presentation object reports no text through UNO anyway, so
the paragraph the export wrote for such a placeholder never had a run. It
carried the properties, and those are the formatting. In PowerPoint 2016 the
original title showed white at 22pt, indented 56.5pt; the round-tripped one
showed bold black at 17pt, indented 18pt.
Write the paragraph the way a shape with no text already does: the paragraph
properties, the run properties in endParaRPr, and no run. The prompt still
stays out of the file. That branch of DrawingML::WriteText is now a method of
its own, called from both places.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I034a4e14f388c90872069d32b303c6c143c1814c
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10768
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit e2859f5b23f53281d80cbad4c56db1764aaf1406)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211538
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A PPTX shape keeps the fit the file was saved with until its text is
edited, and after that it is fitted by our own rules.
The fontScale and lnSpcReduction of a normAutofit never reached the
shape, for three reasons.
Import passed fractions to the TextFitToSizeFontScale and
TextFitToSizeSpacingScale properties, which are percentages.
A missing lnSpcReduction was read as 100000, a full reduction,
instead of 0.
When both properties were set in one setPropertyValues call along
with TextFitToSize, the collected fit item was applied last and
overwrote the scales.
Change-Id: I6b7fcfb6a1822f289f18b8ce77e78526a80f8944
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/13539
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit c6938c35aa527883e2fd867f36e22c396601d376)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211506
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A hyperlink in Impress or Draw can carry a name, the Hyperlink
dialog's Name field: the description a screen reader announces, and
what PDF export writes as the link annotation's Contents. Saving the
document and loading it again lost it, and a tooltip carried by a
PPTX never arrived at all, so the link fell back to describing itself
by its own visible text.
Commit 8bf8873f30 (tdf#161583
drawinglayer,editeng,svx,sd: add "Name" to SvxURLField ...,
2025-03-06) gave SvxURLField the name and wired the export path to
it, but no filter. It is not reachable over UNO either, and both
filters go through UNO, so neither had anywhere to put it.
Give the URL field a Name property, and read and write it in both
filters: office:name in ODF, and the tooltip of a:hlinkClick in
OOXML. On import that tooltip becomes the name rather than
Representation, which TextRun overwrites with the link's text; a
shape's own hyperlink goes through the same import context and is
unchanged. A Draw or Impress hyperlink now survives both round trips,
as a Writer one already did.
Inserting a field into shape text does not reach
SvxUnoTextField::CreateFieldData: SvxUnoTextBase builds the stored
field with SvxFieldData::Create, which needs the name too, or it is
dropped again on the way in.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I43d44d55ab460547bbed8acd04d8938a4ee9a615
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12270
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f6218048f057a229eea7f15c198d850ceedd95dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211048
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The table style definition allows for special definitions
for the first and last rows and columns.
That means that the corners are somewhat ambiguous,
so each corner cell can also have a special definition.
However, the corner cell definition only applies
if both that row AND column have a special definition.
Change-Id: Ia5a0ecc2f5cf5ecd0f63e83883a4b693669828e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210612
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
This reverts 27.2 commit 0a03f797bb.
Microsoft Office was unable to open any of the documents we produced
when the thumbnail was in PNG format.
It complains about corrupt content.
Change-Id: I9975374830459007bcf8cbda37ca9e0115eb74a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210471
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
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>
Do not export transient Scott's-rule width as cx:binSize for automatic
histograms. An explicit binSize is imported as fixed-width
binning, so ODS-to-XLSX roundtrip changed FrequencyType from automatic
to fixed width.
Leave cx:binning without binSize or binCount for automatic mode and add
a regression test verifying that FrequencyType remains automatic after
XLSX export and reload.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: Icac1a0a032213dd5a6d5581a72d7453e8147d391
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7985
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 9b4ab82c920ae20bc82f6d68031b1f853dbc65c6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209217
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The layouts came from the slide master's relations, which carry no order:
a relationship id is opaque, and a producer may assign any id to any part.
The map is keyed by that id as a string, which is what made it visible -
a master with ten or more layouts handed over rId1, rId10, rId11, rId2 ...
and the master pages kept that order. Read the master's
<p:sldLayoutIdLst> instead, which is the order it lists them in.
Beside the layout order itself, this decides which master page stands
for the group of equivalent masters: before the fix, a second save
picked the page of a layout with no title, and wrote a slide master
without one.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I6ff62fd190742246a8317f9efae907eeb4a9d8a3
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9194
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 5652d7d68358aae8819ade918c5f5c3cf35f5456)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210143
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A date/time placeholder saved to PPTX held our own display string
"<date/time>" as literal text with no <a:fld> at all, so PowerPoint showed
that string where the original showed a date. DrawingML::GetFieldValue has
no case for the field kind a header/footer date carries, "DateTime", and
with no type name nothing writes the field.
Name the type that leaves the format to the reading application, datetime:
the field carries no format of its own, the page holds it. PowerPoint writes
datetimeFigureOut in such a placeholder, an alias of datetime1 - MS-OI29500
part 1, 21.1.2.2.4 (fld) - which would pin a formatless field to MM/DD/YYYY;
that alias is read on import as the datetime1 it stands for, so a slide's own
date field keeps its format across a round-trip. Every other datetime* type
was understood; the one PowerPoint itself writes was being dropped.
The page's own DateTimeFormat is out of reach where the type is chosen, so
a footer set to show a time is written as a date. PowerPoint has no
per-page format to fall back on either way, and a date beats the literal
string this replaces.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Icbd9ac57ed7b2311d5f6570fffad1cd78e4d6bf7
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9192
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 145a37d84dd3b22023c46b6be8577008f36a48b9)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210141
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
Commit 73f1e76b1760d4e936aa22627623c922dcda964b (cool#15754: Fix PPTX
round-trip of empty picture placeholders, 2026-05-21) covered <p:ph
type="pic"> only. A layout's media placeholder still imported as an
outliner shape, and an empty slide-side one exported as a <p:pic> whose
<a:videoFile> named an empty external relationship - a package the Open
XML SDK validator refuses to open at all.
A media placeholder needs no copy of its own onto the layout, the way a
picture one does: it reaches the file through the page's own shape tree.
Whether it is still waiting for its content is asked of the media, since
nothing marks such a placeholder empty.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I85707ff863a63874c6f493a0f284f25070f26e49
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9188
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 44a05619224ab206dae4ef076269cbb8ce56f43b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210009
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
At the moment, LibreOffice supports creating thumbnails for documents in ODT format, but it does not create thumbnails for documents in OOXML format, even though this format supports this type.
I have transferred all the logic for creating thumbnails from ODT, namely from the functions sfx2/source/doc/objstor.cxx GenerateAndStoreThumbnail WriteThumbnail. Additionally, bEncrypted was added and transferred for encryption.
To study the code and add encryption, as in ODT, Claude Sonnet 5 (Anthropic) was used.
Change-Id: I4d6fe178a5324ee3b43bd8a71f585413c0e4465b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209306
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
The export needs to write pt-elements for content text nodes with the
original modelId to data.xml. However, the shape has not this modelId
but the modelId of the associated pt-element of type=pres. Thus this
element is searched for in getMasterXShapeForPoint(). The error was, to
examine msPresentationLayoutName. That name is created by the author of
the SmartArt template and is arbitrary. And indeed, a name textNode
exists only twice in the over hundred predefined SmartArt templates. So
remove this test, it prevents to find the shape.
After removing the above mentioned test, an error in WriteText() in
the export becomes visible. The export of a SmartArt diagram calls
WriteText() with bBodyPr=false. With that no a:bodyPr element is
written at all. But for the CT_TextBody it is specified in OOXML, that
the bodyPr child element is mandatory. Thus we need to write an empty
element in this case. Without it, the file markup is invalid and
MS Office requests to repair the document.
Change-Id: I9cdf5e882b415ca1d13718d6c1e47ebb1d2c7018
Signed-off-by: Regina Henschel <rb.henschel@t-online.de>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4396
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 533dccff298edc397a9c0fc564ba4d31b8c27432)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206994
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Nothing told a horizontal rule apart from an ordinary rectangle, so it could
not be laid out the way Word does; the marker is that distinction, and its
absence is what keeps documents written before it rendering unchanged.
The UNO property reports DEFAULT_VALUE while false, since ODF export only
writes direct values - else every shape and graphic style would carry it.
Also let the RTF import build a rectangle for a rule, as the VML import
already does, so both filters produce one model object.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Id2facd7bdc272197273462f0ad581537551234bc
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8657
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit dbe7dca2951640990d3febaf12a9c3118e15ec22)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209328
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
It appears that the ownerIdx attribute of <cx:series> is used to indicate
that series share data. At least that seems to be the case with pareto
charts, which have both a clustered column and a pareto line series. Going
on that assumption, implement parsing/export of ownerIdx, and don't write
a dataId tag when ownerIdx is present. That fixes round-tripping of
pareto charts, at least based on what I've seen.
Signed-off-by: Kurt Nordback <kurt.nordback@collabora.com>
Change-Id: Ie948d2e5992b778462e34e1ef90681631c867332
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5900
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 8c37a25ffb7711f69de978045b4e3dc8d52759da)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209240
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Aron Budea