Age | Commit message (Collapse) | Author |
|
Change-Id: I3e34d078772c701d07c14de0da45bbdcb7b44838
|
|
Change-Id: I44246f85acf197fa1707b37691f21e6e996bc2d3
|
|
Change-Id: I8a57ad303666cfcb3e338fc1933c29a887240a5a
|
|
Change-Id: I107817e730ca0bd94d66ecf9719c3a6eb273e4f1
|
|
I asked on the LO dev mailing list what Evtl means and what is being
expanded, and Michael Stahl kindly responded:
> "Evtl" usually means German "eventuell" which means "possible" or
> "optional" (i.e. totally different meaning from English "eventual").
So in other words, it means paint using line geometry and optionally
expand. Or in other words, it just draws a line using a B2DPolyPolygon.
Thus, I have renamed it to drawLine(), which is a private function of
OutputDevice. I think this makes it somewhat clearer :-)
Change-Id: I7eec23c61eda9dc1074922f5f2f67eacbc7fd725
Reviewed-on: https://gerrit.libreoffice.org/12264
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I08c4a456f9e80f70719ca8c3ad5c0f0d2d8282f6
Reviewed-on: https://gerrit.libreoffice.org/12258
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
they are largely unnecessary these days, since our OUString infrastructure
gained optimised handling for static char constants.
Change-Id: I07f73484f82d0582252cb4324d4107c998432c37
|
|
Change-Id: I86f503f740565bfef27a68636074a38d44046196
|
|
Change-Id: I2e73cd105af7aa9d926659d3275bf10de9993d62
|
|
Change-Id: I08993551473fb9a8284e2a1ed772c99050f785d8
Reviewed-on: https://gerrit.libreoffice.org/12251
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ic29b569df25f8966326101d5179506b24483cb43
|
|
Change-Id: Ibc9345959462b5a1cb9e47791742217e567b3cd0
|
|
Change-Id: Icd4df8610072f5283276738896cb5c01762838ea
|
|
Change-Id: I4dfa2d3fa2d0c0b5029eb2cd3d724e7e6f2e3d6e
|
|
Change-Id: I5e1b6ebb4af3a602233bfb09ba6397569f18aac9
|
|
Change-Id: I8dd9b2a5dd09d5d0be123e9f8a303ad8e280b0f2
|
|
The aim of this patch is to allow for native gradient rendering in
SalGraphics (i.e. let OpenGL do this natively). It is a two step
process:
1. I need to allow gradient draw into SalGraphics, however the current
completely intertwined with the metafile code in OutputDevice. I am
seperating the gradient metafile code from the gradient drawing code.
2. After splitting the metafile stuff from the actual gradient drawing,
I am now able to call on SalGraphics::DrawGradient(). This just
calls on SalGraphics::drawGradient() which returns false if there is
no way of drawing native gradients, and true if there is. If false,
then we use OutputDevice's DrawGradient() functionality.
Change-Id: Ibaaabe13b76a8e7a037d9f751b5f662653a50566
Reviewed-on: https://gerrit.libreoffice.org/12119
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I74c29a39367e7781e5e6cf9795c7176ef599f97e
|
|
Change-Id: Ib92e1a22d7d25f4498272731af12c485937f38ef
|
|
Change-Id: I92c2472a34aca9f7f1a617666607040cadb0b643
|
|
Change-Id: Iaddc47087d796d96fa0ed054c254b3cf83c90b5e
|
|
Change-Id: If1d822e0e6c87e792ff4a769a525e161505325c9
|
|
since
commit 808d273db098e2269e53813595a6bfc7b160e28e
Date: Fri Apr 25 11:56:54 2014 +1000
Remove ImpInitOutDevData and ImplDeInitOutDevData in OutputDevice
All these do is some very, very basic initialization. There is no need
to lazy load the structure, it should be initialized when OutputDevice
is created in the constructor and deinitialized in the destructor.
mpOutDevData is never NULL
Change-Id: Ie08f7520e8c09b57e056c086bba3089abe2486fa
|
|
this includes a fix to leave disabled menu entries disabled.
This reverts commit 454f5c3018c6d61d5872f7c23c7590c2157444e4.
Change-Id: Ifb66b0b241378437f040af19ec163da3cb8d815d
Reviewed-on: https://gerrit.libreoffice.org/12061
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
Change-Id: I8da53d7b81d28b0051be96c0c4ee0a29d8ed8360
Reviewed-on: https://gerrit.libreoffice.org/12209
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
Change-Id: I87084cbc4d6a8b6f5edbf8b90791c2b1e75b4afb
Reviewed-on: https://gerrit.libreoffice.org/12211
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
I've merged these two functions, I just added a new function parameter to switch on and off
the AA check, this function parameter defaults to false so DrawPolyLineDirect needs to do the
AA check each time. If bBypassAACheck is set to true, then we automatically enable AA.
Change-Id: Id2d9b2036a41716590f7b87f658f5bb210964392
Reviewed-on: https://gerrit.libreoffice.org/12191
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: If86cc3cd9ea40dc826c93d6adb6e11fab20a15eb
|
|
I've renamed TryDrawPolyLineDirect() to DrawPolyLineDirect() and also
renamed TryDrawPolyLineDirectNoAACheck() to drawPolyLineDirectNoAACheck().
However, at the same time I feel that there is no need to call on
drawPolyLineDirectNoAACheck in most instances, because DrawPolyLineDirect
does an AA check before it can continue anyway. There is one instance where
constantly checking the AA check is inefficient because it's in a loop, in
that case then we call directly on drawPolyLineDirectNoAACheck, but this is
the only case it is necessary.
Change-Id: Ie0320bfc45b5c0e1ac6ce35912da3e2897af9429
Reviewed-on: https://gerrit.libreoffice.org/12190
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I145ebcfb92fc75f4558d3bf090093aef9e848136
Reviewed-on: https://gerrit.libreoffice.org/12188
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
OutputDevice has a private function that rotates a point around another
point. However, there is no real reason why OutputDevice should be
responsible for this - it's really the responsibility of the Point
class in the tools module. Therefore, I've moved this functionality out
of OutputDevice and into Point, but I've renamed it from the rather
confusing name "ImplRotatePos" to "RotateAround", which is what it
actually does.
Change-Id: If12fb40a7b476653224d4edfc01887bc91a80c7d
Reviewed-on: https://gerrit.libreoffice.org/12171
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I9ab09d65ba7587230de320e22a79e9c7224f4ade
|
|
Change-Id: Ifbb7ab559d161fdc8b6838ea34a4519286423997
|
|
Change-Id: Ib0e8fefb154417dde95bc70765ad675a1824db44
|
|
Change-Id: If19a61c82f1cf723c8e78e8d27461a543ddbfd40
|
|
Change-Id: I58c1b4c9e4c4b3751b233d2fe10b9c953b945c4a
Reviewed-on: https://gerrit.libreoffice.org/12179
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
+ adapted for WNT (it does really need it for app/settings.cxx)
Change-Id: I33a65d24f7c6c46a36718e4421ae88de180a9739
Reviewed-on: https://gerrit.libreoffice.org/11814
Reviewed-by: Douglas Mencken <dougmencken@gmail.com>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
Tested-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|
|
Change-Id: I5362d997bfa086c9fb1726efcb15132a966684f6
Reviewed-on: https://gerrit.libreoffice.org/12160
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I38517bb7fbf4ab1e9314a28973b707223d7120e7
|
|
Change-Id: Ia914c4842e69b3ea57692f1f8ac52c321240b7c4
|
|
Change-Id: Ic9aab232667a9b0a3a995d7b033b7ba508fd42dc
|
|
Change-Id: I91bf3bce86d6b7fb01a26a6785d5bcfd7677878c
|
|
because it's implementation is the same as operator==
Change-Id: If9b63abcd13f899735d59d85be3da54406a6e324
|
|
Change-Id: I413d821a984ab556bd19c52704c04de6d828f699
|
|
so just dump it
Change-Id: I006045aea345e84ff1944fc1ed1daa94bd7bca61
|
|
There was a snaffu with the handling of DXArray
concerning the special case of the 'first' character
and how that translate when the glyph order is not
the same than the character order
Change-Id: Ie9273ff22fa2d22ca0df2b583768ffb2b2a59930
|
|
Change-Id: I577f7582b4938dc5dcd75460dd889c5675ee3c17
|
|
Change-Id: Ia43976d84eede6f699381bc4f3daf89b95e4cb4f
Reviewed-on: https://gerrit.libreoffice.org/12150
Reviewed-by: Bryan Quigley <gquigs@gmail.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I31bfb0b6cdcac78592759824cb74ab62d98fcc7b
|
|
Change-Id: I8d7eb4c01197e885abca717c7814c61a7641ac9d
|