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
This fixes a longstanding problem
exposed by 25.8.0 commit 33f644074e
OOXML handling of 1904 null date for charts with internal data provider
The problem was that size attributes for chart:chart
were being collected before table:calculation-settings was written out.
So the size was lost during import
because it was written into table:calculation-settings
instead of chart:chart
make CppunitTest_chart2_export3 CPPUNIT_TEST_NAME=testTdf170215_nullDate
Change-Id: Ie28cfb09945734fac7a49e8eef52831d933b430a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203220
Reviewed-by: Justin Luth <jluth@mail.com>
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>
Instead of exporting all table styles, export only the ones which were
edited. Note that this will export the edited table style even when it
is not used in the document, this is intentional.
6fc9264fd9 was the original commit, but
got reverted because of a failing test
Change-Id: I3fcc5948a401e1ff4b2c620f21ae265476c89f0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200028
Reviewed-by: Karthik Godha <karthik.godha@collabora.com>
Tested-by: Jenkins
In case of 2 characters string text,
with a delimiter as text and a blank width string like
"-"_)
the delimiter is now treated as text
Add qa test with format of bug report:
[>0]#,##0_);[<0](#,##0);"-"_)
Change-Id: Idd4542bd186c6b6b348f6716bee2fd5055f2c83f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199314
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@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
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>
- Introduce 'SvxAutoFormat' which combines the common funtionality of
Writer and Calc Autoformats.
- Replace module specific 'AutoFormat' dialog and preview with shared
dialog and preview in 'svx'.
- tdf#49437: Load and Save Autoformats through XML instead of
'autotbl.fmt'.
- New Dialog to edit and create table styles shared b/w Writer and Calc.
Change-Id: I7fa108e527141c05703e0e14298eea818fd10378
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190024
Tested-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
> xmloff/source/text/txtimppr.cxx:615:9: error: ‘nVertOrient’ may be used uninitialized [-Werror=maybe-uninitialized]
> 615 | switch( nVertOrient )
> | ^~~~~~
So use the same approach for nVertOrient as was already used for nVertOrientRel
in 7ab4c76e73 "INTEGRATION: CWS warningfixes02
(1.18.10); FILE MERGED", initializing it to 0 aka css.text.VertOrientation.NONE.
Change-Id: Ibf9b259f87fb030e426664bc3bbd63fc1bfb0797
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197832
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
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>
Currently any object anchored in a Writer header / footer which isn't
actually used in the document isn't put on the SdrPage and thus doesn't
have a ZOrder; this results in a spurious z-index="0" attribute, where 0
is a perfectly valid value that is typically already used by a visible
shape and is thus duplicated, which is invalid.
Fix SvxShape::getPropertyValueImpl() and SwXFrame::getPropertyValue() to
check that it has a parent, and
XMLTextParagraphExport::addTextFrameAttributes() to properly check that
the property has a valid value.
There is one possible use case for producing a z-index for something
that isn't visible: when it's anchored in a delete tracked change, and
we want to preserve the order relative to other shapes in the document.
However, it turns out that in SdXMLShapeContext::AddShape() and
XMLTextFrameContext_Impl::Create() the z-index of anything anchored in a
delete redline is already explicitly ignored, so it's a non-issue.
Change-Id: I37e461ebcd3e4546c60f421054ee39c053919267
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197474
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 7ffd4f7a27b9b2bc55ac3ddb7333dbaf3d48109c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197622
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins
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>
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
found by converting tdf34406-1.odp to pptx and running officeotron on the output
INFO - Validating part "/ppt/slides/slide4.xml" using schema "29500T/pml.xsd" ...
ERROR - (slides/slide4.xml:2 col:24,296) cvc-datatype-valid.1.2.3:
'-4900000' is not a valid value of union type 'ST_PositiveFixedPercentage'.
The import data in content.xml looks like:
<style:style style:name="ce8" style:family="table-cell">
<style:graphic-properties draw:fill="solid" draw:fill-color="#808080"
draw:opacity="-4900%"
where the opacity value is wildly out of range. So validate on input.
Change-Id: I1d9146a3f38f975a5e229f63e17fca6fb435439b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194950
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 80c58f15baf79f19b954b1199cbca9c2f3dcf8bf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194952
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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
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
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>
Caolán McNamara