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>
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
Export histogram charts as chart:bar with coext:class="histogram"
and write histogram properties.
Import the histogram class and configuration again recreate the
HistogramChartType, and trigger the histogram template once chart
import is complete so calculated bins, categories, and frequencies
are rebuilt from the preserved raw values-y data.
Change-Id: I202d5666315d4f26da2bf4b3650b4388a9e4fb50
(cherry picked from commit 5fb2f5f2c2676743b823640dbaa02762308d6a54)
Signed-off-by: Devansh Varshney <varshney.devansh614@gmail.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/1880
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit a54fc185d3d73f765bd37cc98df92cac81e01572)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203814
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Store the full threaded comment data as loext: extension elements inside
office:annotation: root text, GUID, person-id, datetime, resolved flag,
and replies. The person list is written as a separate loext:persons
element at the spreadsheet body level, referenced by person-id from
each annotation.
The loext:resolved attribute on office:annotation is not used for Calc
annotations, since resolving only applies to threaded comments; the
flag is an attribute on loext:threaded-comment instead.
Extend the libreoffice ODF schema with loext:threaded-comment,
loext:reply, loext:persons, and related attributes. Add xmloff tokens
for the new element and attribute names.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ibdb6cca545c853b196a8ec234b26542d392967bb
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/803
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 8cddb66d12942025e223d0d54f6bca03ac3b7f94)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205296
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Balance word spacing within the consecutive lines
to get uniform grayness and less rivers for better
readability, enabled by the new paragraph property
com::sun::star::text::ParaComposer
and the following developments:
* Add Paragraph Composer checkbox on Alignment pane of the
paragraph formatting dialog window (not default yet);
* Implement paragraph composer: big word spacing of a
line is decreased by shifting the last word from the
previous line, only if the word spacing is better, than
before, and the increased word spacing in the previous
line doesn't exceed the Maximum word spacing (limited
paragraph composer);
* When Maximum word spacing is not greater than the Desired
word spacing, shifting of the last word is not limited
by the Maximum word spacing (unlimited paragraph composer)
* Add loext:paragraph-composer attribute, as LibreOffice
ODF extension;
* Add ODF unit tests for the limited and not limited
paragraph composer.
Note: "Smart justify" line breaking algorithm chooses
space shrinking (limited by Minimum word spacing)
only if shifting the last word isn't better based
on the desired word spacing. This was still a greedy
line breaking algorithm, resulting big word spacing
in the lines before a longer word.
The paragraph composer shifts the last word (or the
first part of the hyphenated last word) from the previous
line to decrease big word spacing in the actual line.
Note: balancing very big word spacing in narrow consecutive
lines can result vertical rivers. To avoid this, use limited
paragraph composer by setting maximum word spacing.
Follow-up to "smart justify", word spacing, letter spacing
and glyph scaling developments. Selected commits:
commit 529755f091 "tdf#166113
sw smart justify: adjust algorithm for interoperability",
commit 7d08767b89 "tdf#130088
"tdf#119908 smart justify: fix DOCX line count + compat opt.",
commit 7d6696757d "tdf#159923
sw cui offapi xmloff: add custom word spacing",
commit 5a48070f59 "tdf#126154
sw offapi xmloff cui: add min/max word spacing",
commit f83a04c510 "tdf#167648
cui offapi xmloff sw: add DTP-feature maximum letter spacing",
commit 3c53797210 "tdf#167648
sw letter spacing: implement minimum letter spacing",
commit 45ec7bd761 "tdf#168251
cui offapi xmloff sw glyph scaling: extend UNO/UX/ODF".
Change-Id: I727caad70536c86be524bc9d9b52bc71208c202a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203288
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
...contrary to what 0a42ddbdf1 "tdf#146619 Use
more forward declarations in include/xmloff" apparently assumed,
> [CXX] linguistic/source/convdic.cxx
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\span(75): error C2036: 'const XMLPropertyState *': unknown size
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\span(75): note: the template instantiation context (the oldest one first) is
> include\xmloff/txtparae.hxx(404): note: see reference to class template instantiation 'std::span<const XMLPropertyState,18446744073709551615>' being compiled
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\xutility(2184): note: while evaluating concept 'input_iterator<std::_Span_iterator<XMLPropertyState const > >'
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\xutility(984): note: while evaluating concept 'input_or_output_iterator<std::_Span_iterator<XMLPropertyState const > >'
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\__msvc_iter_core.hpp(403): note: see reference to class template instantiation 'std::_Span_iterator<_Ty>' being compiled
> with
> [
> _Ty=const XMLPropertyState
> ]
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\span(70): note: while compiling class template member function 'std::_Span_iterator<_Ty> &std::_Span_iterator<_Ty>::operator --(void) noexcept'
> with
> [
> _Ty=const XMLPropertyState
> ]
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\xutility(1839): note: see the first reference to 'std::_Span_iterator<_Ty>::operator --' in 'std::iter_move'
> with
> [
> _Ty=const XMLPropertyState
> ]
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\xutility(857): note: see the first reference to 'std::iter_move' in 'std::ranges::_Iter_move::_Cpo::operator ()'
> C:\PROGRA~1\MICROS~3\2022\COMMUN~1\VC\Tools\MSVC\1444~1.352\Include\xutility(881): note: see the first reference to 'std::ranges::_Iter_move::_Cpo::operator ()' in 'std::_Indirectly_readable_impl<std::reverse_iterator<std::_Span_iterator<_Ty>>>'
> with
> [
> _Ty=const XMLPropertyState
> ]
Change-Id: Ifd2f07f1dadf26516a8732dde1fed757af5e8e96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201475
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
...contrary to what 0a42ddbdf1 "tdf#146619 Use
more forward declarations in include/xmloff" apparently assumed, as seen at
least with recent Clang 23 trunk against recent libstdc++ 16 trunk,
> In file included from xmloff/source/chart/SchXMLParagraphContext.cxx:21:
> In file included from xmloff/source/chart/SchXMLParagraphContext.hxx:21:
> In file included from include/xmloff/xmlictxt.hxx:28:
> In file included from workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/xml/sax/XFastContextHandler.hpp:6:
> In file included from workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/xml/sax/XFastContextHandler.hdl:6:
> In file included from workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/XInterface.hdl:6:
> In file included from include/com/sun/star/uno/Any.h:30:
> In file included from include/rtl/ustring.hxx:45:
> In file included from include/rtl/string.hxx:51:
> In file included from include/rtl/stringconcat.hxx:22:
> In file included from ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/memory:80:
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/bits/unique_ptr.h:90:16: error: invalid application of 'sizeof' to an incomplete type 'SvXMLImportPropertyMapper'
> 90 | static_assert(sizeof(_Tp)>0,
> | ^~~~~~~~~~~
> ~/gcc/inst/lib/gcc/x86_64-pc-linux-gnu/16.0.1/../../../../include/c++/16.0.1/bits/unique_ptr.h:398:4: note: in instantiation of member function 'std::default_delete<SvXMLImportPropertyMapper>::operator()' requested here
> 398 | get_deleter()(std::move(__ptr));
> | ^
> include/xmloff/shapeimport.hxx:153:62: note: in instantiation of member function 'std::unique_ptr<SvXMLImportPropertyMapper>::~unique_ptr' requested here
> 153 | std::unique_ptr<SvXMLImportPropertyMapper> pExtMapper={} );
> | ^
> include/xmloff/txtimp.hxx:34:7: note: forward declaration of 'SvXMLImportPropertyMapper'
> 34 | class SvXMLImportPropertyMapper;
> | ^
Change-Id: I58fec903631d04dd7a89e599cf745115cdab22bd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200036
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
This change updates Writer to better conform with the ODF standard
wording for the fo:text-align attribute when used in
style:list-level-properties.
Previously, Writer interpreted list label alignments while ignoring
paragraph direction, always behaving as if the list label is always
left-to-right. This change updates Writer to instead apply label
direction correctly, treating start and end label alignment in a manner
similar to how we treat start and end paragraph alignment.
The list style dialog has been updated to reflect the new behavior as
start/end alignment, rather than left/right alignment.
This change also adds the LIST_LABEL_ALIGNMENT_IGNORES_DIRECTION
compatibility flag. In order to preserve the layout of existing
documents, this flag is enabled automatically when loading an ODF
created with earlier versions of LibreOffice.
Change-Id: I56cd37fa83487b010369b99570f7bb4750c07595
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198857
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Add new minimum character limit paragraph property to limit
hyphenation left to the compound constituent boundaries:
com::sun::star::text::ParaHyphenationCompoundMinTrailingChars
– With the previous option for the hyphenation right to the
constituent boundary, this new option allow to limit or disable
hyphenation completely inside the compound constituents, or
hyphenate only at constituent boundaries, with or without
inside the suffix of the word or constituents;
– xmloff: add "no-limit" to loext:hyphenation-compound-push-char-count
and loext:hyphenation-compound-push-char-count;
– "no-limit" values of this and the *LeadingChars option mean
a maximum value. When both *LeadingChars and *TrailingChars
got "no-limit", hyphenation before and inside the suffixes are
forbidden, i.e. it is allowed only at constituent boundaries;
– textflowpage.ui: set max character count to 99, in both options;
– fix ParaHyphenationCompoundMinLeadingChars implementation for
compound words with multiple constituents, when the middle word(s)
are shorter, than the limit (e.g. Hungarian "tűz|kő|pattintás"
wasn't hyphenated as "tűzkő-pattintás", only as "tűz-kőpattintás").
Follow-up to commit 3a332d9f1c
"tdf#158885 cui offapi sw xmloff: fix hyphenation at stem boundary"
and commit c899d3608d
"tdf#158885 sw: don't hyphenate right after a stem boundary".
Change-Id: I0b71562727332217364f9ace85e8ac6ea3abc8b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196345
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
* Introduces a new option ValidationAlertStyle_NONE/SC_VALERR_NONE to
silently reject invalid values
(This is the behavior before c869fb5ea2)
* Sets the disabled state depending on "[ ] Handle invalid values"
(previously "Show Error on loading")
The patch is motivated by bug 159595 respectively the inconsistent
solution. Excel either allows invalid data or shows a message that
allows to change/reject/accept the input. But there is not way to
silently reject invalid data.
The new option does not survive round trips and will be reset to Stop.
Change-Id: I33c965aa7ba999e5850b80d35964b5383928349d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195563
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Implements the ODF 1.2 paragraph attribute style:writing-mode-automatic,
and supporting runtime features. When set, this attribute allows
programs to automatically recompute the paragraph writing mode when the
contents of the paragraph have been edited.
The ODF standard does not suggest any particular algorithm for
automatically determining paragraph direction. This implementation uses
the rules from Unicode UAX #9 3.3.1.
Currently, LO will only automatically change the writing direction when
new text is typed or deleted. Other known interesting cases are already
tracked as separate enhancement requests.
Change-Id: I49eecea36952588dc98f2a98ebce712cd2846c0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193547
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
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>
Implements support for ODF fo:text-align start and end in paragraph
styles. The new alignment options can be selected in the paragraph
dialog. Further user interface changes are tracked as separate bugs.
This change also adds START and END to css.style.ParagraphAdjust, which
is flagged as an incompatible UNO API change.
Change-Id: I2ee57f0029de7b794bc1ecd3eddbbd90af5dfdb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192932
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
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>
Add new paragraph justification options "Minimum glyph scaling"
and "Maximum glyph scaling" to improve typography, like DTP software
do, allowing to typeset visually better paragraphs, especially narrow
columns without unacceptably big word spacing.
* Add spin boxes to Alignment in paragraph formatting dialog window;
* Store properties in paragraph model:
css::style::ParagraphProperties::ParaPropScaleWidthMinimum
css::style::ParagraphProperties::ParaPropScaleWidthMaximum
Note: desired glyph scaling is already supported by ODF/UNO,
see css::style::CharacterProperties::CharScaleWidth.
* Implement visual layout of minimum and maximum glyph scaling,
limited by the available extra word spacing and letter spacing,
too.
Note: last line can exceed the paragraph width, because minimum
glyph scaling, also minimum letter scaling of the last line
haven't been applied there, yet.
* Add ODF import/export (loext:text-scale-maximum and
loext:text-scale-minimum, where style:text-scale is for the
desired text scaling).
* Add ODF unit test.
Note: hyphenated lines, lines with multiple portions haven't
been using custom glyph scaling, yet.
Note: resolution of glyph scaling is 1 percent, which will
avoid of overgeneration of font types using variable fonts.
Change-Id: I9b4576dde4303437b64e37202c47f888f94c3f67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190534
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
ODF has the attribute table:embedded-number-behavior to specify a
natural sort (19.628 part3 ODF 1.4). Its values are 'alpha-numeric',
'double' and 'integer'. LO has the attribute bool bNaturalSort in struct
ScSortParam. The ODF method 'integer' is not implemented in LO.
The patch maps the internal bNaturalSort=true attribute to ODF value
'double'. Until value 'integer' is implemented, it is mapped to value
bNaturalSort=true on import, as that makes at least a natural sort.
This is next step after commit 47eb7f4e4d
Change-Id: Ie8c66e6b2eb2bdf035f0b02ada6ef91b1d921fe7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190437
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
The bugdoc contains a format redline that changes the character style
from Strong to Quote and the font size from 24 to 36. Exporting to ODT,
loading the ODT and rejecting the redline, the font size is set to 24,
but the character style is set to default instead of Strong.
What happens is that the item set of the format redline contains the
necessary SvxFontHeightItem, but contains no SwFormatCharFormat. This is
because the ODT export writes no parents for char automatic styles,
because char formatting outside the redline table has 2 pool items for
such char formatting: a dedicated SwFormatCharFormat for the char style
and a separate SwFormatAutoFormat for other char props, so the ODT
export "knows" to ignore the autoformat parent and creates this markup:
<text:span text:style-name="...named style..."><text:span text:style-name="...automatic style...">t</text:span></text:span>
Fix the problem by explicitly exporting the parent style name when we
write an automatic style that is referred from the redline table (and
not from the body text). This is similar to what e.g. "frame" autostyles
already do, which also have parents. The result is this markup:
<style:style style:name="..." style:family="text" style:parent-style-name="Strong_20_Emphasis">
<style:text-properties fo:font-size="24pt"/>
...
<text:format-change loext:style-name="...">
which contains both the named character style name and the automatic
style, describing the direct formatting.
The ODT import side still needs fixing.
Change-Id: I19a67cf5e2c538cfcfa1b13097241954667d2c89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190181
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Load the bugdoc, the format redline at the doc end has the Quote char
style, reverting the redline should result in the Strong char style, but
results in no character style.
What happens is that XMLChangedRegionImportContext::SetChangeInfo()
assumed that the style name of the format redline is always an automatic
style, while it may be a named character style, too.
Fix the problem by splitting the style name into two parts in
XMLChangedRegionImportContext::SetChangeInfo() (named style, automatic
style) and then work with that pair in
XMLRedlineImportHelper::InsertIntoDocument(), similar to how
XMLTextImportHelper::SetStyleAndAttrs() works for <text:span>'s style
name.
The ODF export worked already.
Change-Id: I2fa1479a0d2463556e84be566967325584bc14f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189984
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Load the bugdoc, save as ODF, open the ODF, revert the format redline,
the font size should go from 36pt (new direct format) to 24pt (old
direct format), but it goes to 12pt (doc default).
What happens is that the format redline specifies the old direct format
via <text:format-change loext:style-name="..."> (referring to an
automatic character style), but this was not handled on import.
Fix the problem by:
1) Handling the new attribute in
XMLChangedRegionImportContext::createFastChildContext()
2) Looking up the already imported autostyle for the style name in
XMLChangedRegionImportContext::SetChangeInfo()
3) Creating a matching SwRedlineExtraData_FormatColl in
XMLRedlineImportHelper::InsertIntoDocument() when the format redline
is created in sw/ core.
Note that this means we have two autostyle names at play, the first is
T<number> and the second is effectively a pointer address as a string,
like 3cb7b270; FindAutoCharStyle() mapping from the first to the second.
Unfortunately both are just string references to the already imported
autostyle.
Change-Id: Ib0f18bad223f4320afe5aaa11ea713e610f6c029
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189845
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Add new paragraph justification option "Maximum letter spacing"
to distribute letters on (part of) the available blank area of the
justified line instead of overstretching word spacing, like DTP
software do.
This improves typography a lot, allowing typesetting visually better
i.e. more readable paragraphs, minimizing or removing rivers and
too big word spacing (which was common in columns or text without
hyphenation).
* Add spin box to Alignment in paragraph formatting dialog window,
(also add spin boxes for future Minimum and the alternative
percent-based Desired letter spacing, see CharKerning);
For example (only ASCII visualization!), 100% maximum letter
spacing adds a space character-width blank space between the
characters, including the original space:
0%:
Lorem ipsum
pellentesque dolores
vitae.
100%:
L o r e m i p s u m
pellentesque dolores
vitae.
Normal value: 3%-5% (or more for very narrow columns), which means
e.g. 1-2 twips (twip = 1/20 pt) letter spacing in a ~12 pt text.
Note: resolution of the custom letter spacing is only 1 twip yet.
* Store properties in paragraph model:
css::style::ParagraphProperties::ParaPropLetterSpacingMaximum
css::style::ParagraphProperties::ParaPropLetterSpacingMinimum
Note: desired letter spacing is already supported by ODF/UNO,
see css::style::CharacterProperties::CharKerning.
* Implement visual layout of maximum letter spacing.
Note: after the last character of the line, there is an
unwanted letter-spacing, yet (which is visible only with
big letter-spacing values).
* Add ODF import/export (loext:letter-spacing-maximum and
loext:letter-spacing-minimum)
* Add ODF unit test.
Note: hyphenated lines and lines with multiple portions do not
yet use custom letter spacing, yet.
Change-Id: Ieac9f21631b90ae46bed4501f12da0d15ed84d63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188653
Tested-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Export/import to/from odf clipboard the bitmap of the graphic bullets
numbering rules.
This is a follow up commit of: 66ed51712b
(Bug 128046 - List hierachy not maintained on copy'n'paste)
With this extra patch we can also copy/paste the graphic bullets
numbering rules together with their texts. However, this goes against
the MS Office and OnlyOffice behaviour, where copying text/paragraphs
only copies the text, not the list rules. So if we would just want to follow
that way, it would be enough to remove UNO_NAME_NUMBERING_RULES, EE_PARA_NUMBULLET
from SvxXMLTextImportComponentPropertyMap and SvxXMLTextExportComponentPropertyMap
See more info in:
https://bugs.documentfoundation.org/show_bug.cgi?id=166882#c5
Change-Id: I3c0b7389adf0d8efee95cc94f02905c3600342c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188532
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga@collabora.com>
... 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
SwXTextField must for the "SourceName" property convert from ProgName to
UIName on setting and reverse on getting, for consistency with the rest
of the sw UNO services.
This is annoyingly complicated because the "sPar1" of SwGetRefField is
used for numerous other purposes, including a bookmark name.
Revert writerfilter changes of commit 80877c7dc4
but keep the test.
With de_DE locale we now get "Überschrift 1 (user)" cloned style (same
as the reverted fix), and exported to ODF as "Überschrift 1"; the ODT
works when loaded both with the same and a different locale.
Unfortuantely an ODT created by versions on the 24.2 branch >= 24.2.4,
which used to work being loaded in the same locale but not in a
different one, stops working when loaded in the same locale with this,
so add an incredibly ugly flag to SwDoc because no SvXMLImport etc can
be accessed from SwGetRefField.
Move testTdf160402 to the new ooxmlexport26 because it also failed with
de_DE locale.
(regression from commit e45f187870362ed4448f4a9fb96883b8431887fb)
Change-Id: I6b7862f142d602544165d8b5a254bf8af28e527b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186228
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Implemented the ODF 1.0 style:script-type text property. This property
can be used by documents to influence which script type-dependent
attributes are used when rendering certain characters.
This implementation uses the following semantics:
- If unset, the behavior is as it was in previous versions.
- If set to latin, asian, or complex, those characters not mapped by the
ODF standard to a script type are treated as latin, asian, or complex,
respectively.
- If set to ignore, all characters will be treated as latin. This value
is intended to be used for interoperability with file formats that
don't implement script types (e.g. HTML).
Change-Id: If81a1390ee455fd971dea655d161d9c3f44fd08a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186309
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Before commit e61a179b4f (tdf#166627: embed
fonts everywhere we emit font data, 2025-05-23), embedding of fonts only
happened during export of content.xml, to avoid complexity of shared data
between different instances of SvXMLExport, created separately per stream.
The said commit introduced a way to pass the data between these instances,
and embedding now is done by any SvXMLExport instance that needs to emit
font-face-decls. Currently, only the first declaration of a used embedded
font gets its font-face-src.
But this is wrong, when the same embedded font in another stream, where it
is also used, does not reference its files. This patch allows all streams
to emit font-face-src for all fonts used in it. File duplication in ZIP is
avoided by passing the embedded file information between SvXMLExport, with
font file hash and its path in ZIP, instead of font names.
Change-Id: I7a62e50c086d8741dbc8aadf61d0f008bad916ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185720
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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>
Caolán McNamara