Refactor the existing places and tests in Impress code (sd) to
use it instead.
Also keep the old property of construction and view of the theme
with a sequence of property values, but under the new property
named "ThemeUnoRepresentation". This is needed by the UI tests
currently.
Change-Id: I484567f4a603f1a5e2e03955fdd2b63132dcc66e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146225
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Restore and update change 56352
Test of https://cgit.freedesktop.org/libreoffice/core/commit/?id=8ca6468f0f4900d4d3bb45e0e938fe35c308512c is now ok
Add disambiguation between '0' and '?' in integer part
XML_MAX_BLANK_INTEGER_DIGITS is added for the number of '?'
XML_MIN_INTEGER_DIGITS is the number of '?' and '0'
This preserve compatibility with previous versions:
in previous versions '?' will be transformed in '0'
It also applies to scientific and fraction numbers.
Integer part for number, scientific and fraction are
treated the same way
Include QA unit test
Change-Id: Iab3127bf07223caac60e409306a1bee2edc37428
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145932
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
Also move Theme from svx to model namespace so it is consistent
with other classes in docmodel.
Theme header also includes ThemeSupplementalFont, ThemeFont,
FontScheme classes that are used by the Theme and were also moved
to docmodel. These may be moved to its own file in the future when
they are used in more places.
Change-Id: Ic409bea8e5298adc2b039b529c4f7b01cf64f03e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146221
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Restore the call (without checking its returned value), removed in commit
d194474aabd699806cb3631bc8641dd0548b8026 ("tdf#151100: xText->getString()
may be empty for content needing export", 2022-09-22), side effects of
which obviously allow some object's changes to get flushed and saved.
Change-Id: I62f27cd056c32ad76f79a4862e2f4a0964eaadef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146106
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
For Table of Figures/Objects/Tables.
Make this similar to DOCX: only one source style is possible, so omit
the intermediate text:index-source-styles element.
Also a boolean attribute like text:use-index-source-styles appears as
unnecessary complexity, so try to do without.
Change-Id: I7cb599c7ec1261ddedc196a25c3eafe35f35fbe9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146013
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The reported problem was that once tracked changes is enabled and an
image is deleted, its aspect ratio changes on save.
What happens here is that the image's frame is marked as a redline
deletion, so when the ODT export writes the file, it'll have a zero
size. But this zero size is nothing we should take into account on save,
XMLTextParagraphExport::addTextFrameAttributes() expected to always have
a valid layout size if the LayoutSize property is available.
Fix the problem by adding one more condition where we ignore the layout
size, which was already there since commit
80550ade30 (tdf#150990 ODT export: fix
zero layout size of scale/scale images, 2022-09-20).
Note that this way the written side will be the original one, so only
the aspect ratio will be correct, but that was accepted as a compromise
earlier.
Change-Id: I108dc2428ce0cb07a044bfef216575fdba19267b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146043
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
And simplify the latter, to always use "CDATA" type (as the former did).
"CDATA" was used in all cases but one, where an empty string was used.
Change-Id: I1b3bfae40e29628e4094d9a6e58a69a66865874c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145526
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Change the xmloff filter to use XThemeColor and the associated
proprties (CharColorThemeReference and FillColorThemeReference).
Change the ODF format for referencing a theme color - make it an
element instead a series of attributes on the *-properties style
element.
Change-Id: I0fa7d8ebffecc02897b7fe9824d6f1776ef36380
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144923
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
The xOldCursor must be restored in all cases.
Also XMLParaContext triggers an exception which ends up aborting the
import.
Change-Id: I8f4785e0e9bde4c8c484954a4d66f3b82d6ca28c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145094
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
warning seen on saving very simple writer document.
maybe since:
commit 91f649a119
Date: Thu Dec 9 08:43:27 2021 +0100
ODP import/export: refer to theme from shape text color
Refer to the 12 pre-defined colors by name + don't write the attribute
for the case when there is no theme.
Change-Id: I4a7d21a7bab1ee77336ed6a5de8862fbab9be177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144870
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
OOXML supports theme colors and tint/shade value that additionally
changed the theme color. Read back which theme color + tint/shade
value was applied in the resulting color and add this attributes
as properties to be used by writer.
In sidebar theme panel the changing the theme colors now doesn't
takes this into account and changes the colors correctly.
Change-Id: I3a2d49d485fd37a1611483ee0bb5e6034ac5f88e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143697
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(See the upcoming commit introducing that loplugin:unocast on why such
dynamic_casts from UNO types are dangerous.)
Change-Id: I803f62085264511976ed9bb0744ee301de2a7dab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144754
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The DOCX bugdoc had a numbering portion which was not bold, even if all
characters in the paragrpah was bold. This was rendered fine, but once
it was saved to ODT + reloaded, the numbering portion became bold as
well, which is buggy.
What happens here is that there is one span that covers the entire
paragraph (and is bold) and there is an empty span at paragraph end
(which is not bold), so the ODT export is fine. But once we import it
back, the first span gets "upgraded" to paragraph-level formatting
(because SetAttrMode::NOFORMATATTR is not used when inserting the hints)
and the second span is not mapped back to the original
RES_PARATR_LIST_AUTOFMT in the text node.
Fix the problem by 1) improving SwXTextCursor::setPropertyValue() to
work with SetAttrMode::NOFORMATATTR when multiple spans are inserted and
by 2) extending SwUnoCursorHelper::SetCursorPropertyValue() to create
RES_PARATR_LIST_AUTOFMT for empty spans at paragraph end. This way the
original doc model and the one created after ODT export + import is much
closer to each other.
This builds on top of 6249858a89 (sw: ODT
import/export of DOCX's paragraph marker formatting, 2022-12-19),
previously the ODT export and import of paragraph marker formatting was
completely missing.
Change-Id: I139e11217dcbc18744aeeb80638090781aa74933
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144587
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Follow-up to 100c914d44
which added the initial id preservation for DOCX.
adding DOCX block SDT grabbaging, ODF import/export
[content controls can't exist in DOC format]
The ID field is CRITICAL to preserve for VBA purposes.
This patch adjusts BlockSDT to also round-trip the id
instead of just creating a random one.
m_nRunSdtPrToken <never equals> FSNS(XML_w, XML_id) since 2021
with 5f3af56b2c,
so I removed that part of the clause.
I had thought about changing the ID to use a string instead of an int,
but then the integer version was adopted to fix a regression
in the commit mentioned earlier.
I think it is AWFUL to have a number as the identifier
when it will be used in StarBASIC. The VBA guys have to deal
with it, but it would be nice to do something reasonable
for LO native access to content controls.
However, the concern would be if we allow VBA macro content created in LO
to be exported to DOCX format - that would cause problems converting
from a string ID to a number ID. VBA editing already is happening to
some extent, and mmeeks seems interested in enabling it.
So over-all it seems best to just stick with an integer ID.
I used the commits for <w:alias> and <w:tag> to compose this patch.
XML_ID already existed in include/xmloff/xmltoken.hxx
and "id" already exists in xmloff/source/token/tokens.txt
The ID can be used in VBA to select a specific control.
The id (which is a positive or negative integer in DOCX)
specifies a unique control - either by passing the number as a string
(of the UNSIGNED value) or by passing as a float (specified with #).
For example:
msgbox ActiveDocument.ContentControls(2587720202#).ID
msgbox ActiveDocument.ContentControls("2587720202").ID
but not as an integer since that is used for index access.
dim index as integer
index = 1
msgbox ActiveDocument.ContentControls(index).ID
make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText
make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport
make CppunitTest_sw_ooxmlexport18 CPPUNIT_TEST_NAME=testTdf151912
make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport
Change-Id: I5c4022dc932d941fad9da6d75ce899ee1ff66ff5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142818
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This has to be vital to keyboard navigation.
Certainly it is good to have it imported
before we start to consider tab-movements
for form controls.
All tabIndex 1's are processed (in placement order)
and then the 2's etc. 0's are to be done last.
XML_TAB_INDEX already existed in include/xmloff/xmltoken.hxx
and "tab-index" already exists in xmloff/source/token/tokens.txt
make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText
make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport
make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport
No existing unit test found containing blockSDT with tabIndex.
Change-Id: I8a958844e6192b079a2b22a62dedfd8739021f4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143603
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
DOCX SdtControls can be locked in two ways:
-Content Control cannot be deleted (sdtLocked)
-Contents cannot be edited (contentLocked)
or both (sdtContentLocked)
make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText
make CppunitTest_sw_ooxmlexport4 CPPUNIT_TEST_NAME=testSimpleSdts
make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport
make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate
make CppunitTest_sw_macros_test CPPUNIT_TEST_NAME=testVba
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport
make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport
Change-Id: I5a82d9f6b5103a4902f59af66cd8a99addd4e690
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143542
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
* sw core RES_DECORATIVE as a FRMATR
* sw API SwXFrame property "Decorative"
* UI checkbox "Decorative"
* ODF import/export as loext:decorative on draw:frame
* DOCX export
* DOCX import - very non-obvious how to get it from model.xml to dmapper
* PDF/UA export: tag flys with this flag as Artifact
* test for DOCX filters, ODF filters, PDF export
Change-Id: I1ceb67fdd4e1cfa212aafdeb1c5f4ccd873d433e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143815
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
(Not adding a test here, as this should already be covered
by several tests in sw/qa/extras/odfexport/odfexport.cxx.)
Change-Id: Ic3cae9f38efc55d3d9055a45bc642d7b15fa382a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143840
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Found this while looking into improving insertion of pages
with tables, as SdDrawDocument::InsertBookmarkAsPage uses "_"
as the rename suffix for styles with identical names but a
different content.
This commit fixes two issues:
- For import, cell styles with encoded names couldn't be found
by table styles. The reason is that styles are referenced in
ODF by encoded names, but at runtime by display names. Yet we
were searching the cell style family by encoded names. This was
already handled for sw in insertTabletemplate(), and now do the
same for sd.
- For export, table template names were encoded, but then
referenced by tables using their non-encoded names. This is
unlike the sw code that doesn't encode them, and therefore
doesn't have this problem. Looking at the schema, both
table:name attribute of a table template, and table:template-name
attribute of a table are of type "string", which suggests that
there is indeed no need to encode those names. This aligns with
the fact that table templates don't have a display-name attribute.
Change-Id: Ie61b6a1c95b033404ee98f3fc40d8e82434a6a6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143839
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
prevent the OOM by detecting cycles in SwList::SwList and throwing an
exception.
(1) However, that means we need to catch the exception in
XMLTextListBlockContext::XMLTextListBlockContext
and undo some registration, otherwise we will get a use-after-free.
The need to catch it is why I'm using an UNO exception here,
it seemed like a bad idea to throw and then catch and std::foo
exception.
(2) this is still not the end of the story, a further exception
is thrown during SwDoc destruction, for which I don't have a
solution.
Change-Id: I48be3d8acbdc0f9ca948a958f1124b158ba77ac0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143820
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
before scanning for autostyles. That way we can collect only the
property state we are interested in, instead of all properties.
Change-Id: I8da4d61401d904631cbf9dc1828266950fe98421
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143466
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Including a new set of default styles, provided by Rafael Lima.
Some ui tests had to be modified, because the new borders are
thicker.
If you intend to edit the xml file, please keep in mind the
following requirements:
1) There should be a table template called "default". It's
applied to newly inserted tables.
2) There should be a cell style called "default". It's used for
new table styles.
3) Please make all cell styles inherit from "default" (directly
or indirectly), unless you intend to specify font names in them.
"default" has its font names filled programmatically based on
officecfg/registry/data/org/openoffice/VCL.xcu.
4) Whenever possible please use <style:table-cell-properties>
for cell properties, instead of the incorrect
<style:paragraph-properties> and <loext:graphic-properties>
we currently use for export. See tdf#72238 and tdf#72239.
Change-Id: I73dd4492fefb65b1870238aec7dc64f8076f6e95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141825
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
In addition to actually used styles, we want to
export user defined styles, as well as built in
styles that were modified.
Detecting the real modification state might be
challenging in some cases, e.g. when importing
the style from an existing document. So for
simplicity, we consider a style as "modified"
if at least one of its child cell styles is user
defined. The UI for modifying cell styles will be
implemented in such a way that built in styles
will never be modified themselves. Instead, a
user defined style will be created on the fly,
with the corresponding built in style set as its
parent, and only that new style will be modified.
It is still possible to modify built in cell
styles via the UNO API, but such styles won't be
exported unless actually used in the document.
Change-Id: Ic73eb460fd024f23016553e134397e07259f5c90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143011
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
- Replace SwContentControl::HasListItems(), which assumed that the type
is dropdown if we have list items. This is not valid, it's OK to have
a dropdown with no list items. Add a GetDropDown() instead to check
for the type, explicitly.
- UNO API sets the dropdown bit when list items are set and the type is
not expilcitly combo box or drop down, to keep backwards
compatibility with existing documents.
- No change to the edit shell, SwDropDownContentControlButton already
checked if items are empty and used STR_DROP_DOWN_EMPTY_LIST in that
case, but that was dead code previously.
- ODT & DOCX filters are now updated, ODF has a new
<loext:content-control loext:dropdown="..."> attribute to specify that
the type is a dropdown, explicitly.
Change-Id: Id577ba9639151549a8f953aab31685a73a898504
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142491
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Follow-up to commit 7c20c3c2a9
"xmloff: ODF export: adapt all checks of ODFSVER_012 etc.".
Reported by Eike Rathke.
See also b7d53247eb
"tdf#115007 i18npool: add NatNum12 formats to locales" and
2a1d2d42af
"tdf#115007 add NatNum12 number format list items, fix title case".
Change-Id: Idb25a37ffcad0a0fb05276b972561abf929cd81b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142373
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Handles fo:border*, fo:padding*, fo:background-color and
style:vertical-align attributes.
Export is unchanged for now, as older versions still
can't read this, and on the other hand we probably want
to keep the import of the wrong attributes for the long
term, to not break existing documents. Also, we can't
fully export fill properties anyway because of tdf#103602.
Change-Id: I8687507b98602ffcd05adb2087c894bb45aa3c6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142058
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Make XMLShapeExport aware and use that PolyPolygons can be not
only in Bezier format, but also a sequence of Points
Change-Id: Ie00e87d35d4f8aa9d481b2800585c5a770bbbc0a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141935
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Map the Alias/Tag UNO properties to:
<loext:content-control loext:alias="..." loext:tag="...">
on export, and do the opposite on import.
Change-Id: Icecbe9037ede0bf8d72d52f2db44328a8db1d83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141492
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Map the ComboBox UNO property to:
<loext:content-control loext:combbobox="...">
on export, and do the opposite on import.
Change-Id: I33c162ace15025c8031eb678ba5a43ac085c4b6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140364
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The check that is removed prevents collecting the table data.
Assume that it's the performance optimization, and that processing
empty text objects would be fast anyway.
This basically reverts commit 73fcb052ed
Author Christian Lippka <cl@openoffice.org>
Date Thu Nov 22 12:26:35 2001 +0000
#90330# only export text autostyles for shapes with text
and commit 7661bbbaef
Author Michael Stahl <mstahl@redhat.com>
Date Fri Nov 25 22:46:34 2016 +0100
tdf#102479 ODF export: ignore exceptions when checking shape text
that becomes unnecessary after the former change is reverted.
Change-Id: I709a7b4c5ac1cc0621d3a1b18f2eb74feb987efb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140313
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tomaž Vajngerl