mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cb151051d79a7ec176e769a33a56e7d906fc1425
libreoffice/drawinglayer/qa/unit/border.cxx

215 lines
7.6 KiB
C++
Raw Normal View History

Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*/
tools: svstream.hxx needs only errcode.hxx & not errinf.hxx Change-Id: Ia28e35ae5af4f601e9a586a3deffbcd61702b0ca Reviewed-on: https://gerrit.libreoffice.org/36896 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
2017-04-14 08:42:15 +10:00
#include <memory>
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
#include <cppunit/TestAssert.h>
#include <cppunit/extensions/HelperMacros.h>
#include <cppunit/plugin/TestPlugIn.h>
#include <com/sun/star/table/BorderLineStyle.hpp>
#include <drawinglayer/geometry/viewinformation2d.hxx>
#include <drawinglayer/primitive2d/borderlineprimitive2d.hxx>
#include <drawinglayer/primitive2d/polypolygonprimitive2d.hxx>
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
#include <drawinglayer/primitive2d/polygonprimitive2d.hxx>
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
#include <drawinglayer/processor2d/baseprocessor2d.hxx>
#include <drawinglayer/processor2d/processorfromoutputdevice.hxx>
loplugin:refcounting Change-Id: I4f696bdb7b37da5949182d522b0d3c6c41fdc756
2016-04-15 18:28:16 +02:00
#include <rtl/ref.hxx>
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
#include <test/bootstrapfixture.hxx>
#include <vcl/vclptr.hxx>
#include <vcl/virdev.hxx>
convert SvxBorderStyle to scoped enum 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>
2017-03-16 12:44:19 +02:00
#include <editeng/borderline.hxx>
borderline: Adapted BorderLinePrimitive2D and usages 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
2017-09-08 13:39:29 +02:00
#include <svtools/borderhelper.hxx>
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
using namespace com::sun::star;
namespace
{
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
class DrawinglayerBorderTest : public test::BootstrapFixture
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
{
public:
void testDoubleDecompositionSolid();
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
void testDoublePixelProcessing();
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
CPPUNIT_TEST_SUITE(DrawinglayerBorderTest);
CPPUNIT_TEST(testDoubleDecompositionSolid);
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
CPPUNIT_TEST(testDoublePixelProcessing);
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
CPPUNIT_TEST_SUITE_END();
};
void DrawinglayerBorderTest::testDoubleDecompositionSolid()
{
// Create a border line primitive that's similar to the one from the bugdoc:
// 1.47 pixels is 0.03cm at 130% zoom and 96 DPI.
basegfx::B2DPoint aStart(0, 20);
basegfx::B2DPoint aEnd(100, 20);
borderline: Adapted BorderLinePrimitive2D and usages 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
2017-09-08 13:39:29 +02:00
double const fLeftWidth = 1.47;
loplugin:oncevar in cppcanvas..drawinglayer 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>
2017-06-22 16:05:11 +02:00
double const fDistance = 1.47;
double const fRightWidth = 1.47;
double const fExtendLeftStart = 0;
double const fExtendLeftEnd = 0;
double const fExtendRightStart = 0;
double const fExtendRightEnd = 0;
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
basegfx::BColor aColorRight;
basegfx::BColor aColorLeft;
borderline: Adapted BorderLinePrimitive2D and usages 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
2017-09-08 13:39:29 +02:00
const std::vector<double> aDashing(svtools::GetLineDashing(SvxBorderLineStyle::DOUBLE, 10.0));
const drawinglayer::attribute::StrokeAttribute aStrokeAttribute(aDashing);
std::vector< drawinglayer::primitive2d::BorderLine > aBorderlines;
aBorderlines.push_back(
drawinglayer::primitive2d::BorderLine(
drawinglayer::attribute::LineAttribute(
aColorLeft,
fLeftWidth),
fExtendLeftStart,
fExtendLeftStart,
fExtendLeftEnd,
fExtendLeftEnd));
aBorderlines.push_back(
drawinglayer::primitive2d::BorderLine(fDistance));
aBorderlines.push_back(
drawinglayer::primitive2d::BorderLine(
drawinglayer::attribute::LineAttribute(
aColorRight,
fRightWidth),
fExtendRightStart,
fExtendRightStart,
fExtendRightEnd,
fExtendRightEnd));
borderline: corrections for calc and writer Made corrections/finetuning for Calc and Writer. Had to remove some former code which tried to do corrections. Change-Id: Id9fc687b9a709d250faaad76c37ecfda8d8feb9b
2017-07-27 16:03:48 +02:00
rtl::Reference<drawinglayer::primitive2d::BorderLinePrimitive2D> aBorder(
new drawinglayer::primitive2d::BorderLinePrimitive2D(
aStart,
aEnd,
borderline: Adapted BorderLinePrimitive2D and usages 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
2017-09-08 13:39:29 +02:00
aBorderlines,
aStrokeAttribute));
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
// Decompose it into polygons.
drawinglayer::geometry::ViewInformation2D aView;
reduce copying when decomposing drawinglayer primitives 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>
2016-10-25 09:54:25 +02:00
drawinglayer::primitive2d::Primitive2DContainer aContainer;
aBorder->get2DDecomposition(aContainer, aView);
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
// Make sure it results in two borders as it's a double one.
CPPUNIT_ASSERT_EQUAL(static_cast<std::size_t>(2), aContainer.size());
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
// Get the inside line, now a PolygonStrokePrimitive2D
auto pInside = dynamic_cast<const drawinglayer::primitive2d::PolygonStrokePrimitive2D*>(aContainer[0].get());
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
CPPUNIT_ASSERT(pInside);
// Make sure the inside line's height is fLeftWidth.
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
const double fLineWidthFromDecompose = pInside->getLineAttribute().getWidth();
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
// This was 2.47, i.e. the width of the inner line was 1 unit (in the bugdoc's case: 1 pixel) wider than expected.
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
CPPUNIT_ASSERT_DOUBLES_EQUAL(fLeftWidth, fLineWidthFromDecompose, basegfx::fTools::getSmallValue());
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
}
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
void DrawinglayerBorderTest::testDoublePixelProcessing()
{
// Create a pixel processor.
ScopedVclPtrInstance<VirtualDevice> pDev;
drawinglayer::geometry::ViewInformation2D aView;
std::unique_ptr<drawinglayer::processor2d::BaseProcessor2D> pProcessor(drawinglayer::processor2d::createBaseProcessor2DFromOutputDevice(*pDev, aView));
CPPUNIT_ASSERT(pProcessor);
GDIMetaFile aMetaFile;
// Start recording after the processor is created, so we can test the pixel processor.
aMetaFile.Record(pDev);
// Create a border line primitive that's similar to the one from the bugdoc:
// 1.47 pixels is 0.03cm at 130% zoom and 96 DPI.
basegfx::B2DPoint aStart(0, 20);
basegfx::B2DPoint aEnd(100, 20);
loplugin:oncevar in cppcanvas..drawinglayer 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>
2017-06-22 16:05:11 +02:00
double const fLeftWidth = 1.47;
double const fDistance = 1.47;
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
double const fRightWidth = 1.47;
loplugin:oncevar in cppcanvas..drawinglayer 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>
2017-06-22 16:05:11 +02:00
double const fExtendLeftStart = 0;
double const fExtendLeftEnd = 0;
double const fExtendRightStart = 0;
double const fExtendRightEnd = 0;
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
basegfx::BColor aColorRight;
basegfx::BColor aColorLeft;
borderline: Adapted BorderLinePrimitive2D and usages 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
2017-09-08 13:39:29 +02:00
const std::vector<double> aDashing(svtools::GetLineDashing(SvxBorderLineStyle::DOUBLE, 10.0));
const drawinglayer::attribute::StrokeAttribute aStrokeAttribute(aDashing);
std::vector< drawinglayer::primitive2d::BorderLine > aBorderlines;
aBorderlines.push_back(
drawinglayer::primitive2d::BorderLine(
drawinglayer::attribute::LineAttribute(
aColorLeft,
fLeftWidth),
fExtendLeftStart,
fExtendLeftStart,
fExtendLeftEnd,
fExtendLeftEnd));
aBorderlines.push_back(
drawinglayer::primitive2d::BorderLine(fDistance));
aBorderlines.push_back(
drawinglayer::primitive2d::BorderLine(
drawinglayer::attribute::LineAttribute(
aColorRight,
fRightWidth),
fExtendRightStart,
fExtendRightStart,
fExtendRightEnd,
fExtendRightEnd));
rtl::Reference<drawinglayer::primitive2d::BorderLinePrimitive2D> aBorder(
borderline: corrections for calc and writer Made corrections/finetuning for Calc and Writer. Had to remove some former code which tried to do corrections. Change-Id: Id9fc687b9a709d250faaad76c37ecfda8d8feb9b
2017-07-27 16:03:48 +02:00
new drawinglayer::primitive2d::BorderLinePrimitive2D(
aStart,
aEnd,
borderline: Adapted BorderLinePrimitive2D and usages 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
2017-09-08 13:39:29 +02:00
aBorderlines,
aStrokeAttribute));
borderline: corrections for calc and writer Made corrections/finetuning for Calc and Writer. Had to remove some former code which tried to do corrections. Change-Id: Id9fc687b9a709d250faaad76c37ecfda8d8feb9b
2017-07-27 16:03:48 +02:00
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
drawinglayer::primitive2d::Primitive2DContainer aPrimitives;
borderline: Adapted BorderLinePrimitive2D and usages 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
2017-09-08 13:39:29 +02:00
aPrimitives.push_back(drawinglayer::primitive2d::Primitive2DReference(aBorder.get()));
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
// Process the primitives.
pProcessor->process(aPrimitives);
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
// Double line now gets decomposed in Metafile to painting four lines
// with width == 0 in a cross pattern due to real line width being between
// 1.0 and 2.0. Count created lines
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
aMetaFile.Stop();
aMetaFile.WindStart();
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
sal_uInt32 nPolyLineActionCount = 0;
drawinglayer, sw: indentation fixes Change-Id: Ia84182629f33220a0d85bde00c16f9c26f45e3c5
2016-04-19 13:55:33 +02:00
for (std::size_t nAction = 0; nAction < aMetaFile.GetActionSize(); ++nAction)
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
{
MetaAction* pAction = aMetaFile.GetAction(nAction);
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
if (MetaActionType::POLYLINE == pAction->GetType())
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
{
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
auto pMPLAction = static_cast<MetaPolyLineAction*>(pAction);
if (0 == pMPLAction->GetLineInfo().GetWidth() && LineStyle::Solid == pMPLAction->GetLineInfo().GetStyle())
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
{
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
nPolyLineActionCount++;
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
}
}
}
borderline: correct problems with border display 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
2017-07-04 16:28:58 +02:00
// Check if all eight (2x four) simple lines with width == 0 and
// solid were created
const sal_uInt32 nExpectedNumPolyLineActions = 8;
CPPUNIT_ASSERT_EQUAL(nExpectedNumPolyLineActions, nPolyLineActionCount);
tdf#99315 VclPixelProcessor2D: fix double border line width 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>
2016-04-18 16:53:48 +02:00
}
Related: tdf#99315 BorderLinePrimitive2D: fix solid line primitive width 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>
2016-04-15 15:46:06 +02:00
CPPUNIT_TEST_SUITE_REGISTRATION(DrawinglayerBorderTest);
}
CPPUNIT_PLUGIN_IMPLEMENT();
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
Reference in New Issue Copy Permalink