Clip stroke paths coming from the PDF import.
Similar to my previous patches for fills.
(It's possible we might have to do something clever with cropping
of arrows/etc but not sure yet)
Change-Id: I9e46deac4a722e3ac510f0cc4bdb6b38b67c579e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176952
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
'clipToStrokePath' is a variant of 'clip' it sets up a clip
to a path that's been stroked with whatever width the current
pen is. Now that we have all the rest of the code in, we can
start using it.
This fixes the white blobs on page 3 of tdf#148526 which
are clipped radial fills. It has a separate problem with
text corruption which this doesn't fix.
It also fixes the geometry of the top left square in:
https://gitlab.freedesktop.org/poppler/poppler/-/issues/178
(although it still has colour problems with that test case)
Change-Id: Ibe2c56927b45d44e90cfa2934fc905034a50e9c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172927
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
Set the line join type from our GC.
Change-Id: I8f64ae032930e46028cd49efefb05af06d4866d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172926
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Pdfimport is one of the few none render pieces of code to use
css::rendering::PathJoinType, switch to using basegfx::B2DLineJoin
instead.
Use that type consistently instead of throwing in sal_Int8's with it.
Change-Id: Ie1384a06558925c796ce6c83b458b4c150bcecc7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172925
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Poppler's 'ClipToStroke' call wants to clip to a paths rendered
shape, i.e. with line thickness and possibly other attributes.
Use get2DDecomposition to do that.
Change-Id: I3ca54621dcb859520504e5c7d6cd41106f5c34d1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172924
Reviewed-by: David Gilbert <freedesktop@treblig.org>
Tested-by: Jenkins
Parse the soon to be created clipToStrokePath command and route
it through the tree code.
Change-Id: I8fa17457ffd062e91983b6ed80bd64259aa7114e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172923
Tested-by: Jenkins
Reviewed-by: David Gilbert <freedesktop@treblig.org>
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
regression from
commit 8ac5f40b33
Author: Dr. David Alan Gilbert <dave@treblig.org>
tdf#113050 sdext.pdfimport: Write the tiling pattern image
The logo in the test file in tdf#159115 appears to be a tiling pattern
fill where the fill is actually rendered text (instead of just an image)
and this triggers splash to try and look at it's font code (even though
I've already got EnableFreeType off) and that was initialised by
startDoc which I'd failed to call. Call it.
Note this doesn't fix tdf#159115, which originally had 4 copies of the
logo, the current state is it has one unrendered white blob, but lets
get rid of the crash first.
Change-Id: I4e3f29cedcb8aefbb5adf96f696bf08457fbd58a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173139
Tested-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
The pdf processor carefully records clip paths, but does very little
with them. It's currently just used in the recently added
tiling pattern fill.
Make the existing solid fills use the clip path.
This resolves 101611, 108813, and helps some
side issues in tdf#155170 In particular, the fish bowl on p.15
now looks about correct, but the fishes are still very, erm, square.
(I think there may be a longer term task to rework the clipping
completely)
Change-Id: Ie48901dbc6070465bac4fdb47b0bbc65a35c5792
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172448
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
also split up the gperf commands when generating sw/generated/tokens.cxx
wsl has trouble appending using shell redirects, so use separate targets
and use cat in the final processing step for tokens.cxx
see also https://github.com/microsoft/WSL/issues/4400
Change-Id: Id7a24d060e9be71113ec2827a389d347456f6522
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166338
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
convert some functions which merely create an OUString on the fly
from a char literal to 'constexpr OUString' literals
Change-Id: I617490baf2d976291b324cc991b59cd18f4b242c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166392
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
The problem was, that upon any error in opening a PDF, out Poppler
wrapper used another bundled document, with a single page with a static
text "This PDF file is encrypted and can't be opened.". That happened
regardless of the nature of the problem (it could be an IO problem, as
in tdf#160260, or other things from Poppler's poppler/ErrorCodes.h).
For automated import (command line or API), it meant that it was not
possible to detect the failure.
This replaces this strange mechanism with a normal error reporting. For
now, a simple "general input/output error" will be reported; but it is
possible to use interaction handler to show details (see comment in
xpdf_ImportFromFile).
Change-Id: I30493118fc5dd0b1c62cae7718acfe95bb4b13b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165771
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
as per Noel's suggestion - this also ends up fixing some leaks as well.
Change-Id: Ia6099afc1955c341256ec0de5a0f839c005d9b76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164446
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Set the tile width/height from the step size and write it into the
draw:fill-image-width/height properties.
Change-Id: I70d69a6d5e77929bd14282731dd68d3bcafa9c1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163574
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
We need to scale the tiled image that fills our polygon, so add
width and height fields, we'll fill in and process them in subsequent
patches.
Change-Id: Ib0000066170ccbc0f4a4c971e1d6df72c3f7df14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163573
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
In a poly which is being image filled, we need to create a style
with the actual image definition in the 'Contents'
and then set the (automatically created) name of this in
the prop on the main style.
Also we need to set draw:fill to "bitmap" rather than "solid"
Change-Id: I253704519011e98fd106331ccfb139ad93ef6dee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163572
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I need the finalisers to be able to read an image, they have
a ref to the processor but not the emitter; so allow the container
to be read via the processor reference.
Change-Id: Ifd3b2af1d456561ad42ae3e7c664f03b2e0c971c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163571
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Use -1 to mean the existing solid fill, otherwise it's the ID
of the image to use as the fill.
Change-Id: I596c26145f5285f75af631a3bb7ddf09600982a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163570
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For fill-images we need the image as a string.
Change-Id: I4a8429563b0e19ad977b4e933a0ffee378dab244
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163569
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
For draw:fill-image we need output like:
<draw:fill-image draw:name="foo">
<office:binary-data>Base64stuff
</office:binary-data>
</draw:fill-image
Style's 'Contents' entry, almost does that and is currently
unused; but it doesn't put the tags in. Adding the tags
manually in the Contents string doesn't work (because it bypasses
something in the Emitter?).
Since it's not currently used, add the office:binary-data
tags for our use.
Change-Id: Idaf11b49bd075bb82116a0578bb4c38790dd0fb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Like stroke-dash, draw:fill-image needs the name setting in
the draw:name attribute.
Change-Id: Ib9c888765af8bfb0849f0f1ef15f9774808a1661
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163567
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
