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
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>
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>
A graphic-object shape with no embedded graphic data exported as
<draw:image><text:p/></draw:image>. Per ODF's draw-image content
model draw:image has a choice between common-draw-data-attlist (the
xlink:href and friends attributes) and office-binary-data, followed
by draw-text (text:p etc.). Without either alternative of the choice
the element is incomplete, and the validator rejects it - the
diagnostic mentions text:p because the parser stops at the missing
choice content before reaching the draw-text part where text:p would
be valid.
Emit an empty <office:binary-data/> placeholder when there is no
xlink:href and no graphic data, satisfying the choice.
Groundwork for the clip polygon that follows, which is written on
exactly such a shape: a picture placeholder that never got an image.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I5bf792c60affd35b33779c91be0a381eb074f00f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9189
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 6d1cbfc9fb8e9a705b05f6cdddd4a87a630e973d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210035
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
A presentation can reference sound files outside its own package, on a
slide transition, an animation, or a click action.
Linked graphics already come under link management, where the user
allows each external reference on its own.
Bring presentation sounds under the same link management. Each external
sound is registered as a link the user can allow through the link-update
infobar or "Edit, Links".
For the uno api move these sounds around as XSoundReference so their
allowed state can be moved with them. So that changes the property
from a string to an XInterface. Setter still accept a string, getter
returns the new XInterface, there's an acknowledged possibility of
incompatibility despite being technically api-change-passing
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Ib7deea2f78cf5c5b9958e43adb8e6f46b1b31e80
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/6970
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 0aa870b7b5a6bda50bab50c7a0a41d28fdf4f6ab)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208430
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The replacement raster image written next to an SVG primary was a
backwards-compatibility fallback for older ODF readers that could
not decode SVG. SVG has been in ODF long enough that current readers
handle it, so the PNG fallback is no longer worth carrying. To stay
cautious, only skip it when the document is written as ODF 1.4 or
newer.
Add testSvgPngFallbackOdf14 and testSvgPngFallbackOdf13 covering
the new behaviour. Both load odp/SvgImageTest.odp, which already
has an SVG primary with a PNG fallback. The ODF 1.4 case must
round-trip with no PNG file under Pictures/, while the ODF 1.3
case must still emit one.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ic3a54f46dd21db0d54f07d410243b885f8905a94
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4164
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 0dec43976c4410cb237b421813e5352ab94195d7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206353
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
PPTX export (pptx-epptooxml.cxx):
- Add xmlns:p14 namespace declaration on <p14:sectionLst>,
required by Office 365 to parse the extension block
- Add position-based fallback when slide name lookup fails
(e.g. after ODP round-trip where "Slide 1" becomes "page1")
- Make section extension URI a constexpr string
ODP export (sdxmlexp.cxx):
- Resolve grab bag slide names to current draw:page names by
position, preventing stale name mismatch between
<loext:section-slide loext:name="..."> and <draw:page draw:name="...">
Change-Id: Id816072838da1a8be4c638310ec252b2eaeaf041
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/895
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit 78766729df864a2d46ed02e95fba7ab4ebf3f689)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205054
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Store slide sections in ODP files using a new loext: extension
element, written only in ODFSVER_EXTENDED mode:
<loext:section-list>
<loext:section loext:name="Section Name"
loext:identifier="{GUID}">
<loext:section-slide loext:name="Slide1"/>
</loext:section>
</loext:section-list>
Export (sdxmlexp.cxx):
Add exportSections() method that reads OOXSectionList from
InteropGrabBag and writes the loext elements. Section names,
GUIDs, and slide page names are written directly since the
grab bag already stores names.
Import (ximpbody.cxx):
Add SdXMLSectionListContext and SdXMLSectionContext classes
that parse the loext:section-list structure and store sections
back into InteropGrabBag with slide names and optional GUIDs.
Hook into SdXMLBodyContext::createFastChildContext.
This enables full PPTX -> ODP -> PPTX round-trip preservation
of slide sections including their GUIDs.
Change-Id: Ic1c040d06c8c890699b7dfa4974694a2ea204f90
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/713
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
(cherry picked from commit b0c9f8bd70a96b2e3d432993260920d3739a2eda)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205050
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
This is safe to ignore both, when one of them empty, as opposed to a
case when both are non-empty, but have different number of elements.
Allows to read some broken real-life documents.
A possible TODO: maybe consider to warn about a broken package, and
only open in repair mode?
Change-Id: I0697dcc73933aa1761ba59a766a519965872a0ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202552
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
On export, always write ControlBorder and ControlBorderColor to the
auto style for control shapes, even when the property state is
DEFAULT_VALUE.
On import, when fo:border is absent, apply the control model's default
border to the shape.
a) New document, user sets flat (2) border:
The constructor default is 2 (flat) but getPropertyDefaultByHandle
returns 1 (3D). Property state is DIRECT_VALUE and the filter exports
fo:border as before. On reimport fo:border is present and applied.
No change in behavior.
b) New document, user sets no (0) border:
Same as flat, DIRECT_VALUE, exported by the filter. No change.
c) New document, user sets 3D (1) border:
1 matches getPropertyDefaultByHandle so property state is
DEFAULT_VALUE and the export filter would previously skip it.
Now export always adds adds ControlBorder explicitly, so fo:border
is written. On reimport fo:border is present so applied.
d) Old document (pre tdf#152974) with no fo:border:
These documents never wrote fo:border for 3D because that was the
real default. Now on import the importer detects the missing
fo:border and queries getPropertyDefault("Border") for the control
which returns 1 (3D) for text controls, restoring the original
border. On reexport the exporter writes an explicit fo:border.
e) Label controls (tdf#167358):
Labels default to no (0) border. Their getPropertyDefault
returns 0, so the importer applies no border when fo:border is
absent, so this fix effort shouldn't cause that problem again.
Change-Id: I365adf84e9d26ae3231331230178381d31bfa829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200685
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
ODF 1.4 Part 3 sect. 19.203 draw:page-number tells:
> For thumbnails on notes pages, the value of this attribute is fixed
> to the drawing page of a notes page.
As further clarified in OASIS ODF TC call from 2025-11-24 for issue
OFFICE-4178, that wording shall be improved to unambiguously point to
exactly the drawing page of the respective notes page. This means,
that for thumbnail of DrawingPage's notes page, the actual value of
the attribute is unimportant. As the bugdoc shows, the attribute may
be missing. It may also possibly have wrong number. In any case, we
should not break the default correct reference established between
the thumbnail object and respective DrawingPage, when thumbnail was
created.
This change implements just that. For SdXMLPageShapeContext, it adds
a new method ignorePageNumber, which sets mnPageNumber to -1. Given
that this value corresponds to draw:page-number, having XML type
positiveInteger, this special value is safe and cannot coincide with
any valid value there. Its meaning is "do not set the shape's page
number", which will keep the mentioned original reference.
ignorePageNumber is only called in the context of DrawingPage/notes
page: the "ignore" flag is passed through SdXMLNotesContext from
SdXMLDrawPageContext::createFastChildContext. For notes of master
page, handled in SdXMLMasterPageContext::createFastChildContext, no
change is done.
Change-Id: I39ef16d4e0ceda89b38ee994c908157e93c119a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199283
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
ShapeGroupContext::popGroupAndPostProcess() is called 2 times when
importing an ODF package file, once at the end of styles.xml, then at
the end of content.xml; in the 2nd case, all shapes of styles.xml end up
in maUnsortedList.
There are 2 problems with it:
1. in the XShapes3 branch, once maZOrderList is empty, any remaining
elements in maUnsortedList are ignored and thus the aNewOrder
contains duplicate 0s at the end which will cause sort() to throw
2. the XShapes3 branch removes elements from maUnsortedList, hence when
the exception is caught and the fallback path runs, it only moves
the elements that happened to remain in maUnsortedList
Effectively, what happens is that the z-order of everything in
headers/footers is rotated so that the last (topmost) N elements go
to the start (background).
3. In case the objects in content.xml happen to be sorted correctly
wrt each other, but there was an object with higher z-index in
styles.xml, sorting is skipped.
Turns out that testTdf159158_zOrder_headerBehind already tests this.
(regression from commit a8b1699ca9)
Change-Id: Ifdde6fc43af4c655b430d723b875dfd46e8533f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197475
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(cherry picked from commit 66a1ad2163d5799a79b23554b22e08a07f693225)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197730
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
found by converting tdf43054--1.odp to pptx and running officeotron on the output
Validating part "/ppt/presentation.xml" using schema "29500T/pml.xsd" ...
- (ppt/presentation.xml:2 col:1,116) cvc-minInclusive-valid:
Value '900113' is not facet-valid with respect to minInclusive '914400' for type 'ST_SlideSizeCoordinate'.
We get the slide size from the master page, and this page appears not to have any
width or height values at all, so use a useful value in that case.
Change-Id: I3624b4ba79ec4919655995c20d729b22ff443641
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194701
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 2d82d56d3f536ba2bbe0496c4f6488e61a2247cb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194752
Tested-by: Jenkins
TextWritingMode and ControlWritingMode are suppressed when
ShapeWritingMode exists.
With commit c70ee4a6b9 we have in addition
GraphicWritingMode2. Thus suppress them in that case too to avoid
duplicate attributes.
Change-Id: Ie7064e2dcea3a6dccc081f03bf027c1e7a261bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194371
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
this is the same concept/ideas as
a12bd4fedfc3f269f1dbb5fea36b607facd1261d
[API CHANGE] sd pdfium: add page number when saving/loading pdf pages as images
but extended to support fodg where the problem of showing the first page
of the pdf for all images remained.
Change-Id: I5a180037634f71104800e09bec400316b56ab1f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193156
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
The problem was wrong identification of the shape type, because of
unreliable use of fragile Z-order.
XMLShapeExport::exportShape used xShape's Z-order to get the info
collected for current xShape. Value of Z-order is calculated in
SwXShape::getPropertyValue; it takes into account text boxes of
shapes, which affects the correction in SwTextBoxHelper::getOrdNum.
The correction results in several different objects returning the
same Z-order. And in the specific document, the information that
was collected for a rectangle object, was used for an object of
different type.
Instead of trying to find a smart way to continue using Z-order,
this change uses XShape itself as the key into the map of info,
similar to how XShapes objects are used as keys into ShapesInfos.
Change-Id: Iacbc101623504db4290ad2c283351c4141b2d1b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192796
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
this is an internal UNO API, and there is only one implementation,
so make that obvious in the code.
That required moving some classes from the svx library to the
svxcore library
Change-Id: Ic5c19327df271920dc1077185ff692abbf5fb091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191494
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
and
cid#1660225 Variable copied when it could be moved
cid#1660211 Variable copied when it could be moved
cid#1660185 Variable copied when it could be moved
cid#1660173 Variable copied when it could be moved
cid#1660168 Variable copied when it could be moved
cid#1660166 Variable copied when it could be moved
cid#1660165 Variable copied when it could be moved
cid#1660163 Variable copied when it could be moved
cid#1660152 Variable copied when it could be moved
cid#1660149 Variable copied when it could be moved
cid#1660147 Variable copied when it could be moved
cid#1660145 Variable copied when it could be moved
cid#1660142 Variable copied when it could be moved
cid#1660140 Variable copied when it could be moved
cid#1660137 Variable copied when it could be moved
cid#1660136 Variable copied when it could be moved
cid#1660135 Variable copied when it could be moved
cid#1660128 Variable copied when it could be moved
cid#1660124 Variable copied when it could be moved
cid#1660122 Variable copied when it could be moved
cid#1660117 Variable copied when it could be moved
cid#1660114 Variable copied when it could be moved
cid#1660110 Variable copied when it could be moved
cid#1660109 Variable copied when it could be moved
cid#1660105 Variable copied when it could be moved
cid#1660104 Variable copied when it could be moved
cid#1660102 Variable copied when it could be moved
cid#1660100 Variable copied when it could be moved
cid#1660098 Variable copied when it could be moved
cid#1660080 Variable copied when it could be moved
cid#1660079 Variable copied when it could be moved
cid#1660078 Variable copied when it could be moved
cid#1660075 Variable copied when it could be moved
cid#1660071 Variable copied when it could be moved
cid#1660070 Variable copied when it could be moved
cid#1660064 Variable copied when it could be moved
cid#1660063 Variable copied when it could be moved
cid#1660060 Variable copied when it could be moved
cid#1660058 Variable copied when it could be moved
cid#1660053 Variable copied when it could be moved
cid#1660050 Variable copied when it could be moved
cid#1660049 Variable copied when it could be moved
cid#1660046 Variable copied when it could be moved
cid#1660042 Variable copied when it could be moved
cid#1660028 Variable copied when it could be moved
cid#1660023 Variable copied when it could be moved
cid#1660022 Variable copied when it could be moved
cid#1660021 Variable copied when it could be moved
cid#1660020 Variable copied when it could be moved
cid#1660017 Variable copied when it could be moved
cid#1660013 Variable copied when it could be moved
cid#1660005 Variable copied when it could be moved
cid#1660003 Variable copied when it could be moved
cid#1659999 Variable copied when it could be moved
cid#1659998 Variable copied when it could be moved
cid#1659995 Variable copied when it could be moved
cid#1659993 Variable copied when it could be moved
cid#1659989 Variable copied when it could be moved
cid#1659988 Variable copied when it could be moved
Change-Id: I2a30c8a2ac8785050d49b98635b0b406535b185a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189056
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
... property #2"
This reverts my 25.2 commits d4dad2e181
and 5a617f77ee.
Obviously this entire thing is just too broken
for a simple guy like me to fix.
It seems like each kind of control has its own definition
of what should happen if the border is not specified.
So much for ODF standardization of default style values...
This makes it virtually impossible to force a setting at import time,
and since styles (without specified fo:borders)
could theoretically be shared between the different control types,
it might also make it impossible to force an export as well?
make CppunitTest_xmloff_style
Change-Id: I0182878a16213ad2c7f06524fe85388aae86551f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187654
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Commit 69ed893087 (tdf#160253: fix list
identifier export decision code) made a large change to the autostyle
collection procedure, which became more precise. It turns out, that
before that change, exporting content.xml gathered autostyles from
page definitions, too, meaning that the fonts used there were marked
as used in that pass. After the change, that pass doesn't look into
the page styles and their content, and the fonts that are only used
in headers/footers aren't seen as used in that pass.
The font embedding procedure was previously implemented to only do
the embedding during content.xml export, to avoid duplicating font
files from each pass. Since each stream was exported by a separate
instance of SvXMLExport, it was considered difficult to maintain the
already embedded fonts list across all passes. It assumed that the
export of content.xml sees all used fonts.
But after the described change, this assumption doesn't hold anymore.
We need to make sure to embed all fonts found in all passes.
This change introduces such state, implemented as set of font names
maintained in the object that exports all the streams, creating an
exporter for each. Using a new set of function to set and get the
"already embedded" font list in SvXMLExport, the outer object passes
that list to each created SvXMLExport instance, and after the call
to `filter`, retrieves the updated list, to pass it to the next one.
The change required to move some members from XMLFontAutoStylePool
to SvXMLExport, to avoid additional complexity of passing the list
from SvXMLExport to XMLFontAutoStylePool. The implementations of
the moved methods are kept in XMLFontAutoStylePool.cxx, because the
internal structs used in the methods are defined there.
After the change, some of the embedded font file references, that
previously appeared in content.xml, will now be in styles.xml.
Change-Id: Iaa26f1d1d623dee5a5c43600ea5fd2af1d04b46f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185704
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Andrea Gelmini