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>
In LO 7.5, ORichTextModel changed the app default to use a flat border
(in order to better match how PDF/print looks)
while the file-spec's default for undefined borders is 3d,
so during import time we ALWAYS need to specify 3d as the border.
The patch replaces 25.2 commit 5a617f77ee
tdf#156707 xmloff import: always provide ControlBorder property
which wasn't wrong, but just was incomplete.
It only handled the situation where there was a fo:border element
which didn't specify 3d/flat/none,
but didn't handle the situation where there was no fo:border at all
in style:graphic-properties.
[On export, since the 3d property is the default value,
fo:border is not even provided as something to be exported,
and therefore only "solid" and "none"
are ever exported as fo:border qualifiers.]
I modified the unit test to remove the fo:border
by clearing the unused-by-3d green border colour
(although the green was seen if the wrong flat border was assigned).
make CppunitTest_xmloff_style CPPUNIT_TEST_NAME=testTdf156707
Change-Id: I70718fe964a7c3578f8edbf8591fe2e3417ec60b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185619
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
To avoid of rivers and too much hyphenation, add minimum
and maximum word spacing options, similar to XSL-FO/CSS
and DTP software.
Only limiting hyphenation was implemented: hyphenation
of the words are disabled, if it's possible to expand
or shrink the spaces of the line within the values specified
by the maximum and minimum word spacing. First try to apply
the minimum word spacing, and if not possible, then the
maximum word spacing.
Note: maximum allowed shrinking has been applied for the
hyphenated lines instead of the minimum to remove the
hyphenation, yet. With the suggested default word spacing
values, this results no or minimal differences.
New UNO paragraph properties:
com::sun::star::text::ParaWordSpacingMinimum
com::sun::star::text::ParaWordSpacingMaximum
New ODF paragraph attributes:
loext:word-spacing-minimum
loext:word-spacing-maximum
New paragraph settings on Text Align pane:
Minimum word spacing
Maximum word spacing
While the desired word spacing got "Desired" label.
Note: suggested values of minimum, desired and
maximum word spacing are 80%, 100% and 133% (default
values e.g. in Adobe InDesign), in narrow columns e.g.
60%, 100% and 150%.
Follow-up to commit 7d6696757d
"tdf#159923 sw cui offapi xmloff: add custom word spacing".
Change-Id: I7f2a07f7fdb634cb16cdd8c2c937ca911b968405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184595
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
Add com::sun::star::text::ParaWordSpacing UNO
and loext:word-spacing ODF extensions to set
desired word spacing of a justified paragraph
relative to the width of the space character,
like DTP software do.
Add Justification section and "Word spacing"
spin box to the Text Align pane of paragraph settings.
This extends not only the smart justify interoperability
feature for custom shrinking (until 0%), but for custom
expansion, too, until 1000%, like Adobe InDesign do.
Note: this value hasn't been applied in the last
paragraph line, yet.
See also XSL-FO/CSS word-spacing and
commit 7d08767b89
"tdf#130088 tdf#119908 smart justify: fix DOCX line count + compat opt."
Change-Id: I06f771335135e4682a1d1abfc9a247dbe4bc6b66
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184187
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
manage SvXMLImportPropertyMapper with unique_ptr instead
of rtl::Reference, which avoids a bunch of ref-counting
traffic
Change-Id: I1e0e95408cdd5dc4271fa72178e57087737eb062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183751
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Add new hyphenation options to adjust hyphenation, like DTP software do
in accordance with typographic requirements:
– Paragraph/Column/Page/Spread end zone spin boxes to Hyphenate Across
section of Text Flow pane of paragraph settings;
– loext:hyphenation-zone-always, loext:hyphenation-zone-column,
loext:hyphenation-zone-page and loext:hyphenation-zone-spread
ODF extensions;
– widorp.cxx, guess.cxx: handle Column/Page/Spread end zones;
– guess.cxx: handle Paragraph end zone (without portions, yet).
According to their typography, languages with long words need better
adjustment of line break of the last full paragraph/column/page/spread
lines, than simply disabling hyphenation by the recent ODF hyphenation-
keep or its equivalent MS Word OOXML extension. DTP software use
paragraph and column/page/spread end zones to adjust the hyphenation
zones in the last lines, for example, setting Column end zone to the
150% percent of the Hyphenation zone, resulting less hyphenation, also
less short words parts at the end of the columns, pages and spreads,
increasing readability.
Note: the default OOXML hyphenation zone 18 pt (or its MS Word variants,
for example 21.25 pt) disables single letter or narrow 2-letter (li-,
fi-, i.e. fi ligature) hyphenations at 12 pt font height. Setting 27 pt
for Column end zone, all 2-letter hyphenation is disabled in last lines
of columns and pages.
Note: textflow.ui needs multiple adjustment definitions for correct work
of the multiple spin boxes.
Change-Id: I37bbb4da30de0ec75eb8636f70d8e16588c56ed1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183565
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
When loading a table, each cell contains an extra node, which is dropped
when finalizing the cell. The removal of the node calls SwDoc::CorrAbs,
which it turn calls MarkManager::correctMarksAbsolute. The latter looks
through all existing bookmarks, checking if they need to be corrected.
In documents with lots of tables and lots of bookmarks, the time taken
by eack following call to SwDoc::CorrAbs grows quadratically.
We know, that these extra nodes in cells do not affect bookmarks, and
it is safe to just skip these specific nodes from bookmark correction.
This speeds up loading bugdoc by 40% in my testing.
Change-Id: I61b587d04c9ae2301d9fef497885fb76c2d3ae74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183348
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
cache LocaleDataWrapper because otherwise we spend quite a bit of
time doing function-pointer-symbol lookups.
Change-Id: Ic1bd07dabac95a2e1bdad70cffbc2b4cabdc62ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183221
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
When processing a report on failed ODF save, it can be tricky to find
reproduction steps. A typical source of errors is some uncaught
exception. Currently we just report which stream failed to save:
0x70c23(Error Area:Sw Class:Write Code:35) arg1=SfxBaseModel::storeSelf: 0x70c23(Error Area:Sw Class:Write Code:35) arg1=styles.xml at sfx2/source/doc/sfxbasemodel.cxx:1735
Improve this to also report what would appear on stderr in a dbgutil
build:
com.sun.star.lang.IllegalArgumentException: "SwXMLExport::exportTheme() failed at sw/source/filter/xml/xmlfmte.cxx:189"
In case e.g. the theme export throws an exception for testing purposes.
Change-Id: I85ec1ac4f932851401aa3b25a753219eb20638a4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182831
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Add loext:hyphenation-keep-line to the ODF export/import
to support HyphenationKeepLine, i.e. MS DOCX compatibility
option useWord2013TrackBottomHyphenation=false, where not
the full hyphenated line, but only the hyphenated word
is shifted to the next text block.
Add unit tests for hyphenation-keep-type="page" and "spread"
with hyphenation-keep-line="true" support.
Follow-up to commit 3e02ffb76c
"tdf#i165354 sw offapi DOCX: implement HyphenationKeepLine – part 1".
Fix unit test testTdf132599_spread, which loaded tdf132599_page.fodt
instead of tdf132599_spread.fodt (duplicating testTdf132599_page).
Restore unit test testTdf160518_auto_in_text_body_style, which was
removed by accident in commit 3e02ffb76c.
Silence the linguistic warning of HyphKeepLine, according to the
commit d25de4a046
"silence unknown property 'HyphNoLastWord'... etc warnings".
Change-Id: Ibb9643f8e20ee2a1456c4d62b901e4c66b57c341
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182424
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
László Németh