summaryrefslogtreecommitdiff
path: root/source/auxiliary/zh-TW/highcontrast1.css
diff options
context:
space:
mode:
Diffstat (limited to 'source/auxiliary/zh-TW/highcontrast1.css')
-rw-r--r--source/auxiliary/zh-TW/highcontrast1.css4
1 files changed, 2 insertions, 2 deletions
diff --git a/source/auxiliary/zh-TW/highcontrast1.css b/source/auxiliary/zh-TW/highcontrast1.css
index 5868d97da5..b26468eb46 100644
--- a/source/auxiliary/zh-TW/highcontrast1.css
+++ b/source/auxiliary/zh-TW/highcontrast1.css
@@ -52,7 +52,7 @@ h1, h2, h3, h4, h5, h6
{ margin-bottom: 5pt; }
p, td
- { font-size: 10pt; }
+ { font-size: 11pt; }
h1
{ font-size: 18pt; border-bottom: 1px solid black; padding-bottom: 6px; margin-bottom: 6px;}
@@ -64,7 +64,7 @@ h3
{ font-size: 12pt; }
h4, h5, h6
- { font-size: 10pt; }
+ { font-size: 11pt; }
.relatedtopics
{ font-weight: normal; }
LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/xmlsecurity/source/component/certificatecontainer.cxx
AgeCommit message (Collapse)Author
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-03-18tdf#88205: Use initializer_list ctor in css::uno::SequenceMani Kumar
Change-Id: I95aaefa11c733f5c020600cf13510af1bc9c0de7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112652 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-31Improved loplugin:stringconstant (now that GCC 7 supports it): xmlsecurityStephan Bergmann
Change-Id: I47c93247b9a34abf4b95966833664e63eb57f133 Reviewed-on: https://gerrit.libreoffice.org/76621 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-05-09tdf#42949 Fix IWYU warnings in xmlsecurity/*cxxGabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: I89c77656ea4021cb16bd122cb1dd1cd803390c3d Reviewed-on: https://gerrit.libreoffice.org/71765 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-02-11new loplugin indentationNoel Grandin
look for mixed indentation in compound statements, which makes them hard to read, and sometimes makes it look like a statement is associated with a nearby if/for Change-Id: Ic8429cee1f9a86d938097a4a8769a2bce97b3361 Reviewed-on: https://gerrit.libreoffice.org/63283 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-03-12loplugin:redundantfcast look for redundant copies in return statementsNoel Grandin
Change-Id: I5f416c865dfe1c36018784246a8007452eb42008 Reviewed-on: https://gerrit.libreoffice.org/50996 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-02-07xmlsecurity: create CertificateContainer instances with a constructorMiklos Vajna
Change-Id: I42f0218a46c67062ea6eb0845d978f2630793ec0 Reviewed-on: https://gerrit.libreoffice.org/49304 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2017-12-14No need to keep these whitelisted functions decorated with SAL_CALLStephan Bergmann
The only effect SAL_CALL effectively has on LO-internal code is to change non- static member functions from __thiscall to __cdecl in MSVC (where all other functions are __cdecl by default, anyway). (For 3rd-party code, it could be argued that SAL_CALL is useful on function declarations in the URE stable interface other than non-static member functions, too, in case 3rd-party code uses a compiler switch to change the default calling convention to something other than __cdecl. But loplugin:salcall exempts the URE stable interface, anyway.) One could argue that SAL_CALL, even if today it effectively only affects non- static member functions in MSVC, could be extended in the future to affect more functions on more platforms. However, the current code would already not support that. For example, 3af500580b1c82eabd60335c9ebc458a3f68850c "loplugin:salcall fix functions" changed FrameControl_createInstance in UnoControls/source/base/registercontrols.cxx to no longer be SAL_CALL, even though its address (in ctl_component_getFacrory, in the same file) is passed to cppuhelper::createSingleFactory as an argument of type cppu::ComponentInstantiation, which is a pointer to SAL_CALL function. Change-Id: I3acbf7314a3d7868ed70e35bb5c47bc11a0b7ff6 Reviewed-on: https://gerrit.libreoffice.org/46436 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-08-11convert std::map::insert to std::map::emplaceNoel Grandin
which is considerably less verbose Change-Id: Ifa373e8eb09e39bd6c8d3578641610a6055a187b Reviewed-on: https://gerrit.libreoffice.org/40978 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2017-07-14use more OUString::operator== in test..xmlsecurityNoel Grandin
Change-Id: If5bdd1532be44a47ff7cc3b769be3ea585aea562 Reviewed-on: https://gerrit.libreoffice.org/39685 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>