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>
ODF has no name for this chart type, so the file says two things at once, the
way a histogram already does: chart:class names the scatter chart, which is the
nearest a reader that knows nothing of correlation circles can make of it, and
coext:class beside it names the type itself. A reader that knows the coext name
gets the chart back as it was saved.
The series need no new shape in the file. The feature column is the range of
the series and the two dimension columns are a domain each, which is where a
bubble chart already keeps its x and y values, so both the reading and the
writing of them follows the bubble path rather than a new logic.
The schema the tests validate against lists the values coext:class may take, so
the new one is added there beside the histogram.
The test document is one block of five columns: three features and then the two
dimensions, the shape the wizard asks for. The test checks after a round trip
that the chart type came back, that the file carries both class names, and that
every series still holds its feature column beside the two dimension columns.
Change-Id: Iac73ff357c7490b4f38a4390c63948cf148d8585
Signed-off-by: Dennis Francis <dennis.francis@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/8106
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 4e59ea1c83e61b8dc2647f9a915884f9d461165d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210498
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A slide's picture placeholder can hold text the author typed instead of an
image, which PowerPoint displays. Impress dropped that text on import and
wrote nothing at all for such a shape on save. To reproduce, type into a
picture placeholder in PowerPoint, save, open the file and save it again:
the text is gone from the shape, and the shape from the file.
What a placeholder is now lives in the page's presentation object list, and
what represents it follows what it holds: a graphic object for a picture, an
SdrObjKind::OutlineText object while it holds text, the placeholder itself
while it holds nothing. It changes over when a file states such text, when
that text is deleted again and the prompt comes back, and when an image is
put in. Text arriving another way, through the API, is caught by the new
SdrPage::onEmptyPresObjFilled and switched at the next idle, so that route
needs a spinning scheduler; what a save writes is right either way. An object
in text edit is left to that edit, which is where it changes over: the idle
pass walks every page, so it asks each object rather than trusting the one
that asked for the pass - in a shared document another view holds it. That
switch is the model's own and covered by no undo step - it answers for a
document the API changed, not for anything the user did.
What the file says about the shape travels with it both ways, the graphic
items included, so an outline a picture placeholder is clipped to is still
there when a picture arrives. It is not written while the placeholder holds
text: the file says text box, and a text box states no geometry to clip a
picture to.
PPTX writes it as the placeholder it is, with the text it holds. ODF states
the class of what represents it, so the placeholder's own class travels
beside it as coext:placeholder-class, and a reader that ignores the
extension sees an outline placeholder with the text.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I0f3353115e56d63a4158ebaeb5689689499894bb
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9441
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 7921401ae48188568e1016db00bd90256d666a6a)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210329
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Commit 67ba6ccd5a (tdf#140912, tdf#159219:
fix import of graphic placeholder with custom prompt, 2024-01-17) left
the prompt out of ODF for want of a representation, so a reload replaced
an authored one with our own localized default. It now travels as a
coext:placeholder-prompt attribute beside presentation:placeholder, on
draw:frame and draw:page-thumbnail, written when saving with extensions
and added to the extended schema so the round trip validates. It is
also listed in the Collabora ODF extensions notes.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I12b51ff2bc103e5c26e94558802064919c7289dd
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9070
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 6b1b6331ada0cc948e880eb83db5506f8bf1aa9c)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210297
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Carry the GraphicClipPolyPolygon UNO property on graphic-object
shapes through ODF save/reload as a new <coext:graphic-clip-poly>
child of <draw:frame> with the polygon serialised as svg:d (the
same SVG d-path encoding draw:path uses). A new XML_GRAPHIC_CLIP_POLY
token is added in lockstep across xmltoken.hxx, xmltoken.cxx, and
tokens.txt so the XMLTokenEnum and FastParser tables stay aligned.
The element is taken before the frame decides what its shape child is, and
applied when the frame ends: an empty presentation object has no draw:image for
the polygon to follow, so the polygon comes first and the shape it belongs on
does not exist until then. A placeholder saved to ODF came back unclipped
otherwise, which is the shape of file our own save writes.
It goes on the image the frame keeps, which is not always the last one it saw:
a frame with a replacement image holds several, and the ones that lose are
taken off the page and disposed.
Export goes through a new ImpExportGraphicClipPoly helper called
from ImpExportGraphicObjectShape alongside ImpExportSignatureLine
and ImpExportQRCode (under ODFSVER_EXTENDED). Import is handled
in SdXMLFrameShapeContext::createFastChildContext, which is where
<draw:frame> children land - the GraphicObjectShape sub-context is
nested inside that and never sees this sibling directly.
The element is added to the extended ODF schema next to
loext-signatureline and loext-qrcode, so a document carrying it
validates, and is listed in the Collabora ODF extensions notes.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: Ib9ae65c1b6f2d8fdb28ae086fd7e2be2f8a8ee24
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/9191
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit b7a56041afda6b658b6b16bb51a5939295c40d75)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210122
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
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
Since commit 3da86d8987 ("tdf#114488
Rank multiple images also for flat odf") GetMimeTypeForExtension()
resolves the "svm" extension to the "image/x-svm" media type. As a
side effect SvXMLGraphicHelper::implSaveGraphic() now stamps that
non-empty media type on the Pictures/*.svm package stream.
ZipPackageStream treats every non-text media type as an
already-compressed format and stores the stream without deflate
(ZipPackageStream::setPropertyValue, "MediaType"). Before the above
commit the svm media type was empty, so the stream kept being
zip-compressed.
But SVM, like EMF/WMF, is an *uncompressed* metafile and must be
zip-compressed. The aCompressiblePics allowlist already contained its
sibling metafile formats (image/x-emf, image/x-wmf) but was missing
image/x-svm, based on the wrong assumption that the ZBITMAP stream
option compresses it -- ZBITMAP only compresses embedded bitmap
actions, not the vector action stream.
Add image/x-svm to the allowlist. A vector SVM that was stored
uncompressed at 8 MB now deflates to ~0.6 MB again (92%), so files
with SVM graphics -- and "Tools > Minimize Presentation" on them --
shrink as expected, losslessly.
Change-Id: I4b67f9a87e4a54c03f16b7babaf2d0ede1202754
Signed-off-by: Balazs Varga <balazs.varga@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4337
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit 2364fc9aeb36ea5edbb38f3fde9e391b481839e3)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206689
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
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
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>
we will do this anyway, and its already common place
to explicitly call collectAutoStyles before places
it is additionally needed for various other reasons.
collectAutoStyles returns early if already called.
Change-Id: I0ba36897963ccf5f9394eedc8c4f5a102c73c6c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192437
Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@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
Justin Luth's comment on the original patch (to which I made
some minor tweaks to adapt to the new simplified API):
"The zoom values set in the view properties by LibreOfficeKit
are technical zoom levels that depend on the current screen DPI.
They do not reflect the logical zoom level that the user sees.
This has been especially problematic for high DPI screens,
where the technical-zoom-level is completely different from
the human-zoom-level - and thus a weird value is exported.
Instead, export the zoom value that LOK presents to the human.
Since LOK doc_setClientZoom always calls setZoom for bAll sheets,
it is sufficient to only have a single export zoom variable.
COOL doesn't have a "View - Page break" view,
so PageZoomValue is irrelevant.
Of course, even in desktop mode it seems irrelevant to me...
I'm rather worried about the "IsLOKExport" flag interferring
with normal, synchronous operations
during a background/download ODT save.
Those WriteUserDataSequence are not at all
limited to file-save operations.
They just fill in property values
for 'whatever' wants to capture the view settings.
So if some other process runs in parallel with the save,
then it will get the export zoom values,
rather than the operational zoom values it was expecting.
But I don't see any way around it since xmloff
just dumps properties as the way that it saves an ODS.
make CppunitTest_sc_tiledrendering \
CPPUNIT_TEST_NAME=testCellInvalidationDocWithExistingZoom"
Signed-off-by: Mohit Marathe <mohit.marathe@collabora.com>
Co-authored-by: Justin Luth <justin.luth@collabora.com>
Change-Id: I54282e4d28dbe489ca0ea7c080036391faa4704c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188674
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Embedded fonts may appear several times during document loading. Now,
they activate immediately after current element was processed, and a
portion of the embedded fonts was collected. The activation may also
happen several times during the load process, each time refreshing
fonts in all windows, which takes significant time.
This change tries to not activate collected fonts in the destructor
of EmbeddedFontsHelper, but to send the list to the model. The model
accumulates the lists in its medium, and only activates late in the
loading process, when all the embedded fonts are collected.
Change-Id: Iff188e84e259206541bcc94880d8aead2b72715a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189310
Reviewed-by: Mike Kaganski <mike.kaganski@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>
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>
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>
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
László Németh