Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
Change-Id: I10ff73f89c965beb3cfb5fc3a40dd959d8f77aaa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124600
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I1992d1ffbbc80efe9749ebd254971a0a92a10019
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124386
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
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>
|
|
...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>
|
|
Change-Id: If3cebeadff5496ae214614b49116060d24b6082f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123696
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
... 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>
|
|
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>
|
|
Change-Id: I46e0f73f67cffb11ab5f1cf2453450a3066eb1fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123425
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...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
|
|
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>
|
|
...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>
|
|
...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>
|
|
Change-Id: I9b35d6333afa6b305bf73fc55a7e60c8365674e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122134
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I359c8259ae402f9f22be392c4ab4a23d31a17b4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121937
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0a9b238c0ba551b330bee7b89eb6cd48fad1b265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121488
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
Change-Id: Ia062a788fec9c67c18382c2ff5f4b4df35bd17d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120771
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic7410f836e584df45101e78e345c8b3c8d355e09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120680
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Ib3324c393c195526160eddbdfc83a688e6f66dbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119534
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Change-Id: Iae3eec214849676be51ded133c1ffd9cf2e56ef0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119074
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: Ia112762f0ece1be589997f6b9be336424603a1c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118947
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
...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
|
|
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: Icf8972be204799e9b3b3824ab18d8584911fe1c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117061
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ide9a3ddd4f6915f45b02353293236988bff51eba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116935
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ia610c0c46e017452db71945f6f53fedbcb6d1198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116415
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
...to not needlessly extend the sal ABI.
At least for now, o3tl::getToken has a simpler interface than its
OString::getToken counterpart (driven mainly by how it is used for now): it does
not support a `token` argument, and its `position` argument must not be npos.
To meet the latter requirement, the check for "subpath" in LineParser::readPath
has been reworked slightly.
Change-Id: I4428fe2d9aa03ca83a436fc6493fbc34665a8033
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115742
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7d4039e87fda447b1d2087b2430a3544e9a1eb14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115732
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
update
commit 3669d4ec43a6aa2d410d8351d631548db45a5302
Date: Fri May 14 15:51:38 2021 +0200
add OString::getTokenView (tdf#42374 related)
with suggested changes from gerrit review
Change-Id: I861d960deaa010740a4aa964e402c4c76a85cbc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115706
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(together with the member functions that operate on that state). That reveals
that Parser::m_nNextToken was always 0 when used, so can be removed.
Change-Id: Iaf27d0503efcc8c7628f2f5f99f6e380c91a3893
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115725
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
small improvement to PDF import
no need to construct temporary string objects when we are just to
going to convert them into int/double.
So use a view and convert the data through the view.
Change-Id: I824fe88bf17142b48fe6032e10c0f3a111927e96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115616
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
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>
|
|
Change-Id: I53e081fd6c52fc040b29fad18dc3a758310f943a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114259
Tested-by: Jenkins
Reviewed-by: Arnaud Versini <arnaud.versini@libreoffice.org>
|