| Age | Commit message (Collapse) | Author |
|---|
|
See tdf#42949 for motivation.
Change-Id: I89c082d62409b40c8472b865cc60b0d10923c9c1
Reviewed-on: https://gerrit.libreoffice.org/75015
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I73f00a0cc052173167a539be02a42c47da34dd98
Reviewed-on: https://gerrit.libreoffice.org/67793
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Step5: Move the view-dependent decomposition from
BorderLinePrimitive2D to SdrFrameBorderPrimitive2D.
It is now possible to use discrete sizes before the
line and edge matching is done what will look much
better. When it was done at BorderLinePrimitive2D
and the matching was already done, that match was
'displaced' with the adapted forced scale to discrete
units.
The space and size used when zooming out for a single
discrete unit (pixel) can heavily vary - it just covers
a much larger logical area than the 'real' line/poly
would do. All this needs to be handled (also for bound
ranges) and can only be in a good way using primitives.
Adapted to no longer do view-dependent changes in
BorderLinePrimitive2D. Adapted to do these now at
SdrFrameBorderPrimitive2D. Currently used to force
the existing border partial lines (up to three) to
not get taller than one logical unit.
Adapted to no longer switch off AntiAliased rendering
in VclPixelProcessor2D for processBorderLinePrimitive2D,
this is problematic with various renderers on various
systems (e.g. vcl still falls back to render multiple
one-pixel-lines when taller than 3.5 pixels which looks
horrible combined with other parts like filled polygons)
All this needs fine balancing on
- all systems
- all renderers
- all apps (which all have their own table implementation)
- all render targets (pixel/PDF/print/slideshow/...)
Done as thorough as possible, but may need additional
finetuning. May also be a motivation to move away from
vcl and implement these urgetly needed system-dependent
primitive renderers...
Adapted UnitTest testDoublePixelProcessing with the needed
comments.
Change-Id: Ie88bb76c2474b6ab3764d45a9cd1669264492acd
Reviewed-on: https://gerrit.libreoffice.org/62344
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
|
|
Change-Id: I30121764303579a7cb4ded0f0f48cc1f8fff6c33
Reviewed-on: https://gerrit.libreoffice.org/46946
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...and fix the fallout
Change-Id: Ie514bd95d5a9f990a887566619031e9844c40b92
Reviewed-on: https://gerrit.libreoffice.org/45195
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Big changes to BorderLinePrimitive2D and BorderLine, freeing
it from one/three entries, going to a free definition using
gaps with width but without color. Adapted usages and creation,
not yet tested much
Change-Id: Ic1255a790401901c3166d200205bc23322b37185
|
|
As preparation for more detailed definition of BorderLine
primitives I have adapted the BorderLine definition to
work with motre possibilities to define the LineStartEnd
definitions in a BorderLineExtend class. That one is
flexible to hold all kinds of definitions - from none to
all four possible extends (Start/End, Left/Right of vector)
Cleanup of DiagStyle and others: DiagStyle is not needed
anymore due to no longer using angles calculated, but
being based on vectors defining the geometry. Also cleaned
up quite a bit of no longer needed calculation stuff for
the control.
|
|
Made corrections/finetuning for Calc and Writer.
Had to remove some former code which tried to do
corrections.
Change-Id: Id9fc687b9a709d250faaad76c37ecfda8d8feb9b
|
|
Borderline display with direct paint and with primitive direct
paint has quite some errors in the current state. Started to
unify usages, check deeper with creation/usage.
borderline: deep changes to BorderLine
Found basic error in determining the offset values
for BorderLinePrimitive creation, these were not
centered on the lines. Corrected that. This makes
it possible to remove the formally used clipping
which seems to have been used to correct that. Also
allows to go back to a 'normal' decomposition that
creates line primitives as expected. That again can
then be painted quite normally.
Also added view-dependent case to the decomposition
to guarantee a gap of one discrete unit (pixel).
Removed the direct painter, too. Checked and corrected
stroking.
borderline: Adapted previews to primitives
Added code to use the primitive representation in
all dialogs and apps using tables. The edit views
use these mostly, so the preview should do that,
too. Currently missing is a good visualization of
diagonals, but this is also true for edit views.
Checked all apps and table usages to not get worse
borderline: correct line dash visualization
When a dashed line is used, a factor of 10.0 was applied in the
original coded, added that. Also the orientation of vertical
borders was inverted since it was simpler to exchange Start/End,
but this also mirrors the line dash visualisation, corrected that
Change-Id: I4c1b380a76cb37389fab1259a53fb7cc9da982d1
e95e246d5563360617a2a2213e4d5ec7d0e736b9
62369b4de58fb0264aeb710ec6983ceddca5701d
77418cc6c84ebb0632f8c3448976e82ce612d6b6
b4eb28dc86ce05eb89b26517167305b994158ef8
borderline: adapt cppunittest and clang
|
|
Change-Id: I5456aad61fb0dfe6830eae62b91d1a6399d6343f
Reviewed-on: https://gerrit.libreoffice.org/39128
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia28e35ae5af4f601e9a586a3deffbcd61702b0ca
Reviewed-on: https://gerrit.libreoffice.org/36896
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
and rename to SvxBorderLineStyle
Change-Id: I19e530f162e4ca6290a0ad076e7fe3d5775ae6bc
Reviewed-on: https://gerrit.libreoffice.org/35265
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
instead of returning a Primitive2DContainer from each method which we
are then going to immediately append to another container, pass down a
single container by reference which we can append to
Change-Id: I0f28a499d2ec54f7111a7044c30099767aa079e1
Reviewed-on: https://gerrit.libreoffice.org/30258
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia84182629f33220a0d85bde00c16f9c26f45e3c5
|
|
Regression from commit 2c91cb08d65cd35fa8ef6eaca3677aa82fb58cbe (better
drawing support for borders of different width, fdo#33634, 2012-04-04),
the problem is that previously the width of inner/outer double border
lines got rounded to integer values quite early, but after the commit
they are kept at a double precision for much longer, which needs pixel
correction in VclPixelProcessor2D.
Example: if the border with is 1.47, and the line gets moved by 0.2
pixels, then the inner and outer edge of the line will be 0.2 and 1.67,
which gets rounded to 0 -> 2 in the pixel processor. Previously the
input was rounded to 1, so moving by 0.2 resulted in 0.2 -> 1.2, which
got rounded to 0 -> 1. The result is that sometimes the line width is 1
pixel wider than expected.
Fix the problem by allowing VclPixelProcessor2D to request pixel
correction from BorderLinePrimitive2D. It wouldn't be possible to do
pixel correction only in VclPixelProcessor2D, as it has no idea what to
correct: it only gets polygons, so it has no idea if e.g. the top of a
polygon is the outer edge of a top border line or an inner edge of a
bottom border line.
Change-Id: I1971f3a952fbcdc598ab46c659e12d976c13cbe6
Reviewed-on: https://gerrit.libreoffice.org/24221
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I4f696bdb7b37da5949182d522b0d3c6c41fdc756
|
|
Regression from commit 2c62596cf264ef10749d8bfdb2bb2ebef2d98fbc
(fdo#75260: Correctly draw double lines for both Writer and Calc.,
2014-03-03), the problem was that when decomposing a double border line
promitive to solid line primitives (which happens for the legacy
"border" type, while both the Calc UI and Excel importer creates
"border-thin" ones), the decomposed inner line's height was larger than
the requested width.
As a result there was no gap between the polygon of the inner and the
outer line of the double border, looking like a non-double border.
The width of the outer border is still incorrect on the screen, though.
Change-Id: Ia9713c315ce8f23e2579b257169798e7c82c0a64
Reviewed-on: https://gerrit.libreoffice.org/24115
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
