summaryrefslogtreecommitdiff
path: root/sdext
AgeCommit message (Collapse)Author
2022-02-21Recheck modules sd* with IWYUGabor Kelemen
See tdf#42949 for motivation Change-Id: I97c1a0e8c7f26807b12e6062581066d09ea13086 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130114 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-02-21tdf#143148 Use pragma once instead of include guardsDeep17
Change-Id: I8f2dd2049a70dde809a1b1afb1f67d5feaf60d8b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130222 Tested-by: Jenkins Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2022-02-17Parameter should apparently be of type sal_Int32Stephan Bergmann
It was like this ever since 969aac0edf437ec0cad0baadfde46188c4822161 "INTEGRATION: CWS pdf25", but the single caller of encodeBase64 passes a sal_Int32 value, and all use of i_nBufferLength in encodeBase64 are in sal_Int32-based computations. Change-Id: I2963a05bf5a83aaee25cdd71c11d28481b28061a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130067 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-04sdext.pdfimport tdf#137128: Recognize more font name and weight...Kevin Suo
...values from the embeded 'PS' font names. Change-Id: I8465a6b1d845ce626848112f0a735a9ee3696e5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129136 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-02-04sdext.pdfimport: these SAL_WARN should be SAL_INFOKevin Suo
SAL_WARN should be some message which showns where the program runs abnormally. Normal debugging output code should be SAL_INFO, and if you have set it to SAL_WARN for easy debugging you should set it back to SAL_INFO or delete those lines when submit. Otherwise our dbgutil terminal will be flood with unrelated messages Change-Id: I0767bfbeb7a21f208be12208009ccda8b6c72bab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118763 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-12-10Generally determine Rdb content from gb_*_set_componentfile callsStephan Bergmann
...instead of by listing the content somewhat redundantly in the Rdb_*.mk files, to avoid duplication of logic for components that are only built conditionally (and thus should only be included conditionally in the corresponding Rdb). To achieve that, add an "rdb" parameter to gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros that internally call gb_ComponentTarget_ComponentTarget), which is used to make the appropriate gb_Rdb_add_component call internally from within gb_ComponentTarget_ComponentTarget. (As a special case, gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that has already been done by the corresponding gb_Library_set_componentfile call, so allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to support that special case.) Most Rdb_*.mk files are thus mostly empty now. One exception is i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as needed during the build in CustomTarget_i18npool/localedata. 1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built components" had already tried to do something similar (in addition to other things) under a new --enable-services-rdb-from-build option. However, that approach had four drawbacks that this approach here addresses (and which thus partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b): 1 Rdb_services shall not contain the component files of all libraries that are built. While that commit filtered out the component files that go into Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files that go into others like Rdb_postgresql-sdbc (connectivity/Rdb_postgresql-sdbc.mk). 2 The code added by that commit to Makefile.gbuild codified the knowledge that there is an Rdb_services, which is brittle. 3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge (for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle. 4 Introducing an --enable-services-rdb-from-build option needlessly provided two different ways how the content of Rdb_services is assembled. The changes done here would leave --enable-services-rdb-from-build as a misnomer, as it no longer controls how Rdb_services is assembled. I thus renamed it to --enable-customtarget-components, as that is apparently what it still does now. Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-12-09change use of wrong slot id to name of correct commandCaolán McNamara
slot was introduced with commit 27452a082237065ac4cf475c8398241907164b2c Date: Wed Oct 10 14:32:04 2007 +0000 INTEGRATION: CWS pppopt02 (1.24.74); FILE MERGED 2007/09/28 14:52:06 sj 1.24.74.1: added slot to be able to clear the undomanager as 27115, but got renumbered to 27118 with commit 35fe915b7cf508356a88897d520b89fc986407fb Date: Wed Jun 10 15:47:52 2015 +0200 Fix sd ID conflicts and duplicates using its name is verified to call the expected handler for it Change-Id: I656d91937612b0807353455930328aa37d5eecb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126581 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-11-26Drop support for poppler w/o cpp/poppler-version.hJan-Marek Glogowski
Seems the first poppler including poppler-cpp.pc.in and also cpp/poppler-version.h.in was 0.14.0. So this also increases the minimal system poppler dependency from * poppler 0.12.0 (Wed Sep 9, 2009) to * poppler 0.14.0 (Tue Jun 8, 2010) Compiling the internal poppler, we're up-to-date anyway. Change-Id: Iee07cfeb43f4320fd596c772eeb26662505d0daf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125778 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-11-23O[U]String::replaceAt overloads that take string_viewNoel Grandin
which results in lots of nice string_view improvements picked up by the plugins Change-Id: Ib0ec3887816b3d4436d003b739d9814f83e244b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125657 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-11-03loplugin:finalclassesNoel Grandin
Change-Id: I10ff73f89c965beb3cfb5fc3a40dd959d8f77aaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124600 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-31Prepare for removal of non-const operator[] from Sequence in sdextMike Kaganski
Change-Id: I1992d1ffbbc80efe9749ebd254971a0a92a10019 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124386 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-22Revert part of "Simplify vector initialization in sdext"Julien Nabet
since it needs 2 allocations instead of one This partially reverts commit d64a6e2245169e5e4a3f8bc5388b4fff4984e5f4 . Change-Id: Iadd8193a02bd922105c082fe3bbcc6f8e9f96b22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124069 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-22Optimize assignment from OUStringLiteral to OUStringStephan Bergmann
...by making the OUString's pData point to the OUStringLiteral, instead of copying the contained characters. This is one of the improvements that had not been done as part of e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString": "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." (Simply dropping the OUStringLiteral overload was not possible in this case, though, as that would have lead to ambiguities among the various OUString and std::u16string_view overloads.) The now-deleted OUStringLiteral rvalue reference overload means that some existing assignments from ternary-operator OUStringLiteral<N> to OUString no longer compile and had to be replaced with uses of std::u16string_view. Those had not already been replaced in e6dfaf9f44f9939abc338c83b3024108431d0f69 because they happened to use OUStringLiteral instances of identical length N in both arms of the ternary operator, so did not already start to fail to compile back then. Change-Id: I328e25b8324d045774e811d20a639f40d6a9a960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124040 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-16Simplify vector initialization in sdextJulien Nabet
Change-Id: If3cebeadff5496ae214614b49116060d24b6082f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123696 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-15Remove non-const Sequence::begin()/end() in internal codeMike Kaganski
... to avoid hidden cost of multiple COW checks, because they call getArray() internally. This obsoletes [loplugin:sequenceloop]. Also rename toNonConstRange to asNonConstRange, to reflect that the result is a view of the sequence, not an independent object. TODO: also drop non-const operator[], but introduce operator[] in SequenceRange. Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-14Avoid COW overhead using css::uno::SequenceMike Kaganski
The scenarios are: 1. Calling sequence's begin() and end() in pairs to pass to algorithms (both calls use getArray(), which does the COW checks) 2. In addition to #1, calling end() again when checking result of find algorithms, and/or begin() to calculate result's distance 3. Using non-const sequences in range-based for loops, which internally do #1 4. Assigning sequence to another sequence variable, and then modifying one of them In many cases, the sequences could be made const, or treated as const for the purposes of the algorithms (using std::as_const, std::cbegin, and std::cend). Where algorithm modifies the sequence, it was changed to only call getArray() once. For that, css::uno::toNonConstRange was introduced, which returns a struct (sublclass of std::pair) with two iterators [begin, end], that are calculated using one call to begin() and one call to getLength(). To handle #4, css::uno::Sequence::swap was introduced, that swaps the internal pointer to uno_Sequence. So when a local Sequence variable should be assigned to another variable, and the latter will be modified further, it's now possible to use swap instead, so the two sequences are kept independent. The modified places were found by temporarily removing non-const end(). Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-12loplugin:moveparam in sdextNoel Grandin
Change-Id: I46e0f73f67cffb11ab5f1cf2453450a3066eb1fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123425 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11Fix font weight comparisonsStephan Bergmann
...after 2d486bac81e06c64d13c647f35d3f4affbeb183e "tdf#143959 sdext.pdfimport: call vcl::Font::identifyFont directly" changed the left-hand sides from aFontDescriptor.Weight of type float to aFontReadResult.GetWeight() of type FontWeight from include/tools/fontenum.hxx. (Diagnosed as > sdext/source/pdfimport/wrapper/wrapper.cxx:624:45: error: comparison of enumeration type 'FontWeight' with floating-point type 'float' is deprecated [-Werror,-Wdeprecated-enum-float-conversion] > if (aFontReadResult.GetWeight() == com::sun::star::awt::FontWeight::THIN) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ in a --with-latest-c++ build.) Change-Id: I0c661fc27eefa478808f796ffb9a7586e1e671c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123375 Reviewed-by: Kevin Suo <suokunlong@126.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2021-10-11tdf#143959 sdext.pdfimport: call vcl::Font::identifyFont directlyKevin Suo
Previously the unittest testTdf143959_nameFromFontFile did not fail even if the fixing code in wrapper.cxx is removed. That was because the "if (xHolder.is())" condition is always false in the unittest run, which suggests that the calling of com.sun.star.awt.FontIdentificator through the uno did not work in some circumstances. See comments in: https://gerrit.libreoffice.org/c/core/+/120815 In this patch, we call the vcl::Font::identifyFont directly rather than through the uno calling. This is proven to work in both the manual and unittest running. Change-Id: I6334bca2defaa27cf6ac72af3d621fbb59e57980 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123358 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-11sdext.pdfimport tdf#78427: Add support for more Font Weight featuresKevin Suo
...e.g. Thin, Extra-Light, Light, Semi-Bold, Bold, Extra-Bold and Black. Previously the xpdfimport code passes the isBold value which is bool value. sdext.pdfimport accepted this value from the xpdfimport output and check whether a font is bold or not. However, there are many other FontWeight features more than a "bold". This patch changes the isBold to the GfxFont::Weight type, and changed the sdext.pdfimport isBold bool type (in FontAttributes) to an OUString fontWeight. The value for the fontWeight is set according to the GfxFont::Weight passed by xpdfimport, and then this fontWeight is passed to the ODF xml generation stage and used there directly. Now the Semibold and Light (as shown in the unittest file) can be currectly handled. However, for other weights the parseFontFamilyName still need to be updated, but before doing that I plan to refector this function as the current logic is very difficult for maintennance. Change-Id: If2ce5f0f41c83843d8a6aeb30134b3faf99ba877 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123339 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-09-15loplugin:constvarsNoel Grandin
Change-Id: I9b35d6333afa6b305bf73fc55a7e60c8365674e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122134 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-09-12allow build with poppler <= 0.71Rico Tzschichholz
Change-Id: I359c8259ae402f9f22be392c4ab4a23d31a17b4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121937 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-09-02clang-tidy:readability-redundant-member-initNoel Grandin
Change-Id: I0a9b238c0ba551b330bee7b89eb6cd48fad1b265 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121488 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-23loplugin:referencecasting look through more clang TypesNoel Grandin
Note that because of where the fix resides, loplugin:redundantcast also notices a few more things. Change-Id: I0b66047fadfff2c5ceafcbd3eab085de00d861a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120865 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-22tdf#143959 sdext.pdfimport: fix font name with subtagKevin Suo
as returned by the font descriptor when reading the font file. Change-Id: I376b887e6356e765f669b41c43776f78f94c3623 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120815 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-20allow build with poppler <= 0.82Caolán McNamara
Change-Id: Ia062a788fec9c67c18382c2ff5f4b4df35bd17d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120771 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-18loplugin:constparamsNoel Grandin
Change-Id: Ic7410f836e584df45101e78e345c8b3c8d355e09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120680 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-10tdf#143148 Use pragma once in sdextYildiray
Change-Id: I0ba29599509b875494f4021948192d2d447b9e6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120277 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2021-08-05Avoid ODR violation, consistently define ZLIB_CONSTStephan Bergmann
At least my --enable-lto --enable-mergelibs build diagnosed > [build LNK] Library/libmergedlo.so > workdir/UnpackedTarball/zlib/zlib.h:86:16: warning: type ‘struct z_stream_s’ violates the C++ One Definition Rule [-Wodr] > 86 | typedef struct z_stream_s { > | ^ > workdir/UnpackedTarball/zlib/zlib.h:86: note: a different type is defined in another translation unit > 86 | typedef struct z_stream_s { > | > workdir/UnpackedTarball/zlib/zlib.h:87:20: note: the first difference of corresponding definitions is field ‘next_in’ > 87 | z_const Bytef *next_in; /* next input byte */ > | ^ > workdir/UnpackedTarball/zlib/zlib.h:87: note: a field of same name but different type is defined in another translation unit > 87 | z_const Bytef *next_in; /* next input byte */ > | (And ZLIB_CONST then required a small adaption in tools/source/zcodec/zcodec.cxx, plus some loplugin:redundantcast. And gb_PrecompiledHeader_ignore_flags_system had to be updated to avoid errors like > Error reusing pch/inc/pch/precompiled_system by Library_wpftdraw. > precompiled header flags : -DBOOST_ALL_NO_LIB -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_MEM_FN_ENABLE_CDECL -DBOOST_OPTIONAL_USE_OLD_DEFINITION_OF_NONE -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=msci -DDBG_UTIL -DEXCEPTIONS_ON -DINTEL -DNOMINMAX -DOSL_DEBUG_LEVEL=1 -DPCH_LEVEL=4 -DSAL_LOG_INFO -DSAL_LOG_WARN -DWIN32 -DWNT -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -D_CRT_SECURE_NO_DEPRECATE -D_DEBUG -D_DLL -D_HAS_AUTO_PTR_ETC -D_MT -D_REENTRANT -D_SCL_SECURE_NO_WARNINGS -D_SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING -D_SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING -D_SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING -D_WIN32_WINNT=0x0601 -D_X86_=1 -EHs -GR -GS -Gd -Gs -Gy -MDd -Od -W4 -Wv:18 -Zc:__cplusplus -Zm500 -bigobj -nologo -permissive- -std:c++17 -utf-8 -wd4127 -wd4201 -wd4244 -wd4250 -wd4251 -wd4267 -wd4275 -wd4505 -wd4611 -wd4706 > object flags : -DBOOST_ALL_NO_LIB -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_MEM_FN_ENABLE_CDECL -DBOOST_OPTIONAL_USE_OLD_DEFINITION_OF_NONE -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=msci -DDBG_UTIL -DEXCEPTIONS_ON -DINTEL -DNOMINMAX -DOSL_DEBUG_LEVEL=1 -DPCH_LEVEL=4 -DSAL_LOG_INFO -DSAL_LOG_WARN -DWIN32 -DWNT -DZLIB_CONST -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -D_CRT_SECURE_NO_DEPRECATE -D_DEBUG -D_DLL -D_HAS_AUTO_PTR_ETC -D_MT -D_REENTRANT -D_SCL_SECURE_NO_WARNINGS -D_SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING -D_SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING -D_SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING -D_WIN32_WINNT=0x0601 -D_X86_=1 -EHs -GR -GS -Gd -Gs -Gy -MDd -Od -W4 -Wv:18 -Zc:__cplusplus -Zm500 -bigobj -nologo -permissive- -std:c++17 -utf-8 -wd4127 -wd4201 -wd4244 -wd4250 -wd4251 -wd4267 -wd4275 -wd4505 -wd4611 -wd4706 > reason : -DZLIB_CONST -DZLIB_CONST > Incorrect precompiled header setup or internal gbuild error. > make[1]: *** [C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/writerperfect/Library_wpftdraw.mk:31: C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/workdir/PrecompiledHeader/nodebug/Timestamps/Library_wpftdraw_reuse] Error 1 with --enable-pch.) Change-Id: Iadd3c90a65993ebef98190458762b1c86d425c4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119961 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-03Consolidate on C++17 std::scoped_lock instead of std::lock_guardNoel Grandin
as in commit 9376f65a26240441bf9dd6ae1f69886dc9fa60fa Change-Id: I3ad9afd4d113582a214a4a4bc7eea55e38cd6ff9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119927 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-27GooString::append(const std::string&) is new in poppler 0.83.0Luboš Luňák
Change-Id: Ib3324c393c195526160eddbdfc83a688e6f66dbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119534 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-07-26Fix typosAndrea Gelmini
Change-Id: If0c2b0df62d2f307ceaef0ea961a0ff221ba5e65 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119520 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-26sdext.pdfimport: Restore to read font file for the determination...Kevin Suo
of font attributes, as suggested by Mike Kaganski in https://gerrit.libreoffice.org/c/core/+/118977. This partially reverts da59686672fd2bc98f8cb28d5f04dc978b50ac13 but did some modification of the previous code with some explanationary comments. Change-Id: I224d9e717bf374a90f4834cbd9e11bf1138b41ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119090 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-18poppler 0.73 doesn't have GooString::append(const std::string&)Caolán McNamara
don't know what version is appeared in Change-Id: Ia1fff05aa58990e631d63a2e694be47a4b74e24c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119126 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-16Fix typosAndrea Gelmini
Change-Id: Iae3eec214849676be51ded133c1ffd9cf2e56ef0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119074 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-16restore compatibility with older popplersKevin Suo
with poppler 20.09: /home/rene/LibreOffice/git/libreoffice-7-2/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx: In member function 'int pdfi::PDFOutDev::parseFont(long long int, GfxFont*, GfxState*) const': /home/rene/LibreOffice/git/libreoffice-7-2/sdext/source/pdfimport/xpdfwrapper/pdfioutdev_gpl.cxx:438:39: error: 'class GfxFont' has no member named 'getNameWithoutSubsetTag' https://www.google.com/search?q=getNameWithoutSubsetTag&oq=getNameWithoutSubsetTag&aqs=chrome..69i57.784j0j7&sourceid=chrome&ie=UTF-8 suggests it was added in 20.12 Change-Id: I4eacd2d740cb689ff9b3c6cab59376e01b1ba162 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118977 Tested-by: René Engelhard <rene@debian.org> Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-14tdf#78427 tdf#81481 sdext.pdfimport: added unittestKevin Suo
Change-Id: Ia112762f0ece1be589997f6b9be336424603a1c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118947 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-14sdext.pdfimport: <text:s> and <text:tab> don't have "text:style-name" attributeKevin Suo
Per OpenDocument specs: * The <text:s> element only has a "text:c" attribute. * The <text:tab> element only has a text:tab-ref attribute. seen in the SAL_WARN message: warn:xmloff:221658:221658:xmloff/source/text/txtparai.cxx:137: unknown attribute urn:oasis:names:tc:opendocument:xmlns:text:1.0 text:style-name value=text13 ... Change-Id: I02a29ac2c9f9db026caec19238cd97111ce587c9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118946 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-14tdf#78427 sdext.pdfimport: more bold/italic/Oblique fixesKevin Suo
e.g. the PDF in tdf#107812. Also added notes to the fontAttributesSuffixes list. Change-Id: I4a4dcba2d9369c6b09168a18784d2f6e7d08793d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118832 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-14tdf81484 Draw and Writer pdf import: SimSun bold font is shown as "outline"Kevin Suo
Case 1: As discussed in the bug report, SimSun does not have a "bold" font. In PDF it uses fill+stroke rendering mode (i.e., Text Render Mode is 2), see CoreTextStyle::CoreTextStyle, as a faux bold (fake bold) feature. For faux bold, the text render fill color is the same as the stroke color. Case 2: Also, it is noted that if you apply real "outline" characters in Writer and export to PDF, on Draw PDF import the text render mode is also 2, but the text render fill color is different than the stroke color. However, I would argue that for this case on PDF export Writer should set the render mode as 1, not 2, per PDF specs, which is another issue to be improved. The old code treated all these two cases as "outline". This patch: 1) treats render mode 2 as faux bold if the stroke color is the same as the fill color; and 2) still treat it as outline if the fill color and stroke color are different. This way, the real outline remains as outline characters while the faux bold (fake bold) becomes bold again on pdf import. This patch Also fixed some incorrect use of <style:text-properties> attributes per OpenDocument specification. This patch depends on change-ID I50a510ab9e5483f859ea2a767ea977ea3f065a2e which guesses the bold/italic if the font indentifaction had failed for whatever reason. Change-Id: Idabb22ea9b01ba53733c3acbd9de843790ebe8ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118156 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-12tdf#78427 sdext.pdfimport: refactor the conversion of font family namesKevin Suo
Simplify the code and hopefully improves performance. The previous code used a long for loop within which it used many duplicated parseFontRemoveSuffix. That for loop was simply intended to remove the font family name suffixes. However, the rResult.familyName is a OUString and this type already has the function of removing suffixes which is more efficient. Also, defined a list of suffixes to be removed in the header file. New suffixes can be easily added to this list. Change-Id: Idfa11cfe60e2e34a1f7456d29562a89eb3de7662 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118734 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-12tdf#78427 sdext.pdfimport: No need to read a font file for the purpose of...Kevin Suo
...determining the bold/italic/underline etc. The purpose for reading a font file is that in case the font attributes determined by the xpdfimport process is not enough, then we use the lo core font classes which read in the font file and then determine whether it is bold, italic etc. However, while this works in some cases, it does not work in many cases when the font file was actually a subset and a toUnicode map is followed in the PDF, see tdf#78427. In addition, in case the information collected from the xpdfimport process is enough, there is no need to read the font file. This commit removes the read of font file part. Also, this commit uses gfxFont->getNameWithoutSubsetTag() to get the font name with the subset tags removed, thus simplified the code in wrapper.cxx while also improves performace as the remove of subset tags is only run when the font is a subset (the previous code did this for all the font names). Change-Id: I94c1ad8e743abfab81cf0a46da178d4d8b212427 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118733 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
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-23tdf#141709: Use poppler_dataMichael Warner
Bundle the files from poppler_data and provide the path to them to poppler when the bundled poppler library is used. Change-Id: I13a2ef861303a0be17aa0a861ef8ac96ed8a93be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117523 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-06-11Simplify vector initializationsJulien Nabet
Change-Id: Icf8972be204799e9b3b3824ab18d8584911fe1c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117061 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-06-09Simplify Sequences initializations (sdext)Julien Nabet
Change-Id: Ide9a3ddd4f6915f45b02353293236988bff51eba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116935 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-05-31sdext : use std::mutex when possibleArnaud Versini
Change-Id: Ia610c0c46e017452db71945f6f53fedbcb6d1198 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116415 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-21LineParser::readNextToken gets called with m_nCharIndex==npos after allStephan Bergmann
eca89ece45ede76605a6102c94b3b67e1f8ff5aa "Replace rtl_string_getTokenView with o3tl::getToken" had erroneously assumed (from a succeeding `make check`) that the only problematic call to o3tl::getToken with position==npos would be the one in LineParser::readPath (and which had been addressed in that commit). But e.g. loading ooo29794-4.pdf from the crash test corpus would also run into that situation via LineParser::readNextToken, > warn:legacy.osl:3090875:3090875:sdext/source/pdfimport/wrapper/wrapper.cxx:259: insufficient input > soffice.bin: include/o3tl/string_view.hxx:34: std::string_view o3tl::getToken(std::string_view, char, std::size_t &): Assertion `position <= sv.size()' failed. > #3 0x00007ffff7a67a16 in __GI___assert_fail (assertion=0x7fffb39ea58c "position <= sv.size()", file=0x7fffb39f2a7f "include/o3tl/string_view.hxx", line=34, function=0x7fffb39ef3a9 "std::string_view o3tl::getToken(std::string_view, char, std::size_t &)") > #4 0x00007fffb3b60131 in o3tl::getToken(std::basic_string_view<char, std::char_traits<char> >, char, unsigned long&) (sv="eoClipPath", delimiter=32 ' ', position=@0x7fffffff29e0: 18446744073709551615) at include/o3tl/string_view.hxx:34 > #5 0x00007fffb3b5aa9f in pdfi::(anonymous namespace)::LineParser::readNextToken() (this=0x7fffffff29d0) at sdext/source/pdfimport/wrapper/wrapper.cxx:260 > #6 0x00007fffb3b5b2fa in pdfi::(anonymous namespace)::LineParser::readPath() (this=0x7fffffff29d0) at sdext/source/pdfimport/wrapper/wrapper.cxx:323 > #7 0x00007fffb3b59eb3 in pdfi::(anonymous namespace)::Parser::parseLine(rtl::OString const&) (this=0x7fffffff2d28, rLine="eoClipPath") at sdext/source/pdfimport/wrapper/wrapper.cxx:859 [...] so better guard there. Change-Id: Ibfd53fd9d3be0a3548d60cb26d59bb5966c5bc2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115916 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-08-08 12:05:42 +0000