summaryrefslogtreecommitdiff
path: root/vcl/source/font
AgeCommit message (Collapse)Author
2021-08-18loplugin:passstuffbyrefNoel Grandin
Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-18undo changes to TextAlignCaolán McNamara
revert commit 8689bd5490b473a7ffb149bbe5f7f0683f679c72 Author: Caolán McNamara <caolanm@redhat.com> Date: Thu Jul 29 20:49:29 2021 +0100 convert TextAlign to scoped enum lets leave this as it always was Change-Id: Id4d2a5644974cdd2b0ed6d361d5c52629674d057 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120626 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-03Pass context and resource string down to boost::locale separatelyNoel Grandin
because this is often on a hot path, and we can avoid the splitting and joining of strings like this. Change-Id: I2a24a123a64b762fd0741c45eaca3ad4bdd5580d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119884 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-30convert TextAlign to scoped enumCaolán McNamara
Change-Id: Id2c466eacb44f0ea6adba75a0ac0be8be8e7ed4c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119682 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-30drop FontAlign alias of TextAlignCaolán McNamara
Change-Id: If69ce85482fdb7d33d00fb0cf9b4d4609bb92cd1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119681 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-29rtl::Static -> static localNoel Grandin
in a handful cases, like a map or a vector, we don't need init on demand at all, the default constructor can be laid out at compile time Change-Id: I2d404584b5aa23db7b1f779e160e04e72dd2aa74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119656 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-01configure: Refactor platform defaultsJan-Marek Glogowski
The main idea was to move complexity from source (and Makefiles) into configure.ac, because otherwise these must replicate the "same" branching, often resulting in diversions. Better to keep the logic in one place (configure.ac) and set additional variables to be used directly by source code and Makefiles. Notably this introduce the "using_*" platform flags, which should be considered constants. There is USING_X11, which actually tells, if the build uses the platform's X11 (and I opted for the removal of HAVE_FEATURE_X11). I also consider variables constant, after they have been exported by AC_SUBST, which should never be conditional, or some AC_DEFINE set them for a config header. A large block of defaults depends on $using_x11, so we set them to the same value, but just if the platform doesn't set it. The other important flag is $using_freetype_fontconfig, if the platform uses freetype and fontconfig. The headless plugin uses cairo for its drawing operations and freetype+fontconfig for text, so $test_cairo = $using_freetype_fontconfig. This is independent from a the cairo canvas! The OpenGL X11 code now depends on USING_X11, but it doesn't yet reflect the filter in Library_vcl.mk protecting glx. I don't know how correct this glx filter is, seeing that the source code just checked for "UNX - some non-X11 targets". Change-Id: Id1ba1a967a5d8d10ee217458be879ed00459f7e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116440 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-11change usage of boost::hash_combine to o3tl::hash_combineTomaž Vajngerl
Change-Id: I840518a36ac43d36c95f38e09c7bfcfe1a25a525 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114984 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2021-05-10tdf#105650 different strikethrough offset for vertical writing.Mark Hung
Change-Id: I7f1a8753bb00972865625628baeff76ff5dc4699 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115015 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com>
2021-03-29cid#1209863 rearrange Untrusted loop boundCaolán McNamara
Change-Id: Ib800cc06352f6d885e9530ecee51d7152561570a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113297 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-27cid#1473755 Untrusted loop boundCaolán McNamara
deem_sanizize isn't sufficiently complex to sanize its input apparently Change-Id: Id1d73feefce9b587a8024021d8766267b105b4f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113234 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-27cid#1209863 silence Untrusted loop bound, it *is* tested hereCaolán McNamara
Change-Id: Ie7e1bc3d8cfa8029569259487ea8f8a0d1b6245b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113173 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-03-03Remove unused includeStephan Bergmann
...introduced with 16901e4ccad95d55d4ae0fa2d6f6103b4177592e "Simplify static string generation" for std::iota, which in turn was removed again with ccb101abd46e1d632d18b30226a6bffed7a66381 "call to consteval function is not a constant expression (HAVE_CPP_CONSTEVAL)" Change-Id: Id923f32c853f51971fa3f70f003ac1e411cb8a5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111818 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-03-01do not repeatedly call getenv("SAL_NO_FONT_LOOKUP")Luboš Luňák
In the profiling data I see it actually takes 1% of the CPU time. Change-Id: I55de0191ac9fb17095e7d137f4efc1735936e233 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111571 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-01call to consteval function is not a constant expression (HAVE_CPP_CONSTEVAL)Stephan Bergmann
...when building with suitable --with-latest-c++ since 16901e4ccad95d55d4ae0fa2d6f6103b4177592e "Simplify static string generation", > vcl/source/font/font.cxx:396:20: error: call to consteval function 'rtl::OUStringLiteral<96>::OUStringLiteral' is not a constant expression > return OUStringLiteral(aArray); > ^ > include/rtl/ustring.hxx:95:16: note: read of non-constexpr variable 'aArray' is not allowed in a constant expression > assert(literal[N - 1] == '\0'); > ^ > vcl/source/font/font.cxx:396:20: note: in call to 'OUStringLiteral(aArray)' > return OUStringLiteral(aArray); > ^ > vcl/source/font/font.cxx:393:25: note: declared here > sal_Unicode aArray[127 - 32 + 1]; > ^ So just keep it easy and spell out the contents explicitly, at least for now. Change-Id: Ic7d22e7fec3f909e219b428e9b6cf6045a08cb44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111734 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-24disable-pch fixNoel Grandin
Change-Id: I14760d858c1500800c9360530b0408986122e00b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111444 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-24Removed duplicated includeAndrea Gelmini
Change-Id: Ie6aac80ed560ad49dd2167afa965a768aac0818b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111482 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-02-24Simplify static string generationMike Kaganski
Change-Id: I838d3900a6f3ba28fd30cd2e3ec7a7f74a7736b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111431 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-23tdf#127471 Detect&Correct EMF/WMF with wrong FontScaleArmin Le Grand (Allotropia)
Before correcting our EMF/WMF export to write the Windows- specific data in the case of FontScaling, we wrote these files with wrong FontScaling. This change tries to detect and correct this at import, so that newer versions of the office on all plattforms can again load old, from us but not on Windows written EMF/WMF files. With this change we can read again all new and old EMF/WMF files (see table in task, comment 80). Change-Id: I1a0b0ab5f57c7cd40520401568af05cab4ecb4c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111399 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-02-18disable-pch fixNoel Grandin
Change-Id: I1200bf7818be7f8142d0a5282d6cf2ef5993d3fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111098 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-18Fix an OUString constructionStephan Bergmann
...introduced with 9d161857f1d4afcb772b477455797a2da0e47a9b "tdf#127471 correct EMF/WMF im/export for scaled font" Change-Id: I2b807e102ca7f71a61794f511dee302c7e509026 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111095 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-17tdf#127471 correct EMF/WMF im/export for scaled fontArmin Le Grand (Allotropia)
If FontScaling is used, system-dependent data is held at vcl::Font Width(). Already if not scaled, we have three definitions: Width is zero, Width is equal to Height (unx) or - on Windows - Width equals avgFontWidth. If used it is W!=H where on unx Width equals Height multiplied with the scale factor. On Windows, this is Width multiplied with the only there existing avgFontWidth. Unfortunately that is ex/imported (since ever) undetected to EMF/WMF thus making EMF/WMF files containing FontScaling system-dependent - on which system was LO running when creating the file? The error can be seen when loading such a EMF/WMF on the vice-versa system, the FontScale is very ugly and wrong. Since EMF/WMF *are* Windows-specific formats the Windows-like definition is the correct one. This change makes all other systems export that now, and adapt on import to their system- specific definition (assuming coming from Windows). As can be seen, the difficulty is that these adaptions are necessary on non-Windows plattforms, but these do not have that avgFontWidth available. Thus I made a deep-dive investigation and multiple experiments to create a as similar as possible value to apply the needed calculations. For details and discussion refer to the bug description. Change-Id: I983fb6d882e2e8fccf9c8460f01509201d8157f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111000 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-02-04Fix typoAndrea Gelmini
Change-Id: I2202a3208b2b65f2ca7fb887c48fce311aef8f7f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110390 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-02-04Missing includesMike Kaganski
... after commit 40b56cd8da8c38582dc4660b486993d1b4711535 Change-Id: I083cdfde6feda267e45060e6ff0593ead4ede9aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110384 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-03tdf#127471 improve SVM FontScaling im/exportArmin Le Grand (Allotropia)
Due to svg::Font Width and it's expression of FontScaling being system-dependent the FontScaling when exchanging beween win-based SVM creators and others was creating errors. Corrected this to work now with newly created SVM files in both directions. For more aspects see discussion in task. Change-Id: I326e4e7e895a9dfc3cdfc5323174ca81e22795e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110330 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2021-01-14cid#1471346 Uncaught exceptionCaolán McNamara
Change-Id: I535affd6597636aa32e1cf9c6005238f9503ef6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109266 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-08use more IsTransparentNoel Grandin
Change-Id: I3ef18a2601a51d56614b5da9b56e871bd33ec79e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108942 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-30vcl: remove {Read,Write}ImpGraphic and ImplExportNative from GraphicTomaž Vajngerl
ReadImpGraphic and WriteImpGraphic have been reimplemented in the TypeSerializer some time ago, but the code has not yet been moved to use that class. This commits does that and changes all the code using those 2 methods and removes them. With this implemented in the TypeSerializer, it is easier to handle In addition it also removes ImplExportNative (and the method on the Graphic interface). This was really used only in one method, and it could be implemented in the mthod itself. Change-Id: I0982429d1c1d5ed7ef07627d87ed9a08df43f040 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108256 Tested-by: Tomaž Vajngerl <quikee@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-12-24custom literal for Degree10Noel Grandin
Change-Id: Id13869138a622e62d9ffebf2c89bddccda6aff01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108238 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-24loplugin:stringviewparam extend to comparison operatorsNoel
which means that some call sites have to change to use unicode string literals i.e. u"foo" instead of "foo" Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-28std::set->o3tl::sorted_vector in vclNoel Grandin
Change-Id: Ie486b629b4074da5121b55c76965aeb8ea057f31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104904 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-21new tools::Degree10 strong typedefNoel Grandin
partly to flush some use of "long" out the codebase, but also to make it obvious which units are being used for angle values. Change-Id: I1dc22494ca42c4677a63f685d5903f2b89886dc2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104548 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-19use tools::Long in vclNoel
Change-Id: Ice1055021e8568634e9a66ba89d3bb4ef4e731df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104522 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-04ofz#26122 allow NINSIZE input full elementsCaolán McNamara
Change-Id: Ifbde8fc055a91e23db08508a34ce4664d2f1f96f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103906 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-30ofz#25989 cmap parsingCaolán McNamara
Change-Id: I048e5d88d5926a4afa75afab18db5ca6354e2454 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103641 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-23ofz#25868 Timeout, encoding conversion only sane in 0..SAL_MAX_UINT16 rangeCaolán McNamara
so ignore points outside that range to avoid ludicrous ranges that aren't possible in the input encoding Change-Id: Ifb7b9b389d4a31b8820a7da661249223fe1e110c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103237 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-22ofz#25855 overflow in nTmpOffsetCaolán McNamara
we already know nLength is >= 24 so just move the calc to the other term Change-Id: Ic52f1686ccf81e6b13d7eb7e74dbd9cb51c8ea01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103183 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21Missing includeStephan Bergmann
(for std::max, since f8474367449a1b6b54918d2753e3a36798761839 "ofz#25774 keep ParseCMAP within legal area") Change-Id: I873c788577e9ec3bd54d9e637d2cf86be7c1f6e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103089 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-19Fix crash from broken font CMAP subtableJan-Marek Glogowski
ParseCMAP crashes on a broken CMAP subtable of a font used by the bugdoc of tdf#119074, which returns a negative offset (technically it's large positive offset turning into a wrong negative integer, which is still out of bounds of the CMAP overall size - you get the point). This simply ignores that broken subtable, checking for other existing ones. Regressed-by: c7482bc2904401e7d975b5721ec861b8589253f9 Change-Id: I95820fe3bb6bd2fe2e0cf9d4c3536abce31fd497 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103033 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18ofz#25774 keep ParseCMAP within legal areaCaolán McNamara
Change-Id: Ic68fadd3d63631cbccda76e7679d95bb89452d25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103017 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-16ofz#25696 OOMCaolán McNamara
Change-Id: Ia69e9ce1ca0156e960dddb7e0bf98dfd2be2d7cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102846 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-15ofz#25684 keep ParseCMAP within legal areaCaolán McNamara
Change-Id: Iee18b5a9390b79efa67414ea2d229d2816c84e18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102776 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-12Replace remaining uses of sal_uCharJulien Nabet
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: I1ed6a56075a47fbfeac97388432bffcbd2ef1f7b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102491 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-14inline some use-once typedefsNoel Grandin
Change-Id: Ifefdb1ad20d09e257064171e458b2eb33065f5de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100733 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-02Upcoming improved loplugin:staticanonymous -> redundantstatic: vclStephan Bergmann
Change-Id: I7559ab5c98a22e315549b5dfc651e937697cac22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97742 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-26Upcoming improved loplugin:elidestringvar: vclStephan Bergmann
Change-Id: I4ffe3cfd0ed9a45607e978df88ae230ec04a152b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97204 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-02-07 23:04:13 +0000