| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Idf526aea21ccfeda9b03d1fb69588f120b6e161d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154571
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I52aad31f63858eba905481812cbf971493252642
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154570
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Enabling this feature on a list level makes all numbered sublevels, that
constitute the number of this level, to use Arabic numerals. This doesn't
change the labels of other levels: e.g., if level 1 uses A,B,C; level 2
uses i,ii,iii; level 3 uses a,b,c, and is "Legal"; and level 4 uses 1,2,3;
then a list may look like
A. Something
A.i. Some subitem
A.ii. Another subitem
1.2.1. This is a "Legal" sub-subitem
A.ii.a.1. And its child
This improves interoperability with Word.
This change introduces document model, ODF and OOXML import and export.
In ODF, a new boolean attribute of 'text:outline-level-style' element,
'loext:is-legal', is introduced; its default value is "false".
Change-Id: I5ae9f970864854c7e84c4b2f7ce46634b3ef104e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154288
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
these fields can be private
Change-Id: I74423a9ae2ef0263a28c8a716ab1c55861e453d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154092
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The attribute was moved to the style graphic-properties in commit
2721520ca37654056c3d509657c50ee42e3dcae4, which is in 7.5.2 so users
likely have upgraded from 7.5.0/7.5.1 and this can be removed now.
Change-Id: I69ef3e2e501af21f04df440bf176e46f651d671b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154074
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
* SdrObject new member m_IsDecorative
* new Undo SdrUndoObjDecorative
* surprising amount of changes in sw including additional SwUndoFlyDecorative
* svx API SvxShape property "Decorative"
* UI checkbox "Decorative"
* ODF import/export as loext:decorative on style:graphic-properties
* PDF/UA export: ViewObjectContcat tag shapes with this flag as Artifact
Change-Id: I37f7a0597eab92c6c6aff94fad6c16c59b231c80
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154063
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: Ia86c8bd0bdc85c375eb3837ba97f9e171d9dac6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153974
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
DocumentInfo currently assumes that a LO version encoded in "BuildId"
property has only 1 digit major version, which is now wrong and would
start to give incorrect results when major version "30" will be detected
as LO_3x.
Add the dots as separators into the BuildId because it's not going to
work without.
Change-Id: I8918afe3642cbefa8488c57658f1505c9a20eddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153649
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Embedded text was limited to number:number. But scientific notation may
require embedded text like
0.000" "000E+00
This change extend ODF format to support embedded text in
number:scientific-number also
Change-Id: I4e3220b06efbd9228d722bf518e137d7707ccf4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150804
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
that can be initialised at compile-time instead of runtime
Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
1. During import, XParagraphAppend::finishParagraph(Insert) are called,
which are implemented using SwXText::Impl::finishOrAppendParagraph,
and the latter calls
m_pDoc->getIDocumentContentOperations().AppendTextNode( *aPam.GetPoint() );
// remove attributes from the previous paragraph
m_pDoc->ResetAttrs(aPam);
so that there is always another (empty) paragraph after the finalized
one;
2. During import, lcl_AddRange is called to create anchored text content;
the start and end of it may reference the very end of the document
(using xTextAppend->getEnd()) - i.e., that last (maybe empty, maybe
extra) paragraph.
3. In many places, and in particular, in DomainMapper_Impl destructor,
DomainMapper_Impl::RemoveLastParagraph is called; and the latter uses
one of the two techniques to remove that last paragraph:
3.1. It either obtains the paragraph's lang::XComponent interface, and
calls its dispose (SwXParagraph::dispose), which eventually calls
DocumentContentOperationsManager::DelFullPara;
3.2. Or it uses cursor to select 1 ch back, and replace the resulting
selection with nothing.
3.1 has an advantage of keeping the formatting of the remaining (second-
to-last) paragraph, but DocumentContentOperationsManager::DelFullPara,
among other things, removes all anchored objects, thus this mode is not
used for the end-of-document case (e.g., see commit message of commit
e521930ea1c855c236efb67793e540d07c201d35 "fdo#58327: writerfilter:
RemoveLastParagraph is tricky:", 2013-01-10);
3.2 keeps the anchored objects, but needs workarounds to keep bookmarks,
and destroys the remaining paragraph character formatting.
Let me try to use #3.1 also in the end-of-document case, by introducing
code to move anchored objects to previous paragraph before calling
XComponent::dispose. Indeed, it may happen that more processing could be
needed, if more properties would happen to be bound to the very last
extra paragraph.
This change adds a call to DocumentRedlineManager::CompressRedlines in
DocumentContentOperationsManager::DelFullPara, because previously, this
was called during #3.2 inside setString. testTdf150086 failed without
this change.
testTdf131386 and testTdf152872 were changed to the now-correct import of
last paragraph properties (previously both of them relied on the hidden
property not present there, while it is there in Word).
In DomainMapper_Impl::RemoveLastParagraph, the check of the content of
selection made by moving backward one character was generalized to be run
before both cases, because RTF sometimes has only one paragraph after a
table (see e.g. testTdf148515), which now could be removed in the absence
of the check.
testTdf104390 was changed to not check the number of runs, because now
the paragraph keeps the trailing "paragraph mark formatting" empty run,
which previously was dropped using setString path.
Also, the fix for tdf#148273 is re-implemented here, by dropping
RES_PARATR_LIST_AUTOFMT in lcl_RstAttr. Likely keeping it was an
unintended side effect of placing RES_PARATR_LIST_AUTOFMT inside
RES_PARATR_LIST_BEGIN/END. After the change, explicit drop of it will be
not needed at arbitrary boundary, which is section break; this property
should only be applied where it's defined. This change can't be done
separately, because of interrelated unit test failures left and right.
In XMLParaContext::endFastElement, setting ListAutoFormat property must
be set only after setting style now, because otherwise it will be reset
in lcl_RstAttr when the style is set.
Some test documents were modified, to drop font from the last paragraph
properties, because their respective tests started to crash (see commit
172270a8f04388a8f8062f672f9c3f3144a01a1f "abort writer layout tests if a
font isn't found", 2022-05-01). Before this change, these paragraphs had
lost their formatting, so those fonts weren't used in layout.
Change-Id: I7e41c20e68e24c78fae1d2005c3fd75fb146ba2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153481
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...at least when building with --with-latest-c++ against recent LLVM 17 trunk
libc++,
> In file included from xmloff/source/text/txtparae.cxx:22:
> In file included from include/o3tl/any.hxx:21:
> In file included from include/com/sun/star/uno/Any.hxx:28:
> In file included from ~/llvm/inst/bin/../include/c++/v1/algorithm:1779:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__algorithm/inplace_merge.h:27:
> In file included from ~/llvm/inst/bin/../include/c++/v1/__memory/uninitialized_buffer.h:14:
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:63:19: error: invalid application of 'sizeof' to an incomplete type 'XMLTextParagraphExport::DocumentListNodes'
> 63 | static_assert(sizeof(_Tp) >= 0, "cannot delete an incomplete type");
> | ^~~~~~~~~~~
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:297:7: note: in instantiation of member function 'std::default_delete<XMLTextParagraphExport::DocumentListNodes>::operator()' requested here
> 297 | __ptr_.second()(__tmp);
> | ^
> ~/llvm/inst/bin/../include/c++/v1/__memory/unique_ptr.h:263:75: note: in instantiation of member function 'std::unique_ptr<XMLTextParagraphExport::DocumentListNodes>::reset' requested here
> 263 | _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR_SINCE_CXX23 ~unique_ptr() { reset(); }
> | ^
> xmloff/source/text/txtparae.cxx:1333:25: note: in instantiation of member function 'std::unique_ptr<XMLTextParagraphExport::DocumentListNodes>::~unique_ptr' requested here
> 1333 | XMLTextParagraphExport::XMLTextParagraphExport(
> | ^
> include/xmloff/txtparae.hxx:115:12: note: forward declaration of 'XMLTextParagraphExport::DocumentListNodes'
> 115 | struct DocumentListNodes;
> | ^
Change-Id: I319c1f682258950caf3571f51e5443d6753bcccd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153312
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7a6088c570ebd0680cc1b2603b946192a19bef26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153268
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@libreoffice.org>
|
|
Change-Id: I4a53fa57f52900104d249c84cde36c9d3b9e1300
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153175
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This is not an error - this method handles elements if it knows about
them, and otherwise leaves the elements for other code to handle
Change-Id: I531a2d9aff84ef4a2762923737a6b827e88cd920
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153191
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This continues to minimize cases where random ids are written, helping
to make the output more deterministic; it builds upon commits
8f48f91009caa86d896f247059874242ed18bf39 (ODT export: omit unreferenced
<text:list xml:id="...">, 2022-03-10), and
82bbf63582bdf28e7918e58ebf6657a9144bc9f3 (tdf#155823: Improve the check
if the list id is not required, 2023-06-14).
The previous code used to write 'text:continue-list' when the list is
restarted. It is unnecessary when there is no other condition requiring
such a reference (like style change, or interleaving lists); so relax
the conditions allowing to put simple 'text:continue-numbering="true"'.
This also allows to simplify a bit the code around 'ShouldSkipListId'.
Change-Id: Idf8be455953d08fd578266bda22f3a55d7b9ee23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153104
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The implementation introduced in commit 8f48f91009caa86d896f247059874242ed18bf39
(SwNumRule::HasContinueList) was a bit naive: it assumed that maTextNodeList is
sorted (it is not, and so, valid cases to avoid the id were missed); it assumed
that a given list can only consist of items of a single numbering style, and so
only tested the list of nodes referenced from maTextNodeList of given SwNumRule.
I.e., this implementation targeted a special case of a list style fully covering
a single continuous list.
This skipped ids for list items with list styles, in which maTextNodeList passed
the check in HasContinueList, but which were followed by items with a different
list style, continuing the same list. This constellation outputs continue-list
attribute in the following items (see XMLTextParagraphExport::exportListChange),
which references the skipped id. The resulting ODF is an invalid XML (an xml:id
is missing that is referenced), and also does not allow to continue such a list.
The change tries to fix this, using a list of nodes in XMLTextParagraphExport,
and analyzing if the list of the current paragraph has a continuation that needs
to reference this list id. Two new hidden properties introduced in SwXParagraph
and SwXTextDocument: "ODFExport_NodeIndex" and "ODFExport_ListNodes", resp. They
allow to pipe the data to the export. The previous special casing of property
state for "ListId", used in SwNumRule::HasContinueList, is removed together with
the mentioned function.
The intention is to have a logic allowing to detect 100% cases where the list id
is required, and where it's not required.
A related unit test for tdf#149668 was fixed to not rely on the mentioned ListId
property state workaround, and moved from sw/qa/core/unocore to xmloff/qa/unit.
Change-Id: If6a6ac7a3dfe0b2ea143229678a603875153eedb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153044
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... XMLTextImportPropertyMapper, XMLTextShapeImportHelper and
XMLTextShapeStyleContext.
See tdf#94879 for motivation.
Change-Id: I03e663811f3c7b0208c50a07806a4ba41e82ad29
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152892
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
When exporting a shape with an axial gradient fill to OOXML, it is
converted to a linear gradient with multiple color stops. Versions
before MCGR had recreated it as axial gradient on import from OOXML.
But now LO is able to handle multiple color stops and so the linear
gradient from OOXML is imported as linear gradient in LO.
When such file is then written as ODF, the multiple color stops are
in elements in extended namespace and versions before MCGR do not
understand them. They show only the first and last color (which are
equal) and the gradient is lost.
With this patch LO converts the linear gradient back to an axial gradient
on export to ODF. The exported axial gradient is rendered in a version
with MCGR same as the linear gradient when opening the OOXML file. The
difference is, that versions without MCGR now render an axial gradient
with two colors.
Change-Id: I2b416b4cdca75d8327107a4f259d63c2e6e97ac3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152574
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
... XMLConstantsPropertyHandler and XMLTextMasterPageContext
See tdf#94879 for motivation.
Change-Id: I739c9d4f7e551f84e7a55c6c5eb5109af596f055
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152598
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
A bunch of range based loop changes in various qa
sections that also take out about 1% of SAL_N_ELEMENTS
Change-Id: I8ef000e9aa400cd8363b48f6175f6ab258cefbd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152422
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This is similar to 'Use tryToRecreateBorder for better BW comp with LO'
(see commit 8259a99f41367a1d8326c9157fe1902915715879), but now for
transparency gradients.
Change-Id: I1c2e11562fa998c364896d517f4ed3bfe92f6c15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152508
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
This reverts commit 5e68d6cfade45f40b1ad46025a81afe4cb8dd337.
Reason for revert: Seems like outside users have been using this API
Change-Id: I8814cf1eb4f000eeb4cbbb5db9c282d001465993
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152441
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Unit test for commit 8259a99f41367a1d8326c9157fe1902915715879.
Change-Id: Iba3367fe42b5014b98cf575f53006fc09a79d6ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152428
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
There is no need for it to be an UNO interface anymore (ever since
we started supporting dynamic_cast on UNO objects).
Which means that XImportFilter2 also needs become a C++ interface.
Change-Id: Ice2db0f098271bba32b199bd083b08cb8410ce93
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152388
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9c58980de73dc2f00802f0d589d0c6fafe11d16a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152460
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
For better compatibility with LO versions before MCGR, try
to re-create a 'border' value based on the existing GradientSteps.
With MCGR we do not need 'border' anymore in quite some cases since
no Start/EndColor at 0.0 resp. 1.0 is explicitely needed. Since we
(unfortunately need to) internally continue to support border
anyways it does no harm to fallback to use the border value - if
there is an equivalent representation as this helper checks for.
For exports that do not support 'border' this will be adapted as
needed (see tryToApplyBorder())
Change-Id: If98c64039ff97143d4b5c92ac2a950e70f5bb70a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152395
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
It was introduced in commit 286ba5b6ca60c7f67106059ea56721b86c36925b
(#79947#: Improve performance, 2001-11-01), and there the size of
xPropStates did not change when incrementing nIgnoreProps. But later
commit 8195d7061ed52ebb98f46d35fe5929762c71e4b3 (INTEGRATION: CWS
swautomatic01 (1.126.4); FILE MERGED, 2006-12-01) started to remove
the ignored items from xPropStates.
Change-Id: Ida864a83c32dec2884beba9ad68943e936655fc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152326
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
... XMLMarkerStyleExport and XMLMarkerStyleImport
See tdf#94879 for motivation.
Change-Id: Ief48236f16c5525c6bd49d78e6ba4f9643ef1214
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152376
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
We need to identify what the color type of the complex color is.
For now we mostly use "theme", but in the future we can also have
other types like "rgb",... when the infrastructure for that is
built.
Change-Id: I38c91d294a191ca3124be4e99050977c9815d23e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152253
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Only decimal separator after S or SS was treated
This change adds [S] and [SS] to treat formats like
[SS].00
Update: correct export to XML
Add QA unit tests
Change-Id: I97ce4084d3caab2fcd18f1c70cd4221596290563
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151823
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
found with a lightly tweaked version of the loplugin:stringadd
and some hand-holding.
Change-Id: I146aadcaf665e98fea89a9cad2df4dc3935622f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152275
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For ODF it's not needed to abbreviate names and we prefer to use
full names. The theme color names in OOXML are abbreviated and the
same names were used also for ODF - this was changed now.
"color-table" used in "theme" element has reused the already
existing "color-table" element name in ODF, but they don't relate
to each other. The name was changed to "theme-colors", which makes
more sense anyway.
Change-Id: I61ec91895d301ad4343f2b977d5cbcf38e360b99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152252
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I63dd83522da7699162eb06a019a679d4b8750d10
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152053
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
RTF doesn't break floating table across pages, and there is a matching
DOCX compat flag to handle such documents.
We can ignore floating table info on the model as a workaround, but that
would mean the info is lost on save, so that's not ideal.
Instead add a new compat flag that disables fly split at a layout level,
which allows both not splitting tables & retaining the model-level info.
This commit does the doc model, UNO API, layout & ODT filter, the Word
filters are not yet updated.
This compat flag is probably quite rare, so introduce a mechanism to
only write the compat flag when it's true: this way the majority of the
documents don't need to say anything about it and we can assume "false"
for them. Also fix two missing xmlTextWriterEndElement() calls in the
xml dumper.
Change-Id: I32321ec204d7bfe011fcf024b97c906da0db8aae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152190
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
... XMLHatchStyleExport and XMLHatchStyleImport
See tdf#94879 for motivation.
Change-Id: I2dd4c97c6e234447190e46bd6f6a6354e16911bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152077
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ib24c4b819c31cdc6a9626b09a5b2acd10389ad7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152051
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I3d943f20e76b8f3e0409d307d11e3bf16489bf02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152050
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I039aea6656cc8dedd74782f4fda8b0e1c25d3910
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152029
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Reset the MajorOrigin property after import to avoid
of the bad export of the modified document, which reset
the original On tick marks/Between tick marks value.
Follow-up to commit 40d83914d43f60a196dfabddea0b52e2046b333a
"tdf#127792 implement UNO chart attribute MajorOrigin".
Change-Id: I0e3915b7d1b601abd40fbd1ba9d01fc05a8fb7c1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151885
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
since we know that this is a matrix only used for 2D transforms,
we know that the last row of the matrix is always { 0, 0, 1 }.
Therefore, we don't need to store that information, and
we can simplify some of the computations.
Also remove operations like operator+ which are not legal for
such a matrix.
Change-Id: I482de9a45ebbedf79e3b6033575aab590e61c2d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151909
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
For PropertyMaps.cxx used:
(MAP_FULL\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_ENTRY\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_ENTRY_ODF12\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_ENTRY_ODF_EXT\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_ENTRY_ODF_EXT_IMPORT\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_CONTEXT\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_SPECIAL\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_SPECIAL_ODF12\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
(MAP_SPECIAL_ODF13\( *[A-Za-z0-9_]+ *, *) => \1XML_NAMESPACE_
For xmlexppr.cxx used:
ENTRY\( *([A-Za-z0-9_]+) *\) => { GET_PROP_TYPE(XML_TYPE_PROP_\1), XML_\1_PROPERTIES }
For OOo2Oasis.cxx used:
(OOO_IMPORTER\( *)([A-Za-z]+) => \1xmloff_\2_get_implementation
For xformsapi.cxx used:
TOKEN_MAP_ENTRY\( *([A-Za-z0-9"]+) *, *([A-Za-z0-9_]+) *\) => { XML_NAMESPACE_\1, xmloff::token::XML_\2, xmloff::token::XML_\2 }
For xformsexport.cxx used:
TABLE_ENTRY\( *([A-Za-z0-9"_]+) *, *([A-Za-z0-9"_]+) *, *([A-Za-z0-9"_]+) *, *([A-Za-z0-9"_]+) *\) => { \1, XML_NAMESPACE_\2, xmloff::token::XML_\3, \4 }
elementexport.cxx and property_meta_data.cxx done by hand.
Change-Id: Ifb0c76a60f95e74ff1f9d596afdaff138c2228c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151867
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I4fce6eeb6652914e1883037b41a2dc3c09a88ada
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151826
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Removed concatenation from the macros, because due to them I wasn't able to find anything relevant with grep when searching for them.
Change-Id: Ic22d711d9e93bb89b402d141aa1ca3293bba866e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151819
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
... XMLDashStyleImport and XMLEventExport
See tdf#94879 for motivation.
Change-Id: I203cc1c789a1a33721b27754412da35c3ca8a56a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151755
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
In OOXML a color definition includes more represenations, one of
which is scheme color (which is what is implemented in ThemeColor
currently), but it supports other representations too (RGB, HSL,
System,..). ComplexColor includes all the representations, so to
have a better compatibility with OOXML, this changes all uses of
ThemeColor to ComplexColor.
In many cases the usage of ComplexColor isn't the same as the
usage of ThemeColors, but this cases will need to be changed in a
later commit.
Change-Id: I9cc8acee2ac0a1998fe9b98247bcf4a96273149a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151492
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
This reimplements commits 6249858a8972aef077e0249bd93cfe8f01bce4d6
(sw: ODT import/export of DOCX's paragraph marker formatting,
2022-12-19) and 209dce614c43f63f63f5b42a746665c0ec1cbfe3 (sw: fix
ODT import of paragraph marker formatting, 2022-12-20).
Instead of using an empty trailing span for the ListAutoFormat data,
introduce a new loext:marker-style-name attribute for text:p element,
referencing a text autostyle.
The problems with the previous implementation were that (1) it was
impossible (or very difficult) to disambiguate several empty trailing
spans, in case it was needed; and (2) this was incompatible change,
with other ODF implementations treating the trailing span normally.
I couldn't manage to incorporate the attribute to paragraph autostyle,
because of problems referencing different autostyles one from another,
so put it directly to the paragraph attributes.
Change-Id: I33473147f1f774c24cbbc57bf0c4f3a1d83ce5bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151645
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ibeeba1862d84e43fa659cb2a97ef3498674f0d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151590
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic3067f1681c047cd944e64179c568f4e972e0c95
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151447
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
