summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2020-09-30tdf#137013 fix Writer find toolbar ui regressionsJim Raykowski
introduced by enhancement patch tdf#132366 Change-Id: I951fcd7891c75e7fbf715581c316b4446d967cd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103499 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com>
2020-09-29tdf#136520 allow color popdowns to be tearable againCaolán McNamara
Change-Id: Ic92ef5235662e1680aadb5666e05dad1bf808e9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103625 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-29disentangle AA and B2D use in VCL drawingLuboš Luňák
A number of powerful functions using B2D polygons such as OutputDevice::DrawPolyLineDirect() were used only if AA was enabled. So e.g. dashing for an AA-ed polyline could be drawn directly using the function, but with AA disabled had to be done manually by a number of polygon operations. Which doesn't make much sense, surely these powerful functions can also draw without AA if set so (and indeed that's mostly the case). And DrawPolyLineDirect() even had a flag to bypass the check. So simply try to use B2D-based drawing whenever possible, AA or not. The previous commit had already changed the naming of the AA option to not include B2D in the name. This seems to come from https://bz.apache.org/ooo/show_bug.cgi?id=88795, which doesn't explain why AA only. There are other bugreports such as https://bz.apache.org/ooo/show_bug.cgi?id=101491 and https://bz.apache.org/ooo/show_bug.cgi?id=98289 that are related, but there I cannot see any difference with this patch. And all unit tests pass. Change-Id: Ibb5938e8fff9b7452bac4bf12ed3e42fd3e5d645 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103354 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-28rename for disentangling AA and B2D use in VCL drawingLuboš Luňák
This renames AntialiasingFlags::EnableB2dDraw to just Enable, and the AntiAliasB2DDraw names to just AntiAlias. This is in preparation for a second commit that will actually separate the AA and B2D functionality of these flags. Change-Id: I9cc215c5752dfabce41e00e19d9074fc8dc3d4de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103416 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-26revert recent Polygon commitsNoel Grandin
This reverts commit 0cabffc05f3b40f5ee897df73475e09a3c05fc7 tools::PolyPolygon -> basegfx in canvas and commit 2c5d5a6d55a1ebd153f05523972a2c625484bde2 tools::PolyPolygon -> basegfx in filter Comment from quikee: The interpretation of integer polygons and floating point polygons (or any other float vs. int drawing primitives) are different, so you have to be really careful when changing, that the result after the change is still the same. A big problem is that we still have the metafile in OutputDevice, which is completely integer based - so there will be conversions that go from int representation to float representation to int again and to float (because backend is in floating point) and I really fear that because of this there will be regressions and even if not, it could make changing later more painful. This is the reason I wouldn't change these things without having tests that would show when there is a difference in rendering. Change-Id: I54addca4e5a72196b5f77f6c7689eb716451c1dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103483 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-26tools::PolyPolygon -> basegfx in canvasNoel Grandin
Change-Id: I7b5ac7b434932515895bf60acfa0109e6a2ebd18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103417 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-26tools::PolyPolygon -> basegfx in filterNoel Grandin
which needed an extra method on OutputDevice. Also add some utility methods to make future conversion work easier. Change-Id: I57c5bc7505e656a014f2e723fea2aa79271e6515 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103415 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-25remove ImpClearVars, set values in the constructorTomaž Vajngerl
Change-Id: I8ff465d5755dae7098293702115ab08055814754 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103403 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-25cid#1448292 coverity has difficulty with css::uno::SequenceCaolán McNamara
current attempt isn't working, try a different approach to silence these warnings Change-Id: I0cc97df0897abc665dfbb683d7aa0df55f8affb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103387 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-25don't write metafile action twice in DrawPolyLineDirect()Luboš Luňák
All other functions calling it already do so, so write it only when called from the outside. Change-Id: If17d973a5d6b3797db46e91a1ec36606a89c5d07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103353 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-25fix Graphic duplication in import and add GraphicMapperTomaž Vajngerl
When importing writerfilter, we change to oox when importing images. This transition doesn't store any previous contexts and all instances are reset. The problem occurs when we have identical images because the transition erases all caches we have to determine if an image has already been imported or not, which causes that we import the same image multiple times which create unnecessary copies. This introduces the XGraphicMapper, which can be used to store the XGraphic for a key and can be transferred between writerfilter to oox. With this we can remember which images were already imported and don't create unnecessary internal copies which decreases memory. This also includes a test which checks that the import and export doesn't produce unnecessary copies of identical images. The test checks that for OOXML, ODF and MS Binary formats. Change-Id: I33dc19218c565937fab77e132b3a996c51358b6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103283 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-25xmlsecurity: fold pdfio into pdfsignaturehelperMiklos Vajna
Most of the initial pdfio was moved to vcl as vcl::filter::PDFDocument. A small part was left here, because it depended on NSS. Then later the NSS bits were moved to svl::crypto::Signing. The rest is just a small amount of code, keeping that separate from PDFSignatureHelper, which is its only user makes little sense. With this, vcl::filter::PDFDocument is an implementation detail of PDFSignatureHelper during signature verification. Change-Id: I6230f9e46deeff7159970f88dbb3bd2de0e9ce7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103350 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-25tdf#124176 Use #pragma once in some include/Andrea Gelmini
switch to #pragma It passed "make check" on Linux Change-Id: Idb01cc7d4ccf404df82016b1b3356400320eb317 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103305 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-09-24tdf#134782 sw,unotools,officecfg: adapt configuration and UIMichael Stahl
Store AddParaLineSpacingToTableCells in configuration as "AddTableLineSpacing", consistently inconsistent like AddTableSpacing (the <desc> elements are not subject to translation). Adapt SwCompatibilityOptPage with some ugly hacks to allow 3 different states (TriState) for the corresponding checkbox that map to false/false, true/false and true/true. The checkbox widget doesn't allow to change *to* indeterminate but at least the status of the document can be displayed this way, with a non-obvious tweak to optcompatpage.ui to reference "checktri1" column. Change-Id: I5f32e05c93b5e16e782cba5d1d055809d9e5e251 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103318 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-24Add English Kenya LCID 0xAC09 {en-KE} langtag mapping, tdf#115436Eike Rathke
Change-Id: I0c32ffa2d7f316b3e97dc597da8539842ad51367 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103300 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-09-23Consolidate on a single sal_UCS4 declaration in vcl/vclenum.hxxStephan Bergmann
Change-Id: I910dba4c4ec6151a08dbb4e679c394ebe8ea5261 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103249 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23tdf#136949: Revert "tdf#115753 fix table border missing when there are ↵Xisco Fauli
merged cells" This reverts commit 2b19cd84f10552c438dace0a4c52a70ccd440369. Change-Id: I5f3f51e0e816416c364155ab67bc37bb8c6fe545 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103187 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-09-23tdf#136566 XLSX export: fix lost scheme based line colorsRegényi Balázs
by converting scheme color identifiers to colors temporarily. Because we haven't exported theme XML yet, we could not import shapes of these exported documents correctly, resulting missing lines. Co-authored-by: Szabolcs Toth Change-Id: I4f3d19cb8a9a851fb07a97f798195011e420d441 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102722 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-22Related: tdf#132970 handle more places with potentially utf16 bulletsCaolán McNamara
Change-Id: Iac6b319700d610b5a1debff0a633172b2411c40e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103161 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-22Simplify those assertLayout checksStephan Bergmann
...recently introduced with 52a49f9e480ca03e231cfda82640a928393131c9 "static_assert that O[U]StringLiteral are layout compatible with rtl_[u]String" Change-Id: Ie89e92aa4230329aa582c4211c2001117d2287b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103138 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-22__coverity_tainted_data_sanitize__ can't be constCaolán McNamara
apparently, so use const_cast on its input instead Change-Id: Ib0dfd94c144a2509470ca7a9b3b8fbfacbfd7581 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103148 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-22tdf#132970 SMP bullets mangledCaolán McNamara
working: a) bullet preview b) writer rendering c) save to odt a) load from odt Change-Id: I2f85576389fe4f0437f81799c14dfd98c8c40b2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103129 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-22Fix symbols already defined MSVC link errorMike Kaganski
... after af90b8089405d6f042207f5639e750f08798ae92, which made VCL to instantiate exported implementation of the template. Fixes the error: ivcl.lib(vcllo.dll) : error LNK2005: "public: virtual void __cdecl cppu::WeakImplHelper<class com::sun::star::frame::XStatusListener>::acquire(void)" (?acquire@?$WeakImplHelper@VXStatusListener@frame@star@sun@com@@@cppu@@UEAAXXZ) already defined in helpinterceptor.o Modelled after 013f84d06f7ad76d72b863170891589c3504508c. Change-Id: I40ba226d95ad2f1fda177839d9468d6861ca54c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103144 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-09-22Avoid unique_ptr(nullptr_t) ctor for incomplete argument typeStephan Bergmann
...hoping that this will avoid > In file included from /home/tdf/lode/jenkins/workspace/lo_ubsan/sw/source/filter/ww8/wrtw8nds.cxx:25: > In file included from /home/tdf/lode/jenkins/workspace/lo_ubsan/sw/source/filter/ww8/docxexport.hxx:23: > In file included from /home/tdf/lode/jenkins/workspace/lo_ubsan/sw/source/filter/ww8/wrtww8.hxx:23: > In file included from /home/tdf/lode/jenkins/workspace/lo_ubsan/include/sot/storage.hxx:24: > In file included from /home/tdf/lode/jenkins/workspace/lo_ubsan/include/tools/stream.hxx:28: > In file included from /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/memory:80: > /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/unique_ptr.h:76:16: error: invalid application of 'sizeof' to an incomplete type 'sax_fastparser::FastAttributeList' > static_assert(sizeof(_Tp)>0, > ^~~~~~~~~~~ > /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/unique_ptr.h:268:4: note: in instantiation of member function 'std::default_delete<sax_fastparser::FastAttributeList>::operator()' requested here > get_deleter()(__ptr); > ^ > /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/unique_ptr.h:233:45: note: in instantiation of member function 'std::unique_ptr<sax_fastparser::FastAttributeList, std::default_delete<sax_fastparser::FastAttributeList> >::~unique_ptr' requested here > constexpr unique_ptr(nullptr_t) noexcept : unique_ptr() { } > ^ > /home/tdf/lode/jenkins/workspace/lo_ubsan/include/sax/fshelper.hxx:33:34: note: forward declaration of 'sax_fastparser::FastAttributeList' > namespace sax_fastparser { class FastAttributeList; } > ^ (<https://ci.libreoffice.org/job/lo_ubsan/1767/>) with libstdc++ prior to <https://gcc.gnu.org/git/?p=gcc.git;a=commit; h=c3ba63c314d61362f7c48c4feeefa13ea3978344> "PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors". Change-Id: Ie3b86b83d0b0e70fe44e2b2022d410643e265fbf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103139 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-21static_assert that O[U]StringLiteral are layout compatible with rtl_[u]StringStephan Bergmann
...as was suggested by Mike Kaganski in a comment at <https://gerrit.libreoffice.org/c/core/+/102222/10# message-aa8bcf42f04686766440e2848c7d1f76f474f2f8> "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString". Doing so revealed that at least lopglugin:unusedmember needs to handle InjectedClassNameType as an alternative to RecordType in at least one place. (More places across compilerplugins might benefit from handling InjectedClassNameType too, but which did not lead to assertion failures for now and should be addressed in follow-up issues.) Change-Id: Icdb8b069324b5ce5f3c7c6b92989379ccb67fc8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103125 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-21No need to make the OString(std::string_view) ctor explicitStephan Bergmann
<https://gerrit.libreoffice.org/c/core/+/101829> "Make std::u16string_view -> OUString construction explicit" (which has meanwhile been abandoned) had intended to make the OUString(std::u16string_view) ctor explicit, mostly not for the rationale given in the commit message there (it being "a rather expensive operation"), but rather to avoid anticipated ambiguity issues when introducing e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString"---but which has ultimately been added in a form that did not give rise to such ambiguity issues after all. 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String" had added the OString(std::string_view) ctor as explicit to match the corresponding explicit OUString(std::u16string_view) from the above <https://gerrit.libreoffice.org/c/core/+/101829>. But as that has now been abandoned, there is no good reason to keep this ctor explicit, either. Change-Id: I05742de5f3992ad5995149631bf8d55c8d448387 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-21weld infobarsCaolán McNamara
note: "pushed" status listener case dropped. Doesn't seem to be an expectation for it to something in infobars, and there doesn't seem to be a working case anyway. Change-Id: I7869cc05de9918f0dd70e28b0087205db6c9506c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101945 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21missing identifierCaolán McNamara
Change-Id: Id3a41a7832299d51776ccd9ea008092c0ee62aab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103093 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21tdf#136620 tdf#136708 filter,oox,sw: fix export of 2 different wrapsMichael Stahl
This reverts commit 2cb90a5c87fe46737c8d840967d8836284f92ffd. Revert the change to EscherPropertyContainer, which was completely bogus, based on pre-existing bogus code in VMLExport::Commit(). The problem is that ESCHER_Wrap values are for wrapping text *inside* a text box, which is "mso-wrap-style" in VML, whereas VML's w10:wrap element defines how text wraps *around* a shape, doesn't exist as an ESCHER property and is specific to Word formats. Instead, export the w10:wrap element in VMLExport::EndShape(). This has 2 callers, WriteActiveXControl() and writeVMLDrawing(). Furthermore the value "none" wasn't written for WrapTextMode_THROUGH, which caused the wrap element to be omitted in that case. Change-Id: Id4a01fcb2ea73fa9bef4ee8769b5e0680e059f15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103009 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-09-21tdf#136247 Change element order of data labelsGülşah Köse
Reference OOXML (Appendix B.5.1, line 248) Change-Id: Idf5c2546b4ad65c8e78ca03e18ecfa575ef17fe8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103005 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2020-09-20fix __coverity_tainted_data_sanitize__ signatureCaolán McNamara
argument of type "const sal_Int8 *" is incompatible with parameter of type "void *" Change-Id: I0f1dba700516043d54c4e46edae9753312b5ad2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103071 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-20tdf#132366 Writer enhancement that highlights search resultsJim Raykowski
This enhancement selects outline headings in the Writer Navigator content tree according to 'Find All' search results. It does this when the content navigation view is set to show headings content only. Change-Id: I77dabcdd38c8877b7f8a177689da094638d5fe00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92886 Tested-by: Jenkins Reviewed-by: Jim Raykowski <raykowj@gmail.com>
2020-09-19tdf#134157 fix Edit with external tool causes a CPU hitTomofumi Yagi
Switch Idle to 100ms Timer for fixing the bug Change-Id: I85a9bdcb173edd28d952d8e91c1b93d748e69206 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102984 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-18[API CHANGE] tdf#136836 emfio: set size hint on inner PDF if used as shape fillMiklos Vajna
The bugdoc has a shape, its bitmap fill is an EMF, which is actually a PDF. The PDF is has a height of 5cm, but the shape has a height of 14 cm. Inform vcl::RenderPDFBitmaps() about the size of the shape, so the result won't be blurry. This approach makes sure that we don't unconditionally render at higher resolution, i.e. the "load a PDF of 100 pages into Online" use-case won't use more memory than before. API CHANGE, because the EMF reader is only available via UNO, though it's likely that no actual external code would ever invoke it directly. Change-Id: If1d8def0136d408a31a0cc54777a7f26430a0ff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102996 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-18jsdialog: use window only if visibleSzymon Kłos
When there is a name conflict we should take currently visible window. Change-Id: Iaccf03a78b083ecaca0ee6aa538674a6de093a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102903 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102983 Tested-by: Jenkins
2020-09-18Online: Show input help on Online / Core part.gokaysatir
Change-Id: I9d10179f266a725b770fdae50045fdb5d77178ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102708 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com> (cherry picked from commit 110069adbba4d272450b30fa03c56efbd478e84c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102935 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-18Resolves tdf#97918 - Individual UNO commands for distribution optionsHeiko Tietze
New UNO commands added, SID_DISTRIBUTE_DLG bend to dropdown, ui removed Menus and toolbars adjusted Change-Id: Ic0a3cc299f745a1a0cd18edead1f410ff57a1f1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102272 Tested-by: Jenkins Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
2020-09-17fix LTO+mergedlibs on windowsNoel Grandin
Change-Id: I3d95d566db76e14532945b881b1847ea8c7e3153 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102946 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-17osl+tools: fix Windows Arm64 buildJan-Marek Glogowski
Change-Id: I17cbc1c8474880024921f476aa602d61978da868 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102851 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16[API CHANGE] Remove unused and deprecated sal_Char/sal_sChar/sal_uCharJulien Nabet
These are deprecated since 2013, see: deprecated since 2013, see: author Stephan Bergmann <[hidden email]> 2013-11-27 12:50:35 +0100 committer Stephan Bergmann <[hidden email]> 2013-11-27 12:52:32 +0100 commit d8565bd266939b4ae4231f5b2c7d6260bee404e9 (patch) tree c4dc8575d838bf7f588ebb5102acc62cf7651336 parent b5fced896632a3c07586702b461545667b33966e (diff) Mark sal_Char, sal_sChar, sal_uChar as deprecated ...there never was a good reason to have SAL abstractions for the C/C++ char types anyway. and last uses of sal_Char and sal_uChar have been replaced with: - https://cgit.freedesktop.org/libreoffice/core/commit/?id=04203a26757d26814a18c3251d1a97f6ded64a62 author Julien Nabet <serval2412@yahoo.fr> 2020-09-11 22:05:12 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2020-09-12 13:36:42 +0200 commit 04203a26757d26814a18c3251d1a97f6ded64a62 (patch) tree 80962f43d3b46e8670ad49068a1a6e8459c22f39 parent 05d5062dca095f2e53de26db41edeb0b1279138b (diff) Replace remaining uses of sal_Char + remove sal_Char check on compilerplugins - https://cgit.freedesktop.org/libreoffice/core/commit/?id=70666469b87ab1e3589db0f5f7a236d744e83733 author Julien Nabet <serval2412@yahoo.fr> 2020-09-11 17:38:21 +0200 committer Noel Grandin <noel.grandin@collabora.co.uk> 2020-09-12 18:54:15 +0200 commit 70666469b87ab1e3589db0f5f7a236d744e83733 (patch) tree 88ee34da282712ea32e6354be92472f5fa52f1d4 parent 8214051829468c783404faf19194b26b35833e41 (diff) Replace remaining uses of sal_uCharHEADmaster The goal is then to remove sal_uChar completely since it's been deprecated in 2013! See http://document-foundation-mail-archive.969070.n3.nabble.com/About-removing-long-time-deprecated-types-from-public-API-tt4287268.html Change-Id: Ifc6057f49b6022a917d479c6f403b3f65454c510 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102436 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-15Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: Id56c9b50540a4de1950dfc4b49ea783d164a6604 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101811 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-15Replace FindCmap with ParseCMAPJan-Marek Glogowski
This introduces a potential performance regression, because FindCmap works on the existing font tables and just sets up a lookup function, while ParseCMAP creates some optimized, in-memory lookup table, which needs a bit more work, but is faster in its usage, I think. At least the initial usage is faster the old way, as the CMAPs aren't decoded at all. As you can see, the old code is just used on Windows and MacOS / iOS. Deep in the bowels of the PrintFontManager, the CMAP is also decoded using ParseCMAP... So I'm not sure this potential regression really exists. Most fonts will already have a decoded CMAP, so my guess is this is actually faster in the end. No idea, how to measure. Change-Id: I52caac1264cd3ff11a2a3fa6e9c800f67f146a79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102685 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-13Unify the code used to get object shell for componentsMike Kaganski
and their parents across the codebase. Change-Id: Ifb37fb940d285f81c1724a912204533e8c3b0044 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102546 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-09-13std::set->o3tl::sorted_vector in svxNoel Grandin
Change-Id: I86154a8ddf885ea23ff29e4df1b67e7501b9165b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102536 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-12replace sal_IntPtr with simple integer typeCaolán McNamara
Change-Id: I5aaf606b684b69641a872b3405b4d4d378289ad4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102466 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-12Replace remaining uses of sal_CharJulien Nabet
+ remove sal_Char check on compilerplugins Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9 Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-11oox smartart: add support for syncing font heights of multiple shapesMiklos Vajna
When 2 or more shapes have their text set to autofit and they have a constraint like: <dgm:constr type="primFontSz" for="des" forName="node" op="equ"/> Then make sure that the automatic font size is the same for all shapes and all content fits, by using the smallest scaling factor from all relevant shapes. Some rework is needed, because normally oox::drawingml::Shapes don't have access to their parents, at the same time there can be multiple SmartArts on a single slide, so storing the grouping info in the filter is problematic, too. Solve this by storing the grouping in the toplevel oox::drawingml::Shape and exposing them in XmlFilterBase just during the time the children of the toplevel shape of the SmartArt are added. This works, because we know SmartArts can't be nested. Change-Id: I6c591eadc7166c7c42752650afdb7ee1e416cff6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102490 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-11tdf#135667 DOCX export: fix border line of OLE objectsAttila Bakos
which wasn't exported. Note: the enlarged monolithic export function was split in the following new functions: - WriteOLEShape() exports the replacement shape of the OLE object. - GetOLEStyle() returns the string value of the style attribute. - ExportOLESurround() handles the surround settings. Also add GetVMLShapeTypeDefinition() to reuse picture frame VML formula string used by VMLExport. Co-authored-by: Arató Dániel (NISZ) Change-Id: I29800a50c60a824a14849ac286a18e5e2f97c689 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102034 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2020-09-11invalidate prerendered fontname cache on style changeCaolán McNamara
Change-Id: Ie2111f23dc3346b914442090e3d9257c5659fafc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102459 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2025-02-27 03:29:20 +0000