When Base loads forms, it flattens ParagraphAdjust values into
GUI-specific awt::TextAlign values. The code that performed this
remapping was missing some recently-added values, causing apparent loss
of column alignment after save.
This change adds the missing values. In addition, this change adds unit
tests for the conversion code, and fixes a long-standing typo bug that
made values fail to round-trip.
Regression due to the following commit:
commit 5d1b2baaa9
Author: Jonathan Clark <jonathan@libreoffice.org>
Date: Tue Oct 21 02:14:26 2025 -0600
tdf#118350 [API CHANGE] Implement start and end paragraph alignment
Change-Id: Ica27870a952c6ec77360f416e112724b4943a016
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206816
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
In report builder if the charts contain date or time
then the generated chart appear without content.
This is fixed by adding appropriate handling of date
and time value cases.
Change-Id: Idfa0e03645e1e8130707fc541b155fd53311572d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206232
Tested-by: Jenkins
Reviewed-by: Vissarion Fisikopoulos <vfisikop@libreoffice.org>
On export, always write ControlBorder and ControlBorderColor to the
auto style for control shapes, even when the property state is
DEFAULT_VALUE.
On import, when fo:border is absent, apply the control model's default
border to the shape.
a) New document, user sets flat (2) border:
The constructor default is 2 (flat) but getPropertyDefaultByHandle
returns 1 (3D). Property state is DIRECT_VALUE and the filter exports
fo:border as before. On reimport fo:border is present and applied.
No change in behavior.
b) New document, user sets no (0) border:
Same as flat, DIRECT_VALUE, exported by the filter. No change.
c) New document, user sets 3D (1) border:
1 matches getPropertyDefaultByHandle so property state is
DEFAULT_VALUE and the export filter would previously skip it.
Now export always adds adds ControlBorder explicitly, so fo:border
is written. On reimport fo:border is present so applied.
d) Old document (pre tdf#152974) with no fo:border:
These documents never wrote fo:border for 3D because that was the
real default. Now on import the importer detects the missing
fo:border and queries getPropertyDefault("Border") for the control
which returns 1 (3D) for text controls, restoring the original
border. On reexport the exporter writes an explicit fo:border.
e) Label controls (tdf#167358):
Labels default to no (0) border. Their getPropertyDefault
returns 0, so the importer applies no border when fo:border is
absent, so this fix effort shouldn't cause that problem again.
Change-Id: I365adf84e9d26ae3231331230178381d31bfa829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200685
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
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>
SetTextBoxes(true) is never called because it checks the shape's
SdrObject, while previously this code was in
SwFrameFormat::SetOtherTextBoxFormat() where it would be called a second
time for the text box SwFrameFormat which has the SwFlyDrawObj.
SwTextBoxHelper::getCount() can't ignore the text boxes if the flag is
never set; this ends up confusing
ShapeGroupContext::popGroupAndPostProcess() (and causes tests like
testTdf84695 to fail with the fixes in the next commit).
Because shapes with text boxes are sorted again with this, testTdf146272
and testTextBoxLoss need adapting.
(regression from commit 504d78acb8)
Change-Id: I80c375d900a10f1956cd112d60c3f25332c485ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197594
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 327e92c78603e011e7ddf8b57749dfd9e690addf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197729
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>
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
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, 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
... 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>
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>
The bugdoc has <del>AA<format>BB</format>CC</del> in it, DOCX import
works, but exporting to ODT turns the format-on-delete redline into a
plain "format" redline.
What happens is that various code only checks the m_eType of the first
SwRedlineData of an SwRangeRedline, so format-on-delete is handled as
format. But this is not correct: if the format-on-delete is to be
accepted, then it's just a small detail that there was a format on top
of it: the result should be text deleted from the document on accept,
not accepting the the format changes and leaving the text in the
document.
Fix the problem by:
1) Extending SwRangeRedline::Hide() and SwRangeRedline::Show(), so when
the ODF export moves delete redlines to their own toplevel SwNode
section, so it can refer to these ranges using a single SwStartNode
index, this move happens for format-on-delete as well, not just deletes.
2) Then can extend SwXRedlinePortion::GetPropertyValue()'s
lcl_GetSuccessorProperties() to produce an XText for the deleted
range of a format-on-delete redline.
3) Finally consume this new XText in
XMLRedlineExport::ExportChangeInfo().
Note that this way a format redline can now have its own XText (in case
it's on top of a delete), but we want to export the text only once, so
restrict the content export for a redline to the 'delete' type.
Change-Id: I91902a2ae4b464ace41717a196d19530be9d84d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185551
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
When a pdf file is opened with pdfium and then saved as odg, each page
is saved as a draw:image of the pdf. But since no page number info was
given, when opening the odg file, all the pages are shown as the first
one.
This adds a loext:page-number to the saved odg and the logic to load a
specific page from an embedded pdf.
Added loadGraphicAtPage to XGraphicStorageHandler.
Change-Id: I398b7ad7f03cc7fb930a4e7b7620c6f238b41c0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181066
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
and extrusion-specularity.
In ODF strict always value 'draw:MetalODF' was written. Changed the
logic to write 'loext:MetalMSCompatible' too, depending on eMetalType.
Using a QName as value requires a namespace declaration for the prefix
'loext'. That is now written directly at the element, not as global
declaration, to restrict its scope to the element. A global declaration
would hide when attributes or elements are accidentially written in
'loext' namespace.
The pattern for nonNegativePercent had missed the percent sign.
The export is adapted to write the percent sign.
Validation is skipped for save to ODF 1.3, because currently the
implicit validation uses always latest ODF version, see tdf#163806.
Tests are extended to cover ODF 1.4 and value draw:MetalODF.
Change-Id: I836d11b9cd327b9772e800d9797e04e1613ab2f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176246
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
The problem was that 3d textbox form controls
were imported as flat.
The default value for ControlBorder is 3d.
Since caolan's 7.5.4 63b8e8bda2,
all textboxes are initially created with a flat border instead of 3d.
Since 3d is the fo:border default (and never specified),
the newly created control had no override to force it to 3d.
So this patch forces passing a ControlBorder property.
On export, since the 3d property is the default value,
ControlBorder is no even provided as something to be exported,
and therefore only "solid" and "none"
are ever exported as fo:border qualifiers.
make CppunitTest_xmloff_style CPPUNIT_TEST_NAME=testTdf156707
Change-Id: Ib4541d5e3599dc42af6055062fd709e105bf5d14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174754
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
ODF uses in several places data type 'angle' (18.3.1, ODF 1.3). That is
a double followed by unit identifier 'deg', 'grad' or 'rad' or a unit
less value in degrees. LO uses in the API angles in degrees, 1/10 of
degrees and 1/100 of degrees in data types 'double', 'short' and 'long'.
Without the fix LO does not interpret the units, but takes only the
number part.
Change-Id: Ib3f2a518a25199e3cf7a7a8572e169785f75c427
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169360
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
.. and draw:rotation in <draw:hatch> element.
ODF 1.1 has not specified the syntax of datatype 'angle'. Since ODF 1.2
it is specified as double with unit "deg", "grad" or "rad", or without
unit. The unit-less value is specified to be in degrees. But OOo, AOO
and all LO versions had written the value unit-less in 1/10th of a
degree in some cases.
To fix it, LibreOffic will be enabled to read units. When then the
active versions are able to read units, starting with the then actual
version, LibreOffice will write angles with unit 'deg'.
This has already be done for gradients, see tdf#89475. This patch
starts the first step to make LibreOffice able to read units for
dr3d:end-angle (UNO D3DEndAngle) and for draw:rotation (UNO
FillHatch.Angle). I have not found further cases of writing 1/10deg.
The patch still writes unit-less 1/10th of a degree for export to
ODF 1.3 and earlier. When it is time to write unit degree or when
LibreOffice supports the next ODF versions, some places need to be
adapted. They are marked.
The converter convertAngle is renamed to convert10thDegAngle() to
indicate, that it is special. The parts, which were specific to
gradients are moved to the gradients, so that it is now usable for
dr3d:angle and draw:rotation too.
I intend to write next a patch that enables LibreOffice to read angle
units for cases where LibreOffice already writes unit-less values in
degree. That is not so urgent, but to bring LibreOffice nearer to ODF,
reading angle units should be implemented nevertheless.
The file xmlbahdl.hxx is moved from xmloff/source/style to xmloff/inc
to have access to it from xmloff/source/draw.
Change-Id: I8ffc2735f8bcfefb86efa80eb05f900c32403f31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168336
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Open the bugdoc, see that the image is roughly half of the page width,
right click, properties, UI shows that the width of the image is 5% of
the width of the entire page. This only happens if tools -> options ->
writer -> general sets the UI units to points, the default cm case is
fine.
This went wrong with commit 9e8712ed6f (sw
image dialog: fix fallback width/height for images with relative sizes,
2022-03-17), because the layout size started to matter more after that
commit. This lead to the nWidth !=
m_xWidthED->get_value(FieldUnit::TWIP) check in SwFramePage::Init() to
be true, because 11906 * 0.48 is 5714.88, so you got 5714 in the layout,
but got 5715 with rounding in SwFramePage::Reset() (which tries to calc
the page width based on the 48% and the fly width). And once we had that
mismatch, we went down the wrong path.
Fix the problem by using rtl::math::round() in SwFlyFrame::CalcRel(), so
the relative width twips value is 5715 everywhere: once we have
consisteny, the UI value is correct, too.
Note that the original bugdoc needs more fixing, this just fixes the
bugdoc where KeepRatio is false.
Change-Id: I1e8782c95a0cf9d97375c36d41134735c01f3e46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167916
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
With import of shapes in 3D-mode from pptx files, the internal values
for light level might be outside the range 0..100 and thus not allowed in
ODF. These high levels are needed to get a similar rendering to
MS Office.
The export to ODF clamps them now to the allowed range.
I do not intend to change the export to loext namespace, because the
extrusion mode of custom shapes needs a totally new handling. But that
will not be possible timely for version 24.8.
Change-Id: I839903cbaf1b304c1e0c4374080963bc70352e61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164948
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Conversion of hex/dec colour notation
(example entry Color( 255, 255, 255), Color(0xFFFFFF) - COL_WHITE)
For the other available colour definitions.
Change-Id: I9eed0cd64adcbc8d25e1c22143a000906a457586
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163729
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Jonathan Clark