it allows to simplify the code a bit since the
TestFilter is passed as the first parameter.
In preparation for a follow-up commit
Change-Id: I316c88e1583dc7d9b04876883b971bdfa54e8967
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198588
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The config changes that didn't restore initial values could potentially
affect other tests in the same test suite, so that could create test
order dependency.
Change-Id: I53cc2fe4e545852d0bcec865da31f2e2a7896d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198505
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit b71d9a6d15 (do not apply line dashing
in drawinglayer (tdf#136957), 2021-04-29) made sure that metafiles pass
dashing information in LineInfo of MetaPolyLineAction, instead of altering
the polyline itself. Since SVG export ignored dashing information in
MetaPolyLineAction, the exported lines were solid since that patch.
This patch introduces respective export support, emitting stroke-dasharray
attribute. As far as I see, it has exactly the same semantics, and renders
correctly in chrome and firefox. It also imports OK into Draw.
Ref: https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/stroke-dasharray
Change-Id: Ifb634a4f3608ee5c2c76727ef4416b80f8f90709
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197618
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Found after running bin/find-unneeded-includes --headersfwd include/vcl/[d-g]*
This shaves off about 150M input
Change-Id: I2b15257451d4b392dca3e5d07f4a443ee653b04c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196395
Tested-by: Jenkins
Reviewed-by: Gabor Kelemen <gabor.kelemen@collabora.com>
utl::MediaDescriptor was just a SequenceAsHashMap with a few added
methods. It made it more difficult to assign a SequenceAsHashMap to
MediaDescriptor, without real upsides. In many places, the class was
used not as media descriptor, but just as helper to create sequences.
This change puts the string constants and the former methods into a
namespace utl::MediaDescriptor.
It would be also good to drop comphelper::NamedValueCollection, which
is basically a twin of comphelper::SequenceAsHashMap (TODO).
Change-Id: Ia9b69c5a2ad153ecc654944c419c1880252ed86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195163
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
After commit 3a633abe5c6a884d152c73737debe215a980c79d "lok: pdf export
comments in margin", on online comments from pages 2 and above were
printed as if the space was much smaller, with one or two characters per
line. This patch fixes that.
It also changes the pdf export test to not have to use things internal
to the sw module.
There is no accompanying test to this change because due to differences
between how the test suits runs LOK and how online does it, the issue
can't be reproduced in a cpp unit test.
Change-Id: Ie603c74dc5fa4bc320102e7144535735e47f89a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191641
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 9ff8618f0f224d42af8d35bbafbe3850ed4a2093)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192737
Reviewed-by: Jaume Pujantell <jaume.pujantell@collabora.com>
Tested-by: Jenkins
Enable print comments in margin for PDF in LOK without tiled comments.
Right now comments are only printed if they are being shown in the LO
document which excludes LOK without tiled comments. Also the post-it
manager and annotation window assume in some places that MapMode is used
and correctly set, which is not the case in LOK.
Adapted an existing test about printing comments in margin to test also
for LOK.
Change-Id: I362cb89ade6d4f53832fd9a722196d214360aae6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189511
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 3a633abe5c6a884d152c73737debe215a980c79d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/192728
Tested-by: Jenkins
Reviewed-by: Jaume Pujantell <jaume.pujantell@collabora.com>
DXArray gives much more reliable data compared to font width, which
is known to require complex corrections (see tdf#127471 and commit
3d33e4ce39).
This fix uses tspan's `lengthAdjust` and `textLength` attributes for
automatic justification, which are already documented as early as in
SVG 1.0 ( https://www.w3.org/TR/SVG10/text.html#TSpanElement ). This
works in LibreOffice and in Chrome, but is not supported in Firefox
yet ( see https://bugzilla.mozilla.org/show_bug.cgi?id=890692 ).
I considered using these attributes on `text` element level, which
is supported in both browsers - but that breaks text elements with
multiple tspans. The `transform` attribute can't be used with tspan
both in Chrome and in Firefox, which creates the same problem, and
has an additional drawback that tspan offsets need tweaks.
Change-Id: I7d4bbb7542a9d60e53bdf6f6cac7fae0729e6e48
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186033
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Previously, the direction attribute was not set on text tags when
exporting RTL text to SVG. This change adds the missing attribute.
Change-Id: I57770c1cc44f10c3c43ccac2f5a17c1422c34d35
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176869
Tested-by: Jenkins
Reviewed-by: Jonathan Clark <jonathan@libreoffice.org>
Interactive signing via the .uno:Signature command parameters were
possible, but headless PDF export had no similar parameters.
The primary difference is that the interactive signing works with the
sign certificate of the SfxViewShell, while PDF export has its own
vcl::PDFWriter::PDFWriterContext::SignCertificate.
Fix the problem similar to what commit
80723fccbb (filter: allow PDF export to
sign from the cmdline, 2022-02-03) did, but here we don't refer to an
already configured sign certificate by name, we take the sign cert/key
from parameters instead.
Test this in the NSS case where it's known to work, ignore the mscng
signing case for now.
Change-Id: Ib0c171736d2554fb3678ae4b8842541c43f9f3dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175644
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Since commit 872dba61a1 (INTEGRATION:
CWS xmlfilter01 (1.1.2.3.2.1.16); FILE MERGED, 2003-04-04),
XMLFilterDetect service uses Clipboardformat field in filterdetect.
Thus, it detects any file starting with "<?xml" and having string
"pwi" as "writer_PocketWord_File", because writer_PocketWord_File.xcu
has the text "doctype:pwi" as the value of its ClipboardFormat.
The problem is: since commit 1e6e891016
(restore PocketWord filter, this time backed by libwps, 2020-09-27),
this format is not handled by XMLFilterDetect service. So the filter
mis-detects some else filter's data, which then isn't accepted there.
This change makes the code of FilterDetect::detect to make sure that
it only processes its own data, checking DetectService property, too.
I didn't remove the ClipboardFormat property value from the mentioned
XCU, because (1) I don't know if it may be used by other code; and
(2) because it allows to have the sensible unit test.
Change-Id: I02fafe8df10f64640305d45cf1461b0a37552630
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174607
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
These are only sent to an external API expecting char*-like strings,
or for comparison. Having every assertXPath having three of _[ou]str
is too much syntactic noise, making the unit tests almost unreadable.
Change-Id: Ic004a36ea75e7bfe0b96f405c40f926a957b51cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174416
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
normal 'playback' case is ok, but during the peek-ahead to get text positions
then the MapMode was skipped over so the rotate values were created with
the wrong MapMode.
Change-Id: I2b51dbc1b15e8d0d24b00b2bd4decb4c71772208
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173260
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Open the bugdoc, try to export as SVG, results in an assertion failure
in debug builds, the produced XML would not be well-formed.
Commit 666f252457 (SVG export: fix lost
semi-transparent text on shapes, 2020-07-17) added support for text
opacity on shapes, but this assumes that the entire shape has the same
opacity, while this shape has 3 paragraphs and only the middle one has
an opacity set, at a text span level. Additionally, it's a bullet, so
the text (for the bullet, has no transparency set) starts before the
transparency metafile action would start. This means that the existing
logic won't realize that opacity should be exported using the
fill-opacity attribute instead of a <g> element.
Fix the problem by checking for the isTextShapeStarted() case in
SVGActionWriter::ImplWriteMask(): if we're already inside text, then we
always want to map a transparency mask to the fill-opacity attribute
instead of a <g> element.
Leave the shape-level code at SVGTextWriter::setTextPosition()
unchanged, that continues to deal with per-shape text opacity.
Change-Id: I8cb0ca2e839fba911a75e1925cf79145f69af151
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172856
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
As part of the efforts in #145538 to replace the SAL_N_ELEMENTS()
macro with std::size() and std::ssize(), this commit performs the
necessary changes for a few files in the filter/ module.
PS-2: Replace an std::size call with sizeof, and one with std::ssize
Change-Id: Icac6470cdff762f828651153d0abc5f40b8e5d7c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165592
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Since commit c16969b9bc
(tdf#84553 Detect and warn of Windows Antivirus., 2020-02-08),
it is checked that antivirus is disabled in $SRC_ROOT and $BUILDDIR.
This reverts commit a6b2c618cb
(disable cve tests by default on windows, 2014-10-01).
Change-Id: I3816e97cfb4559f7647167ed291b75468b03dc4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164612
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
The new tests fail with:
> core/xmlsecurity/qa/unit/signing/signing2.cxx:
> 252: Assertion
> Test name: testPasswordPreserveMacroSignatureODFWholesomeLO242::TestBody
> equality assertion failed
> - Expected: 1
> - Actual : 4
This is because only the first test that runs sees the testing CA
certificates that are copied in MacrosTest::setUpNssGpg(); when the
second test runs, they have somehow vanished.
This is because apparently SQLite on MacOSX, unlike on Linux, monitors
the file descriptors of its database files, and then invalidates itself
when setUpNssGpg() via osl::File::copy() renames and unlinks the
existing database files:
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/cert9.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 5 (0x11)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode renamed while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x20)
> cppunittester[29873:5483181] [logging] BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: core/workdir/CppunitTest/xmlsecurity_signing2.test.user/key4.db.osl-tmp
> cppunittester[29873:5483181] [logging] invalidated open fd: 6 (0x11)
Split MacrosTest::setUpNssGpg()/tearDownNssGpg() into functions
setUpX509() which only does something on the 1st invocation, and
setUpGpg()/tearDownGpg() which may be invoked per-test (they could also
be run once for the whole test suite, but not obvious how to do that);
PDF related tests don't need GPG.
Presumably this is (along with the WNT-specific problem fixed in commit
3e9a700091) the reason why most of the
tests not only accept the expected result of SignatureState::OK but also
SignatureState::NOTVALIDATED.
Change-Id: I59b85ca651cecaccfdea729ed1e645c53079c8bf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162693
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The old name was misleading (it doesn't take an URL, but a filename);
also, now it's easier to grep for it - doesn't get mixed with
vcl::graphic::loadFromURL.
Change-Id: Ib88d2194200a6a54d2326971e0306ba39f0c7025
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161578
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Commit 046e954595 (Try to revert to use
of file_iterator from boost on Windows, 2023-10-31) had introduced a
problem that pdfparse::PDFReader::read couldn't create file_iterator
for files already opened with write access: mmap_file_iterator ctor
on Windows used single FILE_SHARE_READ as dwSharedMode parameter for
CreateFileA WinAPI; and that failed, when the file was already opened
using GENERIC_WRITE in dwDesiredAccess - which happens when opening
stream in TypeDetection::impl_detectTypeFlatAndDeep.
Fix this by patching boosts' mmap_file_iterator constructor to use
FILE_SHARE_READ | FILE_SHARE_WRITE, like we do in osl_openFile.
But there was a pre-existing problem of using char-based CreateFileA
API, which disallows opening any files with names not representable
in current Windows codepage. Such hybrid PDF files would still fail
creation of the file_iterator, and open as PDF.
Fix that by further patching boost to have wstring-based constructors
for file_iterator and mmap_file_iterator on Windows, which would call
CreateFileW.
Change-Id: Ib190bc090636159ade390b3dd120957d06d7b89b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160218
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
A bunch of range based loop changes in various qa
sections that also take out about 1% of SAL_N_ELEMENTS
Change-Id: I8ef000e9aa400cd8363b48f6175f6ab258cefbd9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152422
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This was somehow possible already when the document was printed with
comments in margin before - but it was not possible to set this option
when exporting a PDF via dialog or API.
To use this setting via API, set the "ExportNotesInMargin" property.
Change-Id: I97a80c5b3b3b2cde669496fd881a41ea0acc5c28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143234
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
The watermark direction is currently either 0 degrees for landscape
pages or 270 degrees for portrait pages.
The problem is many people expect 45 degrees rotation angle or some
custom angle in general, and we provide no way to control it.
Fix the problem by adding a new "WatermarkRotateAngle" PDF export filter
option to specify the rotation angle explicitly. Note that the watermark
text is still centered, and the text size is decreased to still fit the page
boundaries. To keep things simple, do this shrinking by going with a
size that matches the shorter dimension of the page, instead of some
more complex iterative approach.
Example cmdline usage:
soffice --convert-to pdf:writer_pdf_Export:'{"Watermark":{"type":"string","value":"draft"}, "WatermarkRotateAngle":{"type":"long","value":"450"}}' test.odt
Change-Id: I1fee14c333e68c92cf4c65ec100e04dcf024f907
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143229
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The font name of the watermark text is currently hardwired to Helvetica,
a sans-serif font.
The problem is that this looks bad in case your document uses serif or
monospace fonts. Or perhaps your document uses a single font and you
want to make sure that the watermark uses exactly the same font.
Fix the problem by adding a new "WatermarkFontName" PDF export filter
option to specify the font name explicitly.
Example cmdline usage:
soffice --convert-to pdf:writer_pdf_Export:'{"Watermark":{"type":"string","value":"draft"}, "WatermarkFontName":{"type":"string","value":"Times"}}' test.odt
Change-Id: I2f065e1517236695b0a95369bdcd803125018587
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143143
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The font height of the watermark text is currently automatic: we start
with a value based on the page size and then decrease it till the text
fits.
The problem is that sometimes you want a smaller value, but specifying
this was not possible.
Fix the problem by adding a new "WatermarkFontHeight" PDF export filter
option to specify the font size explicitly.
Example cmdline usage:
soffice --convert-to pdf:writer_pdf_Export:'{"Watermark":{"type":"string","value":"draft"}, "WatermarkFontHeight":{"type":"long","value":"100"}}' test.odt
Change-Id: Iceab943b7a995badfcdc6b12ecc9264e39e4a3a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143135
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Xisco Fauli