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>
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
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>
eca89ece45 "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>
(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>
I was wrong, the Concat framework already optimised appending
numbers by stack-allocating small buffers, so include
them in the plugin
Change-Id: I922edbdde273c89abfe21d51c5d25dc01c97db25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115037
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In order to prevent that the event listener
holds the object reference count when removed,
ensure they are removed when disposing the object.
Change-Id: I7cb4cb7d87acfc9610c2498760ade531456fe22e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113493
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
In order to prevent that the frame action listener
holds the object reference count when removed,
ensure they are removed when disposing the object.
Change-Id: If83574e31230d9c683adaf36af36485650fd2c50
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113389
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
...by re-enabling the code temporarily #if'ed-out in
a528392e71 "Fixed/improved
loplugin:cppunitassertequals" (and which then triggers lots of other
lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings).
For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it
was more straightforward to rewrite them with an explicit call to operator ==
(which silences loplugin:cppunitassertequal) than to adapt them to
CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types.
In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been
implemented trivially for now, but might want to combine that with the
DEBUG_PIVOT_TABLE-only ScDPItemData::Dump.
Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit 3ed9bba283. osl_Pos_Absolut
(include/osl/file.h) is part of the stable URE interface; it must not be changed.
Change-Id: I1f49923a9351e4be5aee39b10720d38b424feb9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110435
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Kevin Suo