found by converting tdf34406-1.odp to pptx and running officeotron on the output
INFO - Validating part "/ppt/slides/slide4.xml" using schema "29500T/pml.xsd" ...
ERROR - (slides/slide4.xml:2 col:24,296) cvc-datatype-valid.1.2.3:
'-4900000' is not a valid value of union type 'ST_PositiveFixedPercentage'.
The import data in content.xml looks like:
<style:style style:name="ce8" style:family="table-cell">
<style:graphic-properties draw:fill="solid" draw:fill-color="#808080"
draw:opacity="-4900%"
where the opacity value is wildly out of range. So validate on input.
Change-Id: I1d9146a3f38f975a5e229f63e17fca6fb435439b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194950
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit 80c58f15baf79f19b954b1199cbca9c2f3dcf8bf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194952
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
found by converting tdf43054--1.odp to pptx and running officeotron on the output
Validating part "/ppt/presentation.xml" using schema "29500T/pml.xsd" ...
- (ppt/presentation.xml:2 col:1,116) cvc-minInclusive-valid:
Value '900113' is not facet-valid with respect to minInclusive '914400' for type 'ST_SlideSizeCoordinate'.
We get the slide size from the master page, and this page appears not to have any
width or height values at all, so use a useful value in that case.
Change-Id: I3624b4ba79ec4919655995c20d729b22ff443641
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194701
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 2d82d56d3f536ba2bbe0496c4f6488e61a2247cb)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194752
Tested-by: Jenkins
TextWritingMode and ControlWritingMode are suppressed when
ShapeWritingMode exists.
With commit c70ee4a6b9 we have in addition
GraphicWritingMode2. Thus suppress them in that case too to avoid
duplicate attributes.
Change-Id: Ie7064e2dcea3a6dccc081f03bf027c1e7a261bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194371
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
Implements the ODF 1.2 paragraph attribute style:writing-mode-automatic,
and supporting runtime features. When set, this attribute allows
programs to automatically recompute the paragraph writing mode when the
contents of the paragraph have been edited.
The ODF standard does not suggest any particular algorithm for
automatically determining paragraph direction. This implementation uses
the rules from Unicode UAX #9 3.3.1.
Currently, LO will only automatically change the writing direction when
new text is typed or deleted. Other known interesting cases are already
tracked as separate enhancement requests.
Change-Id: I49eecea36952588dc98f2a98ebce712cd2846c0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/193547
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Tested-by: Jenkins
After recent commit 851fb75779
recheck these directories in include/ again
to test drive the new --headersfwd mode of bin/find-unneeded-includes
Change-Id: I0ede437c4f9958cd98210ed1760a5b98ea8bd1ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192377
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
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>
Currently, we do not correctly implement fo:text-align "start" or "end".
Support for these attribute values is faked at the parser level by
always treating "start" to mean "left", and "end" to mean "right".
In addition to this, previously, the ODF serializer always printed
"start" for left alignment, and "end" for right alignment. This behavior
is harmless for documents that only contain LTR paragraphs, but mirrors
the alignment of all RTL paragraphs per the ODF standard. Other programs
cannot view these documents as intended.
This change updates the ODF serializer to instead print "left" for left
alignment, and "right" for right alignment, reflecting our actual
document layout.
Change-Id: I3a1134924f4adf71b7a0ea3f672e8c1580770841
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192858
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
The problem was wrong identification of the shape type, because of
unreliable use of fragile Z-order.
XMLShapeExport::exportShape used xShape's Z-order to get the info
collected for current xShape. Value of Z-order is calculated in
SwXShape::getPropertyValue; it takes into account text boxes of
shapes, which affects the correction in SwTextBoxHelper::getOrdNum.
The correction results in several different objects returning the
same Z-order. And in the specific document, the information that
was collected for a rectangle object, was used for an object of
different type.
Instead of trying to find a smart way to continue using Z-order,
this change uses XShape itself as the key into the map of info,
similar to how XShapes objects are used as keys into ShapesInfos.
Change-Id: Iacbc101623504db4290ad2c283351c4141b2d1b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192796
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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
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>
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>
What is actually reported is Use-of-uninitialized-value but I don't see
a problem of an uninitialized value. But I do see that nVal is -2147483648
so presumably that's the actual problem.
Change-Id: I9e5bdcb0e8fdfc6274888c1d7f1c94a65a8613d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192238
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@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
...(like the Emscripten build), see the HAVE_FEATURE_SCRIPTING conditions in
SfxObjectShell::GetBasicContainer (sfx2/source/doc/objxtor.cxx) and
SfxApplication::GetBasicContainer (sfx2/source/appl/appbas.cxx), so in such
builds loading e.g. xmloff/qa/unit/data/MCGR_threeStops.fodt containing
> <office:scripts>
> <office:script script:language="ooo:Basic">
> <ooo:libraries xmlns:ooo="http://openoffice.org/2004/office" xmlns:xlink="http://www.w3.org/1999/xlink">
> <ooo:library-embedded ooo:name="Standard"/>
> </ooo:libraries>
> </office:script>
> </office:scripts>
would fail with
> warn:sax:392777:392777:sax/source/fastparser/fastparser.cxx:645: Unexpected exception from XML parser com.sun.star.xml.sax.SAXException message: "nowhere to import to at xmloff/source/script/xmlbasicscript.cxx:96"
> wrapped:
and a
> General Error.
> General input/output error.
error box. But all the code paths using m_xLibContainer appear to first check
it to be non-null, so it seems rather harmless to make a null m_xLibContainer
non-fatal here for such builds at least.
Change-Id: I6f20b15cb4032fc6293aaae6551095125360171e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192076
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
this is an internal UNO API, and there is only one implementation,
so make that obvious in the code.
That required moving some classes from the svx library to the
svxcore library
Change-Id: Ic5c19327df271920dc1077185ff692abbf5fb091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191494
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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>
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
Use the returned object directly, instead of creating an O(U)String.
Concatenate with adjacent appends.
Change-Id: Id84563876bbb0df50d9e0bfc0b0c033630d4be81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190351
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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
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>
and
cid#1659754 Variable copied when it could be moved
cid#1659755 Variable copied when it could be moved
cid#1659756 Variable copied when it could be moved
cid#1659766 Variable copied when it could be moved
cid#1659767 Variable copied when it could be moved
cid#1659769 Variable copied when it could be moved
cid#1659770 Variable copied when it could be moved
cid#1659777 Variable copied when it could be moved
cid#1659787 Variable copied when it could be moved
cid#1659790 Variable copied when it could be moved
cid#1659793 Variable copied when it could be moved
cid#1659802 Variable copied when it could be moved
cid#1659818 Variable copied when it could be moved
cid#1659822 Variable copied when it could be moved
cid#1659824 Variable copied when it could be moved
cid#1659825 Variable copied when it could be moved
cid#1659826 Variable copied when it could be moved
cid#1659842 Variable copied when it could be moved
cid#1659849 Variable copied when it could be moved
cid#1659850 Variable copied when it could be moved
Change-Id: I70729aaf6e229518a9a50ac18311286ab5b05b53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189348
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
and
cid#1660117 Variable copied when it could be moved
cid#1659950 Variable copied when it could be moved
cid#1659946 Variable copied when it could be moved
cid#1659945 Variable copied when it could be moved
cid#1659936 Variable copied when it could be moved
cid#1659933 Variable copied when it could be moved
Change-Id: Ib6cbb6751a230e62b416b33ca082b279a2ecb878
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189318
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@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
Noel Grandin