Add new paragraph justification option "Split compound words" for
custom compound-based "smart" hyphenation. Add compound-based "smart"
hyphenation support for Danish, Dutch, Esperanto, Estonian, German,
Norwegian, Swedish (and potentially, Icelandic, Finnish and
Latvian) languages by fixing Hunspell morphological analysis and the
associated lingucomponent code. (Previously compound-based "smart"
hyphenation was enabled only for Hungarian.)
With the new option it's possible to keep MSO/MS-DOCX interoperability,
also introducing a better hyphenation algorithm for several languages.
Details:
* Add check box to Alignment in paragraph formatting dialog window;
* Store properties in paragraph model:
css::style::ParagraphProperties::ParaIsCompoundBased
* Implement it by checking the new option in the previously
added commit f9f694f5d9f39c5801bc5fec45867252c293bbcb;
* Add ODF import/export (loext:compound-based);
* Add ODF unit tests by the new tdf173389_smart_hyphenation_nl.odt
and tdf173389_smart_hyphenation_hu.odt. Now use the previous
tdf119908_smart_hyphenation_hu for disabled compound-based "smart"
hyphenation, also the new tdf119908_smart_hyphenation_nl.odt.
Note: the Dutch test document results better compound-based
hyphenation in two positions.
* Add Hunspell patch to fix Danish, Dutch, Esperanto, Estonian,
German, Norwegian, Swedish (and future Icelandic, Latvian,
Finnish) morphological analysis for compound word constituents;
* hyphenimp.cxx hyphenate(): fix tokenization for consecutive
pa: elements, like resulted in the fixed Hunspell dictionaries.
Follow-up to commit f9f694f5d9
"tdf#173389 sw: add compound-based “smart” hyphenation for readability".
Change-Id: I4414bd588646ecf6dc86b77642833ac9c7820a98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211341
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
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
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
The default drawing style names a theme color now, and a PPTX saved
to ODF and back came out with every shape green. A shape that really
did name a theme color lost the reference and came back plain.
A color item holds the color and the theme reference together.
Setting a plain color started from the item the shape inherits from
its style and overwrote the color alone, so the inherited reference
won. Clear the reference, which is what an explicit color means.
The ODF export repeats each shape's fill on a paragraph style,
applied after the graphic style, and the paragraph properties had no
complex color. Carry it there too.
A style's graphic properties took a complex color only when it was
the character one, matched by element name. Match on the context id,
which the fill and stroke colors share.
Add a round trip test through ODF and PPTX with a plain shape, a
themed one, and a themed one with a luminance modulation.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia9550222d18a243287240e4184666d78d0abdd22
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10060
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 07cf37b104983f765d3e1005f677e0058df12026)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210510
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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>
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
We had only one shared setting for the three script groups, which means
the same variation settings are applied to the three groups, which makes
no sense as they often use entirely different fonts.
Change-Id: I6f2a8b4d1c9e0357a6b2d8f4e1c7093b5a2d6e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209222
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
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>
To solve the trade-off between better spacing and less hyphenation,
support hyphenation level and its user interface, the hyphenation
slider, like DTP software do.
Add new paragraph property com::sun::star::text::ParaHyphenationLevel
The hyphenation slider is the basic interface of DTP software to adjust
single (or all) paragraphs using better word spacing (i.e. more
hyphenation) or less hyphenation (i.e. worse word spacing). It allows 1)
to choose the best from the near equally good layouts and 2) to solve an
extreme bad layout (caused by words without hyphenation or other corner
cases).
– 50% hyphenation level means disabled hyphenation, if minimum
and maximum word spacing settings allow to break the line within
words (default interoperability value).
– 100% hyphenation level means using extra hyphenation only if that
results better word spacing in the line, than breaking within words.
– Between 50% and 100% hyphenation level, use extra hyphenation only if
its weighted word spacing is better, than breaking the line between
words (weighting grows with the hyphenation level).
– Between 0% and 50% hyphenation level it means disabled hyphenation
with increased desired and maximum word spacing, depending on the
hyphenation level. At %0, the desired word spacing is enlarged to the
original maximum word spacing, while maximum word spacing is enlarged
by a single space.
For example, the original 4-page unit test document with the default 50%
hyphenation level contains 14 hyphenations. 100% hyphenation level
results in 22 hyphenations, while 0% only results in 8 hyphenations.
– sw/qa/extras/layout/data/tdf167648_minimum.fodt,
sw/qa/extras/layout/data/tdf169168_minimum.fodt: set maximum
word-spacing to 100% from 101% to limit the original unit test only
for minimum letter spacing.
More information: LO/COOL Book & Typography projects:
https://www.numbertext.org/typography/https://www.numbertext.org/book/
Follow-up to commit cf104be5cb "tdf#119908
tdf#166113 cool#15973 sw smart justify: fix DOCX hyphenation",
commit d572576dd6
"tdf#119908 cool#15973 sw smart justify: fix "smart" hyphenation",
commit 529755f091
"tdf#166113 sw smart justify: adjust algorithm for interoperability" and
commit 7d08767b89 "tdf#130088 tdf#119908
smart justify: fix DOCX line count + compat opt."
Change-Id: I84b3893ea6c5cd4eff74a73514722285e7071392
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207545
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Read underflow and overflow attributes from the histogram chart
type properties.
Export the same properties back to <cx:binning> so chart roundtrip
preserves optional edge bins.
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Change-Id: I963febac4987da23dce2571928982973f7ea67d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207153
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Import classifies each formula cell:
- Plain non-array, no coext:spill: the import-time walk over
the freshly compiled RPN decides if the formula intends an
array. If yes, prepend @ at the front of the parse and at
the back of the RPN.
- Plain non-array + coext:spill="true": a master saved while in
spill state. Comes back at 1x1 with the dynamic flag, the
position marked spilled. The next interpret re-checks the
blockers.
- Array formula (matrix dims): static array master by default.
coext:spill="true" promotes it to a dynamic-array master.
Legacy Ctrl+Shift+Enter (CSE) arrays without the marker keep
their static iteration-and-pad behaviour.
Export reverses:
- ODF always strips @ on save. The @ is an in-memory marker
only. OOXML and the UI grammar keep it.
- Dynamic master: coext:spill="true" in extended ODF, matrix
dims as before. In spill state, write as plain non-array with
coext:spill="true".
- Static array master: matrix dims, no coext:spill.
GetFormula skips the {} wrapping for dynamic-array masters so
they read back as plain formulas. Static array masters keep {}.
XML_SPILL is added to the xmloff token machinery and the ODF
extension schema (OpenDocument-v1.4+libreoffice-schema.rng)
gains coext:spill on table-cell.
Tests cover each import shape, the FODS export of regular and
spilled masters, the @ insertion on CompileXML, and the @
stripping at the formula-compiler level. ArrayFormulasStatic.ods
is a legacy fixture whose B1 = AND(C4:C52) summarises 49 per-row
value checks. The test runs the grid on import and after an ODS
round trip and confirms plain bare-range cells gain @ while the
five matrix masters stay static, keep their {} wrapping, and
get no coext:spill in the saved XML.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ib8ae345528185c824415ec5d039b6d5cf0d7eac8
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4663
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a21f6a3a0eae72fef90576d249d96dc00beeb2c5)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207171
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
After
commit e052641d460d8111d3333705aea03ad24822ebbb
Author: Michael Stahl <michael.stahl@collabora.com>
Date: Thu Apr 16 14:55:25 2026 +0200
xmloff,package,xmlsecurity,oox: add Collabora extension namespace
For both ODF and OOXML export, add a new "coext" namespace.
New features saved in Collabora Office will not work in LibreOffice
Also add a test for it
Change-Id: I5626dbcf5e87e06ef94e33d1ce09a091c1557688
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206987
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
When Base loads forms, it flattens ParagraphAdjust values into
GUI-specific awt::TextAlign values. The code that performed this
remapping was missing some recently-added values, causing apparent loss
of column alignment after save.
This change adds the missing values. In addition, this change adds unit
tests for the conversion code, and fixes a long-standing typo bug that
made values fail to round-trip.
Regression due to the following commit:
commit 5d1b2baaa9
Author: Jonathan Clark <jonathan@libreoffice.org>
Date: Tue Oct 21 02:14:26 2025 -0600
tdf#118350 [API CHANGE] Implement start and end paragraph alignment
Change-Id: Ica27870a952c6ec77360f416e112724b4943a016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206816
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
In Word only the first-page-shared flag is shared between header and
footer, while the existence of header and footer is independent.
Split into core flags `DisableFirstHeader` / `DisableFirstFooter`,
properties `HeaderNoFirst` / `FooterNoFirst` (which allows removing some
special checks as the name prefix checks now cover these).
`SectionPropertyMap::setHeaderFooterProperties()` had some special code
to turn off a header but not a footer, add that to do it consistently.
Also rename the ODF attributes, `is-first-page-header-enabled` better
describes the values than `is-first-page-header-shared`.
Signed-off-by: Michael Stahl <michael.stahl@collabora.com>
Change-Id: Ieee9cb7a8f7b4fb7e66352c95142d8ccb06f9cb5
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4383
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit a443891f1a6480421fa08c311526c1a9d4bdd642)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206703
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The problem with not having some but not all headers enabled on a page
style is that Word does page margins differently than Writer, and this
causes `testTdf116486` and `testFdo44176` to fail.
In Writer, it's always additive: page `fo:margin-top` + header
`fo:margin-bottom` gives the spacing from the top of the page to the
body text.
In Word, there is a `w:header` (from top of page to header) and `w:top`
(from top of page to body text) and the problem is, they're not
additive, both are measured from top of page.
If all headers are enabled,
`SectionPropertyMap::PrepareHeaderFooterProperties()` can map this to
`HeaderHeight` and `HeaderBodyDistance` properties, but of course those
won't be used if there's no header on the page.
So import `w:top` as a new property "MinTopBodyDistance" (and also
"MinBottomBodyDistance") implemented as new item
`RES_FRMATR_PAGE_MIN_TOP` (and also `RES_FRMATR_PAGE_MIN_BOTTOM`).
Use it in `SwLayoutFrame::Format()` to set the page frame margins, but
only if there is no header; else rely on the existing header properties.
Export this to ODF as
`coext:min-page-margin-top` and `coext:min-page-margin-bottom`.
Signed-off-by: Michael Stahl <michael.stahl@collabora.com>
Change-Id: I9d98bbf7138c9ef04d4ab1ddcb4c3183a12d9b11
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4310
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e065ba01c029cd01c9128afccdc953e2e3a49e65)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206702
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
A broken ODF document may have draw:fill-image-name on the page layout
or drawing-page properties referencing a name with no matching
<draw:fill-image> element in <office:styles>. When the same page layout
also has a style:background-image with actual image data (the old
mechanism), recover the missing bitmap table entry from it.
This is done before deactivateOldFillStyleDefinitions so the
BackGraphic property indices are still valid. The recovered bitmap is
inserted into the BitmapTable so the draw:fill-image-name reference
resolves correctly, making the background image visible in the page
setup dialog (Area tab) and in Collabora Online.
Change-Id: I5c1b658621f288af026c57e69d13363fbc1fe45a
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/1142
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit b370baba6ac0daa31395f47b80bc5c11cc561b1e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206429
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Since commit 3da86d8987 ("tdf#114488
Rank multiple images also for flat odf") GetMimeTypeForExtension()
resolves the "svm" extension to the "image/x-svm" media type. As a
side effect SvXMLGraphicHelper::implSaveGraphic() now stamps that
non-empty media type on the Pictures/*.svm package stream.
ZipPackageStream treats every non-text media type as an
already-compressed format and stores the stream without deflate
(ZipPackageStream::setPropertyValue, "MediaType"). Before the above
commit the svm media type was empty, so the stream kept being
zip-compressed.
But SVM, like EMF/WMF, is an *uncompressed* metafile and must be
zip-compressed. The aCompressiblePics allowlist already contained its
sibling metafile formats (image/x-emf, image/x-wmf) but was missing
image/x-svm, based on the wrong assumption that the ZBITMAP stream
option compresses it -- ZBITMAP only compresses embedded bitmap
actions, not the vector action stream.
Add image/x-svm to the allowlist. A vector SVM that was stored
uncompressed at 8 MB now deflates to ~0.6 MB again (92%), so files
with SVM graphics -- and "Tools > Minimize Presentation" on them --
shrink as expected, losslessly.
Change-Id: I4b67f9a87e4a54c03f16b7babaf2d0ede1202754
Signed-off-by: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4337
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 2364fc9aeb36ea5edbb38f3fde9e391b481839e3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206689
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
In report builder if the charts contain date or time
then the generated chart appear without content.
This is fixed by adding appropriate handling of date
and time value cases.
Change-Id: Idfa0e03645e1e8130707fc541b155fd53311572d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206232
Tested-by: Jenkins
Reviewed-by: Vissarion Fisikopoulos <vfisikop@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
ODF import applied the histogram template before series data existed, so
bins were not rebuilt on reload. Apply it again after series import.
For XLSX import, preserve generated histogram bin labels during axis
conversion instead of replacing them with generic category labels.
For XLSX export, write the direct values-y source range for new
histograms instead of generating an _xlchart.v1.N alias without a
guaranteed matching workbook definedName.
(cherry picked from commit d346a0edcaa200720b8ce5716a84427b5fce10d8)
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3302
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Change-Id: I6c9d2aa5c70e0340331cde159499f3c4992828a1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205843
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>