Age | Commit message (Collapse) | Author |
|
For some reason, XML_TOKEN_INVALID was taking wrong value
in windows, causing to fail imports with unknown entries.
I've also added some of the tokens I found from several
test files to the list.
Change-Id: Idd2e7db165b9b4b5a2d8c7a837786fde252fe938
Reviewed-on: https://gerrit.libreoffice.org/43677
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
no need to explicitly specify it anymore
Change-Id: I6ad9259cce77201fdd75152533f5151aae83e9ec
Reviewed-on: https://gerrit.libreoffice.org/43567
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0b2012d2134a94603d95ce5a955f03944e344561
|
|
instead of mixing and matching rtl::Reference and tools::SvRef, lets
just use rtl::Reference
Change-Id: I5d77c8a662e1455f97935e5f4a99e484e8cad332
Reviewed-on: https://gerrit.libreoffice.org/43205
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
By substituting a (valid matching the type) format using these
special LCID modifier values with the current system locale's
format.
See ECMA-376-1:2016 18.8.31 numFmts (Number Formats) and
https://msdn.microsoft.com/en-us/library/documentformat.openxml.spreadsheet.numberingformats.aspx
which seems to be the only documentation available.
Change-Id: Ieca048a77d4ef473ae475e202557d1353ff5387d
Reviewed-on: https://gerrit.libreoffice.org/43148
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I10ffefd29b858548472a459314c7d5632324bca2
Reviewed-on: https://gerrit.libreoffice.org/43069
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic15590a13bd3770ee5dd7db76b21c830a4fe73e2
Reviewed-on: https://gerrit.libreoffice.org/42587
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
so if there are still ScXMLDatabaseRangesContext on the import stack,
i.e. exception thrown during ScXMLDatabaseRanges import, then
stuff crashes
=================================================================
==23249==ERROR: AddressSanitizer: heap-use-after-free
READ of size 8 at 0x6020001c3190 thread T0
SolarMutexGuard::~SolarMutexGuard() /src/libreoffice/include/vcl/svapp.hxx:1420:9
ScXMLImport::UnlockSolarMutex() /src/libreoffice/sc/source/filter/xml/xmlimprt.cxx:1916:13
ScXMLDatabaseRangesContext::~ScXMLDatabaseRangesContext() /src/libreoffice/sc/source/filter/xml/xmldrani.cxx:64:19
ScXMLDatabaseRangesContext::~ScXMLDatabaseRangesContext() /src/libreoffice/sc/source/filter/xml/xmldrani.cxx:63:1
destroy /usr/local/bin/../include/c++/v1/memory:1838:64
__destroy<rtl::Reference<SvXMLImportContext> > /usr/local/bin/../include/c++/v1/memory:1706
destroy<rtl::Reference<SvXMLImportContext> > /usr/local/bin/../include/c++/v1/memory:1574
std::__1::deque<rtl::Reference<SvXMLImportContext>, std::__1::allocator<rtl::Reference<SvXMLImportContext> > >::pop_back() /usr/local/bin/../include/c++/v1/deque:2604
pop /usr/local/bin/../include/c++/v1/stack:212:19
SvXMLImport::~SvXMLImport() /src/libreoffice/xmloff/source/core/xmlimp.cxx:418
ScXMLImport::~ScXMLImport() /src/libreoffice/sc/source/filter/xml/xmlimprt.cxx:769:1
freed by thread T0 here:
#0 0x6164a0 in operator delete(void*) /src/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:126
#1 0x6254e3 in ScXMLImport::~ScXMLImport() /src/libreoffice/sc/source/filter/xml/xmlimprt.cxx:787:5
#2 0x6259cc in ScXMLImport::~ScXMLImport() /src/libreoffice/sc/source/filter/xml/xmlimprt.cxx:769:1
Change-Id: Ia72284f99e2e2efe4f1f9e57b1483c0f1333274d
Reviewed-on: https://gerrit.libreoffice.org/42502
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Tunelling 1 piece of information through 20 layers of abstraction
Advanced tunelling all the way to sfx2
Exhausted beyond recognition arrived to [Flat]ODF filter
Change-Id: I0597c20c28f5cf8e2c60c4398622b36bda83abd0
Reviewed-on: https://gerrit.libreoffice.org/41777
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
and remove some dead ones
Change-Id: I6946d717d3c15dc5207489ed3d56d985dd953d59
Reviewed-on: https://gerrit.libreoffice.org/41746
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I899a8126c9d971601fea6c77eca165718aea0ac5
Reviewed-on: https://gerrit.libreoffice.org/41237
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib92aba17c46a4ada75c2a0630f281759d995f32e
Reviewed-on: https://gerrit.libreoffice.org/40843
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I51143ecfe4eb1584f13bd1590f927743de8fa91e
Reviewed-on: https://gerrit.libreoffice.org/40572
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I136ee42523a40c576d7cf0b66abbf50ad9be052f
Reviewed-on: https://gerrit.libreoffice.org/40517
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia874baf21257e5fe41e104211068a2bcc50446eb
Reviewed-on: https://gerrit.libreoffice.org/40391
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
|
|
Change-Id: Iec9535b106c85e47ddb14eec4ef3db5b1c8d8fd7
Reviewed-on: https://gerrit.libreoffice.org/40219
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6b4c431d66835b6affe834a23b900fa61830d87f
Reviewed-on: https://gerrit.libreoffice.org/40159
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Passing FastAttributeIter to the method makes the
code much cleaner and easy to read.
Change-Id: I227e9dc378dfba51168c29452667576a779dc215
Reviewed-on: https://gerrit.libreoffice.org/39730
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: Ica367371f1f7fb6e7858c8e35ec4c8de994e357d
|
|
Change-Id: Ic883a07b30069ca6342d7521c8ad890f4326f0ec
Reviewed-on: https://gerrit.libreoffice.org/39549
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9db514a20aad0e82a99a02334dfd5910b66e3a01
|
|
Change-Id: I4f9ffd686e8e5a10bdd3f5ad4282dc4776923b62
|
|
Change-Id: I4964ff97e0a1735dc08c6ad204cae0b08e9ffc2c
Reviewed-on: https://gerrit.libreoffice.org/39406
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Replacing integer-to-integer mapped tokens with
fast Tokens direcly for branching.
Adding a macro XML_ELEMENT that combines namespace
and element tokens.
Change-Id: I8701c8af9607392843460fe726bffb6556cf9b33
Reviewed-on: https://gerrit.libreoffice.org/39275
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
So we can finally grep these things.
Change-Id: I7ab4d0c82d8abf3fad4063321fc73772a7a6cb8d
|
|
Why do we need 2 identical constants?
Change-Id: Ib969f9b9583261f26fe65e04f183bdfabcb9eefe
|
|
Change-Id: I2ce725f87ee6f8ebcffbac268cc7e7f8850023e5
Reviewed-on: https://gerrit.libreoffice.org/39232
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
would have preferred to re-use o3tl::strong_int, of which this
is a modified copy, but there are lots of convenience accessors
which are nice to define on the class.
Change-Id: I301b807aaf02fbced3bf75de1e1692cde6c0340a
Reviewed-on: https://gerrit.libreoffice.org/38497
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Made those methods static, so that it is easy
to use them outside the module.
Also updated the Namespace-constants list.
Change-Id: Id0bf501457c53d1420a00ce58c9bcedfcba17908
Reviewed-on: https://gerrit.libreoffice.org/38708
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Change-Id: I173a29fd1ee889127369d2bc2fce8e010b89ca65
Reviewed-on: https://gerrit.libreoffice.org/38633
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib0304de5d873ac833dcc121235b8de494a1bb3bf
Reviewed-on: https://gerrit.libreoffice.org/37999
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Since it's not used outside xmloff.
Change-Id: Ibec67db2106300b6d4a91ce07d779e16e028eb2a
Reviewed-on: https://gerrit.libreoffice.org/38144
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
and avoid some reference-counting in a hot path
Change-Id: I7f5fd7f8f5f9076eb5f8d60118afa8e3ac8a5e6c
Reviewed-on: https://gerrit.libreoffice.org/38129
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
add the results files so I can just see the diff in future
Change-Id: Ia20a1aa6418be95ed620719cde340c00b7b053e1
Reviewed-on: https://gerrit.libreoffice.org/37988
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This avoids a lot of repeated allocation and freeing
of memory for AttributeList.
Change-Id: I97e44e633ed9880f37665f71e4dec3e74085cb09
Reviewed-on: https://gerrit.libreoffice.org/34134
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
|
|
Allow to have frames with the same name. For removing
real duplicated frames (generated by LO earlier)
check other things also next to the frame name:
position, size or whether the two frames are anchored
to the same position.
Change-Id: I191ae5128d0228eb85f78f065b44b1f0b3ba6dcf
Reviewed-on: https://gerrit.libreoffice.org/37702
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
New options are:
* insert columns.
* insert rows.
* delete columns.
* delete rows.
Change-Id: I076b0d01bee0fff0623e2f1137c09938a6110939
Reviewed-on: https://gerrit.libreoffice.org/37695
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
|
|
Change-Id: Id3df69b38fd35f46735246a6d307a89aa10d4294
Reviewed-on: https://gerrit.libreoffice.org/37426
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I59d2cb1f69882b62e6fe732e9d9214feec8a79a2
Reviewed-on: https://gerrit.libreoffice.org/37283
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia4e6f856dc37a2398c5bba58e77261e5e12d3c9c
Reviewed-on: https://gerrit.libreoffice.org/37317
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1c7a4e657601e28d9d50d86e24c4e0ba7579b9d4
Reviewed-on: https://gerrit.libreoffice.org/37289
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I751006fd054882a9ceab424675ac0505a9ddfd8b
|
|
The problem was that in case the document has shapes where the order
does not match the z-index order, so sorting is needed, then sorting
failed to take the multi-image feature into account. E.g. SVG images
have a PNG fallback, but at the end of the shape import the PNG
fallback is removed, which means the "actual" (not the "wished") z-index
of the shapes after the SVG image has to be adjusted.
Without this happening SvxDrawPage::getByIndex() (or in case of Writer,
SwTextBoxHelper::getByIndex()) will throw when the importer calls
getByIndex(3) but we only have 3 shapes. This results in not honoring
the z-index request of the remaining shapes.
Regression from commit 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 (re-base
on ALv2 code. Includes (at least) relevant parts of:, 2012-10-09), from
the
Svg: Reintegrated Svg replacement from /branches/alg/svgreplavement
http://svn.apache.org/viewvc?view=revision&revision=1220836
part.
Change-Id: Ibe880e5c6c74b728b4a760498720ee31f052b726
Reviewed-on: https://gerrit.libreoffice.org/36998
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: If99a944f7032180355da291ad283b4cfcea4f448
Reviewed-on: https://gerrit.libreoffice.org/36629
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia28e35ae5af4f601e9a586a3deffbcd61702b0ca
Reviewed-on: https://gerrit.libreoffice.org/36896
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
... and fix the wrong export for <text:meta-field>, which erroneously
did not use the same bIsPrevCharSpace flag as everything else (which was
obviously a bug, as there should be one flag per paragraph).
Interop testing demonstrates that at least Word and Calligra Words
differ in their interpretation of spaces following <draw:frame> and
other shape elements, and <text:note>: if there is a U+0020 space
before the element, LO will not collapse a U+0020 space behind the
element but Word and Calligra Words do collapse it.
The distinction between "mark elements" and "non-mark elements" in the
whitespace collapsing implementation in OOo since the beginning was
never explicitly spelled out in ODF, although listing the
<text:bookmark> etc. elements in ODF 1.1, 5.1.1 was a strong hint.
Fortunately all 3 applications agree that a <text:s> following a
<draw:frame> is consumed as a space, and it is valid to write a <text:s>
in this situation, so just do that to improve interoperability.
Change-Id: I42260c0528db9fe7e87e8dbae5105aeadb83780d
|
|
... to exportCharacterData. The others all export XTexts.
Change-Id: Ic4b1d6364c15d99d839e2736d4c2966d7aa302d4
|
|
Change-Id: If0e80fbe21b6d8bed55357d7fc09027fc4a37e06
Reviewed-on: https://gerrit.libreoffice.org/36373
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I9e9dddcbdd450f40b34318c90b8c2d8d3980dbd6
Reviewed-on: https://gerrit.libreoffice.org/36374
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|