| Age | Commit message (Collapse) | Author |
|---|
|
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: I88d3e33823d68745b98625050a8a274f9ef04bcb
Reviewed-on: https://gerrit.libreoffice.org/27135
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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: I0a545008e1bd7f99fe1f928b4cd42fbcfdc85517
|
|
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>
|
