Add new paragraph justification option "Split compound words" for
custom compound-based "smart" hyphenation. Add compound-based "smart"
hyphenation support for Danish, Dutch, Esperanto, Estonian, German,
Norwegian, Swedish (and potentially, Icelandic, Finnish and
Latvian) languages by fixing Hunspell morphological analysis and the
associated lingucomponent code. (Previously compound-based "smart"
hyphenation was enabled only for Hungarian.)
With the new option it's possible to keep MSO/MS-DOCX interoperability,
also introducing a better hyphenation algorithm for several languages.
Details:
* Add check box to Alignment in paragraph formatting dialog window;
* Store properties in paragraph model:
css::style::ParagraphProperties::ParaIsCompoundBased
* Implement it by checking the new option in the previously
added commit f9f694f5d9f39c5801bc5fec45867252c293bbcb;
* Add ODF import/export (loext:compound-based);
* Add ODF unit tests by the new tdf173389_smart_hyphenation_nl.odt
and tdf173389_smart_hyphenation_hu.odt. Now use the previous
tdf119908_smart_hyphenation_hu for disabled compound-based "smart"
hyphenation, also the new tdf119908_smart_hyphenation_nl.odt.
Note: the Dutch test document results better compound-based
hyphenation in two positions.
* Add Hunspell patch to fix Danish, Dutch, Esperanto, Estonian,
German, Norwegian, Swedish (and future Icelandic, Latvian,
Finnish) morphological analysis for compound word constituents;
* hyphenimp.cxx hyphenate(): fix tokenization for consecutive
pa: elements, like resulted in the fixed Hunspell dictionaries.
Follow-up to commit f9f694f5d9
"tdf#173389 sw: add compound-based “smart” hyphenation for readability".
Change-Id: I4414bd588646ecf6dc86b77642833ac9c7820a98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211341
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
A hyperlink in Impress or Draw can carry a name, the Hyperlink
dialog's Name field: the description a screen reader announces, and
what PDF export writes as the link annotation's Contents. Saving the
document and loading it again lost it, and a tooltip carried by a
PPTX never arrived at all, so the link fell back to describing itself
by its own visible text.
Commit 8bf8873f30 (tdf#161583
drawinglayer,editeng,svx,sd: add "Name" to SvxURLField ...,
2025-03-06) gave SvxURLField the name and wired the export path to
it, but no filter. It is not reachable over UNO either, and both
filters go through UNO, so neither had anywhere to put it.
Give the URL field a Name property, and read and write it in both
filters: office:name in ODF, and the tooltip of a:hlinkClick in
OOXML. On import that tooltip becomes the name rather than
Representation, which TextRun overwrites with the link's text; a
shape's own hyperlink goes through the same import context and is
unchanged. A Draw or Impress hyperlink now survives both round trips,
as a Writer one already did.
Inserting a field into shape text does not reach
SvxUnoTextField::CreateFieldData: SvxUnoTextBase builds the stored
field with SvxFieldData::Create, which needs the name too, or it is
dropped again on the way in.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I43d44d55ab460547bbed8acd04d8938a4ee9a615
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/12270
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit f6218048f057a229eea7f15c198d850ceedd95dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211048
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The default drawing style names a theme color now, and a PPTX saved
to ODF and back came out with every shape green. A shape that really
did name a theme color lost the reference and came back plain.
A color item holds the color and the theme reference together.
Setting a plain color started from the item the shape inherits from
its style and overwrote the color alone, so the inherited reference
won. Clear the reference, which is what an explicit color means.
The ODF export repeats each shape's fill on a paragraph style,
applied after the graphic style, and the paragraph properties had no
complex color. Carry it there too.
A style's graphic properties took a complex color only when it was
the character one, matched by element name. Match on the context id,
which the fill and stroke colors share.
Add a round trip test through ODF and PPTX with a plain shape, a
themed one, and a themed one with a luminance modulation.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia9550222d18a243287240e4184666d78d0abdd22
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/10060
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 07cf37b104983f765d3e1005f677e0058df12026)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210510
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Nothing told a horizontal rule apart from an ordinary rectangle, so it could
not be laid out the way Word does; the marker is that distinction, and its
absence is what keeps documents written before it rendering unchanged.
The UNO property reports DEFAULT_VALUE while false, since ODF export only
writes direct values - else every shape and graphic style would carry it.
Also let the RTF import build a rectangle for a rule, as the VML import
already does, so both filters produce one model object.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Id2facd7bdc272197273462f0ad581537551234bc
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8657
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit dbe7dca2951640990d3febaf12a9c3118e15ec22)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209328
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
We had only one shared setting for the three script groups, which means
the same variation settings are applied to the three groups, which makes
no sense as they often use entirely different fonts.
Change-Id: I6f2a8b4d1c9e0357a6b2d8f4e1c7093b5a2d6e84
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209222
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
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
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 replacement raster image written next to an SVG primary was a
backwards-compatibility fallback for older ODF readers that could
not decode SVG. SVG has been in ODF long enough that current readers
handle it, so the PNG fallback is no longer worth carrying. To stay
cautious, only skip it when the document is written as ODF 1.4 or
newer.
Add testSvgPngFallbackOdf14 and testSvgPngFallbackOdf13 covering
the new behaviour. Both load odp/SvgImageTest.odp, which already
has an SVG primary with a PNG fallback. The ODF 1.4 case must
round-trip with no PNG file under Pictures/, while the ODF 1.3
case must still emit one.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ic3a54f46dd21db0d54f07d410243b885f8905a94
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4164
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 0dec43976c4410cb237b421813e5352ab94195d7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206353
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Bail when the factory does not provide a Footnote/Endnote service, which
happens when a text:note element is seen while importing into
Calc/Impress.
Then extend the mbListContextPushed check to cover the whole
endFastElement body. Originally that was already the case at:
commit 530897d64b
Date: Wed Oct 1 06:34:11 2008 +0000
CWS-TOOLING: integrate CWS swlists02
but at:
commit 5f4938d89d
Date: Wed Nov 15 10:03:54 2017 +0200
loplugin:flatten in xmloff
the early return, left DeleteParagraph and SetCursor(xOldCursor)
reachable on the !xFactory.is() path
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: Ibcaa525e314833660aa90bcbfe66461d626718cd
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2678
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit e060ac2fcc65ebd7b308066a3fbc579782a494f4)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205284
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
- 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>
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
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
When collecting autostyles, each added autostyle is compared with the
already added ones. If all the properties match, new autostyle is not
added, but an existing one is used.
For text columns, the comparison procedure only compared things defined
in XTextColumns interface, and ignored all properties of TextColumns
service - so, styles only differing in those properties were considered
identical, and only the first of them was saved and used for all cases.
This had never been implemented properly; all versions I tested, did the
same, so I doubt it was a regression. But indeed, it was a bug.
Change-Id: I0042067499a904a66ffb10b4f4ce4115d86e6cfb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192639
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
It produced incorrect markup like
<text:a ...><text:ruby ...><text:ruby-base>...</text:a></text:ruby-base><text:ruby-text>...</text:ruby-text></text:ruby>
after commit c50fbdceafdd4b857954f098e38cae03e8bc6064 (tdf#148198: merge
identical hyperlinks of adjacent text ranges on ODF export, 2022-07-18).
Only the inner Text portions need an 'a' element.
Change-Id: Ia5a0b671b5d454b0e9d4dab0295b57249db9f4dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192249
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This happens in exportTextRangeEnumeration, when URL ends (so the next
HyperlinkData is empty). A normal situation, warning is not needed.
Change-Id: I838785b58fb0ee2033d5604e373f3fe6f3bbaeca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192247
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Save the bugdoc in strict ODF, the exporter crashes due to an assertion
failure.
What happens is that strict ODF doesn't add the loext namespace alias to
the alias list, so we crash when we would write an loext attribute.
Fix the problem by simply throwing away the direct format of a format
redline when saving to strict ODF, just to please the validator.
If we're at it, also don't register the direct format of the format
redline in the autostyle pool in that case, since it would be
unreferenced anyway.
Change-Id: I0de9ee114be9ef67f97716cf5fd9aaa9f8757683
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190851
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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>
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
Open the input DOCX, save to ODT, the named char style of the format
redline is:
<text:format-change loext:style-name="Strong Emphasis">
while it should be:
<text:format-change loext:style-name="Strong_20_Emphasis">
This was not obviously a problem before, because both the import and the
export failed to encode/decode, but it'll be a more noticable problem
once we try to handle both direct format + char style, where autostyle
parent names are encoded and this was not, leading to inconistency.
Fix the problem similar to how it's handled for <text:span> elements for
export in XMLTextParagraphExport::exportTextRangeSpan() and for import
in XMLTextImportHelper::SetStyleAndAttrs(), by encoding/decoding on
export/import.
Also update sw/qa/filter/xml/data/format-char-style-change.odt, which
had a bad style name, missing an encode before export.
Change-Id: I2a9fae2c99c286d8c1c3a5e6af18f6f501e18089
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190151
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>
Load the bugdoc, 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 we have working DOCX import to store this in
SwRedlineExtraData_FormatColl's item set, but the ODF import/export is
missing.
Add the ODT export by:
1) Adding a new SwXRedlineAutoStyle that exposes the item set, assuming
it contains character properties, and create this in
SwXRedlinePortion::GetPropertyValue() if the RedlineAutoFormat property
is requested.
2) In XMLRedlineExport::ExportChangeAutoStyle(), write this item set as
an autostyle.
3) In XMLRedlineExport::ExportChangedRegion(), refer to this autostyle.
Note that similar to delete redlines, the format redline contains the
old formatting, the new formatting is directly in the document.
Change-Id: Iedd7416e5eefc4814199d60c4a6b68dbb76136e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189672
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
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>
... 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
László Németh