Age | Commit message (Collapse) | Author |
|
Change-Id: Ie35ae8c10eaa66b48c9c79a0356a71ad82ca66e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94720
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I624be5423e1536aab351be21a4254d61c122a783
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87045
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie181eeb984d8531b437c267b410eeb3c552f844f
|
|
Change-Id: I250bc68da118a994a2e0ff8ab9eb11112827756d
Reviewed-on: https://gerrit.libreoffice.org/80158
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
VirtualDevice and children are virtual, others not.
Change-Id: I9ef7f4d13b26e554b000b2b51216fbdbc6892b08
Signed-off-by: Adrien Ollier <adr.ollier@hotmail.fr>
Reviewed-on: https://gerrit.libreoffice.org/71875
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icf1a952fbe190fd6c4efd89364136aa2b48050e3
Reviewed-on: https://gerrit.libreoffice.org/66767
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Originally I thought mpPDFWriter can be used to create PDF from
any OutputDevice, but it's actually just set for the internal
VirtualDevice of the PDF writer.
So this gets rid of all the special mpPDFWriter and GetPDFWriter()
handling and replaces it with checks for OUTDEV_PDF. But since
ImplPDFWriter used to be a OUTDEV_VIRDEV, this also introduces
OutputDevice::IsVirtual(), which now replaces most of the direct
OUTDEV_VIRDEV checks.
Change-Id: I11824143b6b8833ecc81119762448cbdf1145dbc
Reviewed-on: https://gerrit.libreoffice.org/62257
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I619c19837c3bb6124009787ba0fc53991b4c4d0b
Reviewed-on: https://gerrit.libreoffice.org/62256
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: Iff3ddfb4dd75088e39ea7675b085f1bbde2c2045
Reviewed-on: https://gerrit.libreoffice.org/56247
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5e0d46fa863a9a74063063cc3d22ea15d2544d8b
Reviewed-on: https://gerrit.libreoffice.org/56208
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7c70f9c590dd63cca1dce16ce184fc7e14922de2
Reviewed-on: https://gerrit.libreoffice.org/53353
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Mostly generated using
make check COMPILER_EXTERNAL_TOOL=1 CCACHE_PREFIX=clang-rename-wrapper RENAME_ARGS="-qualified-name=Rectangle -new-name=tools::Rectangle"
Except some modules have their own foo::tools namespace, so there have
to use ::tools::Rectangle. This commit just moves the class from the
global namespace, it does not update pre/postwin.h yet.
Change-Id: I42b2de3c6f769fcf28cfe086f98eb31e42a305f2
Reviewed-on: https://gerrit.libreoffice.org/35923
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I9ff378d9c7c9a221599c0a84df638b3acf8f069f
Reviewed-on: https://gerrit.libreoffice.org/30121
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
|
|
and fix the bForceZeroExtleadBug TODO
Change-Id: Iac9295c6ce31112d69a870e3a229823eb1e9a4f2
|
|
Change-Id: I36daccd90bfa6ba0ee8b9e76bff2bd8494155a04
Reviewed-on: https://gerrit.libreoffice.org/22710
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
The only things passed as buffers there were null pointers and
shared_arrays that had the deletion explicitly disabled with a struct
NoDelete, so it's sufficient to just pass a pointer.
Change-Id: I68d618782aa654242048516d2e910b8136b16e2d
|
|
Change-Id: I9d0ad886c4c6e1c8496eb6129b22d327ca0968eb
|
|
Change-Id: I068d404431d3565f6ad5741edbd3693225824a4d
|
|
Change-Id: I64566aa7dcd3c50e083180945d08039dd89364b3
|
|
Change-Id: I65e7e82e46c5751617b00a39df47d864b29b6ce1
Reviewed-on: https://gerrit.libreoffice.org/20441
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
cairo can therefore always render to a svp virtual device with
need for a fallback
Change-Id: I5d03ae541820389e26f7448444444be009fb28a4
|
|
are 1 or (rarely) 8 bit and lock that down.
Change-Id: I3d946ebef34ffb71c5adea7aa420af50e9584e05
|
|
that way we can use cairo to text render etc onto our basebmp-backed
headless/gtk3 virtual devices
Change-Id: I91002b610b72a4fe1d2094a57c5cb1b6b5d69cb1
Reviewed-on: https://gerrit.libreoffice.org/19957
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I05e89f9896170d4df3d1377549ea074f06b884a0
|
|
Change-Id: I2ea407acd763ef2d7dae2d3b8f32525523ac8274
|
|
Change-Id: I328ac7a95ccc87732efae48b567a0556865928f3
|
|
Change-Id: I65c31995c02a644aa436aecd065255fab38045e4
|
|
Change-Id: I12356b3fdce68282a30cae2b270b02e46558860a
Reviewed-on: https://gerrit.libreoffice.org/16847
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I98b88ca3369a2c888fd63796e39d42376d513002
|
|
Change-Id: If3ecbb0599b50d50ce6b3997ca7892200c332ffe
|
|
Also remove an over-optimistic assert & ref-holding in dispose piece.
Change-Id: I6ce6abb666c8143502fc450a26e1ba2aac787455
|
|
Change-Id: I9ea64443350ed2e1341b99270fa8b29189f07eb2
|
|
Looking into the code we handle more cases correctly so remove this
misleading comment.
Change-Id: Id738bb8af312dfce97560a43122a81a6708f64d3
|
|
otherwise vcl's clipping doesn't work quite right when the render text
with vcl apis fallback is used.
Manually forced in my case, but it should happen in practice with vertical
text, so if there is a bug about vertical text not appearing in slideshows then
this is part of the fix for that.
Windows and Mac remain unchanged as initialized with 1, 1. If the same problem
affects those platforms then they'll need to be adjusted to remember their
height/widths from the ctor and those values plugged in here instead
Change-Id: I2f82f0db0cf446d7db21f0a7ee4f8c15c7ebdb42
|
|
This reverts commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba.
Conflicts:
cui/source/tabpages/transfrm.cxx
svx/source/svdraw/svdedtv1.cxx
svx/source/svdraw/svdibrow.cxx
sw/source/filter/ww1/w1filter.cxx
tools/source/generic/rational.cxx
Change-Id: I4849916f5f277a4afef0e279b0135c76b36b9d15
|
|
This reverts commit 582ef22d3e8e30ffd58f092d37ffda30bd07bd9e.
Conflicts:
svx/source/svdraw/svdedtv1.cxx
svx/source/svdraw/svdibrow.cxx
sw/source/filter/ww1/w1filter.cxx
Change-Id: I80abc7abdeddc267eaabc9f8ab49611bb3f8ae83
|
|
Fraction used BigInt internally for computations, rational does nothing
like that.
Change-Id: I3e9b25074f979bc291208f7c6362c3c40eb77ff5
|
|
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Put the VCL Region class in the vcl namespace. Avoids clash with the X11
Region typedef.
Change-Id: I6e008111df7cf37121fbc3eaabd44a8306338291
|
|
We also want to be able to set whether or not the buffers
should be painted to top down, so add that parameter
as necessary (default seems to be false, however e.g. gtk
requires this to be true, i.e. needed for tiled rendering).
Change-Id: Id98882e4c7f62508ae5a976c0d8df743460a4ab2
|
|
We still need some way of managing the buffers properly rather
than just keeping a static reference to the last buffer
that was rendered.
Change-Id: I17940c758948aa9418f4e0216ecd253d128cd04f
|
|
Change-Id: Iff4198fdd51db787461b897f2d9d8b7640dbf772
|
|
Change-Id: I1aacc4a908798fda24de6b6f09b58dcf5d392e70
|
|
Turns out, we don't try to initialize a graphics context, much less
*acquire* one. e.g. Window instances can have many frames (subwindows),
of which one some are really being used at any time so we try to
"steal" one of the graphics contexts from the frame to use ourself,
later on that frame will steal it from someone else, etc.
Change-Id: I66d5dbb7015301bc2d2be51627061c91e1f2ee5d
|
|
In #i60945# it was discovered that Unix's leading external font spacing
causes problems with the display of documents. Therefore, the reference
device implemented a workaround, which was to set the spacing to zero.
However, the reference device is a VirtualDevice, so it should really be
handled there, not in OutputDevice. I have added a new protected function
to OutputDevice, GetFontExtLead() that handles this.
Change-Id: I1b84ee7d9f7ae96841b441b52705e67c8115ae5c
|
|
A new protected abstract function has been introduced only for
complex gradients. As it stands, we currently need to work out if
we should use a PolyPolygon or a Polygon because, as the comments
say:
// Determine if we output via Polygon or PolyPolygon
// For all rasteroperations other then Overpaint always use
// PolyPolygon, as we will get wrong results if we output multiple
// times on top of each other.
// Also for printers always use PolyPolygon, as not all printers
// can print polygons on top of each other.
Interestingly, the next line is either wrong or expressed badly,
because the check uses PolyPolygons when a VirtualDevice is in use:
// Also virtual devices are excluded, as some drivers are too slow.
Therefore, I've removed that comment as it seems rather misleading.
Change-Id: Ic496284cb2be8e7e2d348eae76aeeec994e1029c
Reviewed-on: https://gerrit.libreoffice.org/8802
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: Ie95ab47d0252d21391e51116ca5e2c424fba1b59
|
|
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
|
|
Change-Id: I6e099911afec9c4086f620b45656880135decff0
|