Age | Commit message (Collapse) | Author |
|
Change-Id: I8cafc7e106bbf9ddc790d72b9399efcf76df633e
|
|
Again, polygons can apparently have curved edges.
Change-Id: I6519da7bb7f0dde7f1550fe6b03c09be127f77d6
|
|
Change-Id: I882a42f58ac298d333985068b2fe6ef9ac198c8b
|
|
Change-Id: Iaec5aa5bd353c888a3b35a277a3618c29d9cbd67
|
|
Apparently GetVersionEx() is deprecated now, but the replacement header
"versionhelpers.h" does not exist in older SDKs (at least not in 8.0),
so try to determine the used SDK version by checking if the Windows 8.1
version constant _WIN32_WINNT_WINBLUE (0x0602) exists.
http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972%28v=vs.85%29.aspx
Change-Id: Ia9224a8c76823ada7cb294a600046c6a0fc843ad
Reviewed-on: https://gerrit.libreoffice.org/14020
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
This reverts commit 9995222d1141b326197a387cc7897b3971ce9e9a
and additionally converts the ruler settings to radio buttons and not
checkboxes
Conflicts:
vcl/source/control/tabctrl.cxx
Change-Id: Ie0eac5f07729447942065b7f415398165fbf067c
|
|
Change-Id: Ifa22e2914a1e34f6e2fd635973eca4101914bb88
|
|
Take care not reproducing fdo#86552 again.
Change-Id: I4a5967e76afcb5467addc81bc9eca61bb65865e7
Reviewed-on: https://gerrit.libreoffice.org/13992
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I962416f48fdb348d8a3d95edf747cfe2f1c929c9
|
|
The polygons that make the polypolygon cannot be simply drawn one onto another,
because if they overlap, it's actually xor (as used e.g. for drawing the border
when editing a text box Impress, which without this fix just made it a full
rectangle instead of a frame).
Change-Id: I67c7f6448fb3ee0f9742a2299c612515abff68d8
|
|
Apparently polygons can consist of curves too.
Change-Id: Ie35861e6d182e4bd4ac0523e78a90618c96f09a6
|
|
Change-Id: I8e66d369956a9bcf9c63c6eccad47d4b7a7eb67d
|
|
So far it's been always disabled, with the exception of the slide preview
extension.
Change-Id: Iaee6fe2d5267c9dfdc31cbf4fb90a9ac0e08e781
|
|
Change-Id: I0e4ad776cbf31f9a130aedf0f9741927560b5ac1
|
|
Change-Id: I3cf79b590b7d4c5aab92ccaebf6fd9c7eda529f7
|
|
This addresses some cppcheck warnings.
Change-Id: Ib6b9651b828287665f7248052855f0da2779806e
Reviewed-on: https://gerrit.libreoffice.org/13968
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
This addresses some cppcheck warnings.
Change-Id: Ia3910e7f1b33d16866b7e606fd648f152f9fe67a
Reviewed-on: https://gerrit.libreoffice.org/13971
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
This addresses some cppcheck warnings.
Change-Id: Ibebfe89ad1874f5fa9e20fb76a534d9c2da01e3f
Reviewed-on: https://gerrit.libreoffice.org/13969
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
The DrawDeviceAlphaBitmapSlowPath used fast/ugly scaling with
blending. With this a bilinear scaling is used which should
improve quality for downscaling (less than 50% should start to
degrade in quality as only 2 samples are always used) and
upscaling.
Change-Id: I56cdf2b5761687be891387343a773b6fefac03e2
|
|
Additioanlly cleanup and use ScopedReadAccess
Change-Id: Ia3365f4dc968368bdd90d4398188bffe2d56e89b
|
|
Change-Id: I1aa12c89cbddd83febac733f68904cda6b91f0a9
|
|
This fixes a crash as we would need to make each context current before
calling ReleaseFramebuffers.
However this is totally unnecessary as only the current context can have
bound framebuffers.
Change-Id: I8b1496bb890982742b3d2ebf60fdce47db642d70
|
|
left over from "SVStream operator>> to Write method" conversion
Change-Id: I619eb743d7890d5c70d0a94e51ce263567fa6f3b
|
|
Change-Id: I085f2d0e15c88b995bea3f99945c9ab2e2bcc909
|
|
glibc declares write() with the warn_unused_result attribute, so we need
to check the return value to avoid a compiler warning.
(This warning only seems to occur when gcc optimizations are enabled)
Change-Id: I31962aae63d0a12eecfe44bb7920a68b29c05d8a
Reviewed-on: https://gerrit.libreoffice.org/13927
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
if we didn't make use of them.
Change-Id: Iee1c2fef5966a614b068c832bf8c6b51973b4c8a
|
|
Change-Id: I4af8963ab7a9a53b457ea6054a603257b35a0e6e
|
|
Change-Id: If47baad0ec31f18fcb55c7db86fb2a316dd0807f
|
|
when you want to find the uses of it
Change-Id: I580c194f0fd200505d3df99089afc0872921a67b
|
|
Change-Id: I4044722f59aec3ed06cc77f9a29b01f5f1ab7d68
|
|
Hijacked ImplNumericGetValue() to parse fractional strings. It now searches for
'/' and build 3 string segments for mixed fractions: whole number, numerator
and denominator. It then follows the previous conversions and checks for
decimal formats. The output string remains as a decimal formatted string for
simplicity and standardization.
Change-Id: Iad842e0ef2b1f637025b09401b10fe93f90e0fba
Reviewed-on: https://gerrit.libreoffice.org/13225
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6835387cab5c093ad6645d75966786330bd0602a
|
|
Change-Id: Ib0554f6d489e410527d7bf4dc77f76db1bdbf1fc
|
|
Change-Id: Ia5ee0fdc7617b43c4874aa285459f9a1a52cea12
|
|
Change-Id: Ibd5c8574b0454f9f3688a65d246fd2dea4d0dda8
|
|
I believe the intent was to "retarget unresolved pLogCluster[n] to a glyph inside the cluster".
Unfortunately in the loop that detects clusters there was a typo and we are only indexing
element 0 of the array:
// retarget unresolved pLogCluster[n] to a glyph inside the cluster
// TODO: better do it while the deleted-glyph markers are still there
for( n = 0; n < nCharCount; ++n )
if( (p = pLogCluster[0]) >= 0 )
break;
That just doesn't make any sense, I believe we should be accessing pLogCluster[n].
If not, then why not just do:
p = pLogCluster[0];
n = nCharCount - 1;
Change-Id: I9d8873541b5c794071d69c0f63df88f17a352904
Reviewed-on: https://gerrit.libreoffice.org/13876
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I8d23c11decca864337ccc5288165058a7c21cd4e
|
|
regression from
commit e0cce521f1ad0cc384d30ce2f1077ea229fffe62
Author: Armin Le Grand <alg@apache.org>
AuthorDate: Thu Jan 10 16:28:40 2013 +0000
Commit: Caolán McNamara <caolanm@redhat.com>
CommitDate: Thu Jun 13 14:50:46 2013 +0100
Resolves: #i121504# Support for alpha channel in clipboard for all systems
(cherry picked from commit ef3931ff410117e1237b3bef7bc090e8b83b9519)
which blindly just bulldozed out the bMSOFormat branch
Change-Id: Iec354f1fb585f0803b9df472bc9ec9e103aa5847
|
|
Was missing from 82bc764bc9, without this opengl scaling wasn't used for these.
Change-Id: If853435b12383e799afe2f057c43263b2d2297fa
|
|
As a side effect, this prevents the lines from looking too wide,
because of generic polygon drawing being a bit too generous with AA.
Change-Id: I17314c39fd57e33ecbd10b8a8785c600bdc5b212
|
|
I'm somewhat confused by why there needs to be a separate line width
for X and Y, but apparently there is, and the latter shouldn't be just plain 0
(otherwise a number of drawPolyLine() implementations either skip using
a simpler path for the usual case of them being equal, or even plain to refuse
work at all and cause a fall back).
And I hope this doesn't lead to finding out that some of those implementation
are actually buggy.
Change-Id: I2dbbd1539c4a96d41935cce9ae6565872e2a459b
|
|
Change-Id: I66a04febdbfa673e0883ab6f574bb7768cad7953
|
|
118529d4644a and 011903894 might have been technically correct, but
'mProgramIsSolidLineColor' is clearly a misnomer at best, and they'd
have made it even more likely that this would break yet again.
Change-Id: I1f01663e2abc0b1b0e557ae7241637a96e1a402a
|
|
Change-Id: Ifa69f3272ebda2a61ac00d2affb8aebd4524f0fc
|
|
and dump the ones that nothing is listening to
Change-Id: I253ef284df785812a439dd160edba1b07fdbaac4
|
|
and drop DATACHANGED_DATETIME because no-one is using it
Change-Id: Id5ac9a7fbba0e35501ed82e5252f66858621f7ff
|
|
and their default implementations are empty, so just delete them
Change-Id: Ibae2f92c3326ad46c4b6ef462b5b7b62ad63f0d8
|
|
Change-Id: Ib80a8dd433b22a5e88aaab8e11d5c42ced8097ae
|
|
- remove the SHORT_WAIT test parameter, no-one is using it
- inline the various independent shortWait() methods
- use the util.utils.shortWait() utility method everywhere
Change-Id: I93cd4a2580172a1441d2ff3d390f52b9505e2721
|
|
Basically, the issue noted here (justification adjustment issues in CTL) is
a legacy problem caused by emulating the EmrText structure, which is an
Enhanced Metafile (EMF) structure (or "object"). The EmrText structure holds
an array of inter-character spacing widths for text. It is used in the EMF
records EMR_EXTTEXTOUTA and EMR_EXTTEXTOUTW, which is flawed in that it
doesn't consider issues around CTL scripts and only cares about character
interspacing - i.e. it maps to each printable character, and doesn't take into
consideration other sorts of glyphs.
Change-Id: Ib7ae994758a835e9d8cb5f479a0b91d3d5809b8c
|