summaryrefslogtreecommitdiff
path: root/include/xmloff
AgeCommit message (Collapse)Author
2016-10-07loplugin:staticmethods: xmloffStephan Bergmann
Change-Id: Iad001ce011cd6aff4af9bb2e9129abee7fb935dc
2016-10-07might as well go back to a std::stack nowCaolán McNamara
after... commit 8daf6707ef203b26a744140f74d7cd231a25f0dd Author: Michael Stahl <mstahl@redhat.com> Date: Thu Oct 6 23:37:51 2016 +0200 xmloff: fix crash in ~XMLParaContext on fdo72541-1.fodt Change-Id: I57f10e60a2f76dde048a594d8391bb5b246dfc63
2016-10-04crashtesting: use a stack with the expected dtor order for its elementsCaolán McNamara
contains test document which crashes if it doesn't Change-Id: Ieeee6cc7007a90d37225fffd636c9648289f04d7
2016-10-04this is used as a stack, so convert to std::stackCaolán McNamara
Change-Id: I248617ccbb985615f936ecd607ab7c8246ff8e71
2016-09-26implement prototype for more stable calc cell style namesMarkus Mohrhard
This should ensure that as long as the style does not change the cell style name is the same after an import export cycle. Each ScPatternAttr stores a unique ID and we store the ID to name mapping during import. During export if we find a ScPatternAttr that has a key that is also stored in the map we write back the style name from the map. To avoid name collisions we block the style names from the import for the export. The missing piece to make this completely awesome is now to make sure that styles are sorted by name during export. That way we can reduce the diff between import and export even more. Change-Id: Ie4fe2aa00f07efec27ea129e314ac0b6b7e0d8c0 Reviewed-on: https://gerrit.libreoffice.org/29255 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-09-26soon is nowMarkus Mohrhard
Change-Id: Ib4b8b949f00609149f9134fb2f286cd7e0dc0255 Reviewed-on: https://gerrit.libreoffice.org/29254 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2016-09-25tdf#101935 and tdf#102201:Mohammed Abdul Azeem
This fixes both the bugs. Change-Id: I7a64abc0cb12b5195a3b955549ce4f72f3530d57 Reviewed-on: https://gerrit.libreoffice.org/29263 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-09-16coverity#1372990 xmloff: use unique_ptr for RewindMapsMichael Stahl
Change-Id: I51e67607d94a465ce39e822f01a0c60efbf1a0f0
2016-09-14loplugin:countusersofdefaultparams in xmloffNoel Grandin
Change-Id: Ia92a878ac97b3cc668594946e77a718f27a3e3ed Reviewed-on: https://gerrit.libreoffice.org/28890 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2016-09-13loplugin:dllprivateStephan Bergmann
Change-Id: I1fe70a39c50aba8b84c117653185fc37dbbfeab0
2016-09-13do not add calendar modifier to format code when importing as E or EE keywordEike Rathke
... with implicit calendar switch. Change-Id: Ie4d848e261fe86bbe504954b2e0c7cf24bc181bc
2016-09-13loplugin:override: No more need for the "MSVC dtor override" workaroundStephan Bergmann
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark overriding destructors as 'virtual'" appears to no longer be a problem with MSVC 2013. (The little change in the rewriting code of compilerplugins/clang/override.cxx was necessary to prevent an endless loop when adding "override" to OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager(); in chart2/source/inc/LifeTime.hxx, getting stuck in the leading OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.) Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
2016-09-13coverity#1372877 I'm guessing this is what might have been the intentCaolán McNamara
warning is 'Constant' variable guards dead code Change-Id: I06e65f576180d7ff62417828c26f969982788b55
2016-09-10Blind fix for MSVCStephan Bergmann
Change-Id: I53e01f3c76cf1e52fbf5f95f525cfc3b643b9e77
2016-09-10fix the buildMarkus Mohrhard
Change-Id: I600d1820d95ecbd428bbda18b3a07ec225bd2db0
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: I8ba37267e8a7058ade54783ea0e117a8f8816c45
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: I39475538ed838e4210e256d85c6dd46232f8dc50
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: I507b19dfd7445144258554b08bbf2fea0ed1698f
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: Ic0cb9399e5cfc7237a3cda666b1d4f926761a9ca
2016-09-09Blind fix for MSVCStephan Bergmann
Change-Id: I1b3e21e9fdf1ac14e095df203cb48fdd1b4fd028
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: I33d75ede0031da63c00c35af7b42867fea0b8d80
2016-09-09use std::shared_ptrDavid Tardon
Change-Id: Ie3f89c611f06be3c2fd5f43a4fa691f719078307
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: I94aafd665116d01d2f6134c4b41ab70c34e23ab6
2016-09-09loplugin:refcountingNoel Grandin
Change-Id: I3ab5f1df08670fdad3e31aadafd3a02f1925dd88
2016-09-09remove manual memory managementDavid Tardon
Change-Id: Ic715adae42ff34be892d19802629aa50077dc120
2016-09-09remove direct memory managementDavid Tardon
Change-Id: I9c7d53a9cfd5c03e1551626a96cdaa30fc4e546b
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: I5128b3e950657f3fe6fc71a8de56c9dd87ac2324
2016-09-09remove direct memory managementDavid Tardon
Change-Id: Id0278f15e0c46a32cf07900dffdf27b3acb2649c
2016-09-09use std::unique_ptrDavid Tardon
Change-Id: Ic6ebe839fa22e6a7b9904ad00877eddd78331ba4
2016-09-09remove direct memory managementDavid Tardon
Change-Id: I5dd5d9130f11f47c4b48c1aae9748434ac751d95
2016-09-09remove direct memory managementDavid Tardon
Change-Id: Ie5103347fc30095778d96d46ce702bf4f0da00a6
2016-09-09resolve the snafu with 2 separate refcounted basesDavid Tardon
Change-Id: Ia275596d54ea27436f03d01297fb78b6ca09e8a6
2016-09-07loplugin:constantparam in vcl..xmlscriptNoel Grandin
Change-Id: Icf66c08071b154259c9e551342d30331caf2b15a Reviewed-on: https://gerrit.libreoffice.org/28685 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2016-09-06Again avoid UBSan "left shift of 65536 by 16 places cannot be represented...Stephan Bergmann
...in type 'int'"; i.e., re-apply 11cc9bdc21be241f2feb3ab4822d9d365dba4f96 "Avoid UBSan 'left shift of 65536 by 16 places cannot be represented..." after 67ef208b2b586603e205105a384231645d7f6712 "Fixes for migrating SvXMLImport to use FastParser" removed that fix, for no apparent reason. Change-Id: I8379d2ae8a39ce8a655688d1168d8de67186472a
2016-09-06use std::unique_ptrDavid Tardon
Change-Id: I0cc84cc6b18849118a2b7824a8e4b37ca063cd50
2016-09-06drop unneeded dynamic allocationDavid Tardon
Change-Id: I9e19c33998137ee0065f92ccb980d1ff5a82115b
2016-09-05Fixes for migrating SvXMLImport to use FastParser:Mohammed Abdul Azeem
These are necessary for implementing fast interfaces for the contexts. Change-Id: I37655c85c76b42782a49eeea3140490213047341 Reviewed-on: https://gerrit.libreoffice.org/28641 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2016-08-30loplugin:countusersofdefaultparamsNoel Grandin
Change-Id: I69f55593e6101906e0e97565f2cfc818852258dd Reviewed-on: https://gerrit.libreoffice.org/28486 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2016-08-30Avoid UBSan "left shift of 65536 by 16 places cannot be represented...Stephan Bergmann
...in type 'int'" warning when constructing an XML_TOKEN_MAP_END instance, whose nPrefixKey is 0xffffU. Problem got introduced with 41b3fd8ca54eff7e71c69bb0b60e63016f1ac8c2 "Make SvXMLTokenMap compatible with FastTokens", the intent was presumably to make the shifted value of ( nPrefixKey + 1 ) << 16 be zero in that case. Change-Id: I0b83a03198a44e54077899e4484634286d06cdcc
2016-08-29Make SvXMLTokenMap compatible with FastTokens:Mohammed Abdul Azeem
Added seperate map for fastToken and Token, to get token using only fastToken. Default values are derived for fastTokens from prefixKey and localName. Duplicate/ dummy tokens need to be overidden with different values. Change-Id: I17268754d8fd1bac29dd7bae05706ff20b8314ae Reviewed-on: https://gerrit.libreoffice.org/28415 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
2016-08-26Make SvXMLTokenMap compatible with FastTokens:Daniel Sikeler
Added new methods for the fasttokens and a lot of entries must be updated in later commits. Change-Id: I37de9c8d4bdeb75f678902a422a5961670480562 Reviewed-on: https://gerrit.libreoffice.org/28355 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2016-08-25cid#1371771 Uncaught exceptionStephan Bergmann
Change-Id: I47105f30e702f9bc40cb711f862fb25796202d09
2016-08-23GSoC - First cut at migrating xmloff/ to use FastParser:Mohammed Abdul Azeem
This lays the foundation for using fast parser and contexts. Tokens are detokenized and made to emit events just like legacy parser interfaces. Change-Id: I11659be68026e112fdd06f8a847f3f2c876dae35 Reviewed-on: https://gerrit.libreoffice.org/28175 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2016-08-23use rtl::Static for static std::ordered_set in XMLPropStyleContextNoel Grandin
we suspect the current situation of causing a crash on shutdown after the tokenmap unit test: (gdb) bt 20 __gnu_cxx::new_allocator<std::__detail::_Hash_node_base*>::deallocate (this=0x7fffffff52c7, __p=0x78a700) at /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/ext/new_allocator.h:110 std::allocator<rtl::OUString>, std::__detail::_Identity, std::equal_to<rtl::OUString>, rtl::OUStringHash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, true, true> >::_M_deallocate_buckets ( this=0x2aaab3166640 <XMLPropStyleContext::maParaSet>, __p=0x78a700, __n=11) at /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/bits/hashtable.h:794 std::allocator<rtl::OUString>, std::__detail::_Identity, std::equal_to<rtl::OUString>, rtl::OUStringHash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, true, true> >::~_Hashtable ( this=0x2aaab3166640 <XMLPropStyleContext::maParaSet>, __in_chrg=<optimized out>) at /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/bits/hashtable.h:959 rtl::OUStringHash, std::equal_to<rtl::OUString>, std::allocator<rtl::OUString> >::~unordered_set ( this=0x2aaab3166640 <XMLPropStyleContext::maParaSet>, __in_chrg=<optimized out>) at /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/bits/unordered_set.h:93 rtl::OUStringHash, std::equal_to<rtl::OUString>, std::allocator<rtl::OUString> >::~unordered_set ( this=0x2aaab3166640 <XMLPropStyleContext::maParaSet>, __in_chrg=<optimized out>) at /opt/rh/devtoolset-2/root/usr/include/c++/4.8.2/debug/unordered_set:113 Change-Id: Iff36d4f217b8bb07083d2e599afade1f86206165
2016-08-17UTF-8 is Unicode, tooTor Lillqvist
There is no dichotomy of "Unicode" vs. "UTF-8". What is meant is UTF-16 (OUString) vs. UTF-8. So say so in the comments. Change-Id: I14fa7f543e87ed9e54fb37374a0b17d7e09a0879
2016-08-17loplugin:staticmethodsTor Lillqvist
Change-Id: I84fe6603010defcfae32250c86e75cf2237f64a1
2016-08-16tdf#100547 Save to ODF XY customized namesLaurent Balland-Poirier
Trendline equation: Following change 27069 https://gerrit.libreoffice.org/27069 Save customized names of X and Y variables in extended ODF Change-Id: Ie39487866f7671f4468a37f48847038fbd2cec2a Reviewed-on: https://gerrit.libreoffice.org/27233 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Laurent BP <laurent.balland-poirier@laposte.net>
2016-08-16GSoC - implement global tokenhandler for odf-tokensDaniel Sikeler
This generates perfect hash for odf-tokens and use them with the tokenhandler. With added test case to check to and fro mapping between tokens. This is taken from Daniel's work in feature/fastparser branch. Change-Id: I7cf77c1eb6c9dd68fd78108c6e0726507c7672e1 Reviewed-on: https://gerrit.libreoffice.org/28073 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2016-07-27tdf#100834 Extend ODF for integer/fraction delimiterLaurent Balland-Poirier
Any string can be used as delimiter between integer and fraction. It is now saved/loaded to/from ODF, as it was from XLS. Change-Id: Ie6364d1cdefc020ea615c18099118135c619f96b Reviewed-on: https://gerrit.libreoffice.org/27262 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
2016-07-27tdf#100755 Extend ODF to allow 0 in fractionLaurent Balland-Poirier
As '0' is now allowed in numerator/denominator this commit extend ODF to save/load this format Change-Id: I3bc897dcce5393453acd7a434a21ae305feeb919 Reviewed-on: https://gerrit.libreoffice.org/27263 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Eike Rathke <erack@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-08 16:43:28 +0000