Re: [REVIEW][3-5] fdo#38215: sw: fix consecutive border line gaps regression

2012-04-20 Thread Michael Stahl
On 20/04/12 14:11, Caolán McNamara wrote:
 On Mon, 2012-04-16 at 17:19 +0200, Michael Stahl wrote:
 this fixes a regression in painting border lines in LO 3.4, leading to
 small visible gaps between borders of consecutive paragraphs, and is
 proposed for libreoffice-3-5.

 fixed by re-implementing the merging of border lines that are less than
 1.5 pixel apart that was done in the old paint implementation.
 
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=0868a0155a2b57daf7b862d120aead0458372b17
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=44092833d3a0f0d6074c64bd0e64bbdf11109afe
 
 So, looks reasonable to me, except it doesn't apply cleanly to 3-5, can
 you tweak it to apply to 3-5 and we can push that then to 3-5.

it requires this one first:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1024c172a5bfb3d85a86fcf7a046aa2b03950edd

but then i still got a trivial conflict, so i've merged the 2 commits
into one that applies on top of the above, see attachment.

 And why
 the change from ::std::swap to a manual push_back of each line to new
 SequenceAsVector followed by clear on the original ?

because the types of the elements are different, the return value has
uno::Reference of XFooPrimitive while the member is changed to contain
rtl::Reference of BorderLinePrimitive so it's not necessary to
dynamic_cast while iterating over it.
From 0919f42d62b658fc39be1be269fdfea0892f8a2c Mon Sep 17 00:00:00 2001
From: Michael Stahl mst...@redhat.com
Date: Mon, 16 Apr 2012 16:12:36 +0200
Subject: [PATCH] fdo#38215: merge consecutive border lines:

This re-implements the merging that was done by SwLineRects::AddLineRect,
SwLineRect::MakeUnion with the drawing layer border lines.
This is used to merge borders of paragraphs and of tables that have the
separating border-model, which fixes both the tiny dividing gaps
between successive borders in the second bugdoc and the weird subtly
differently rendered successive borders in the first bugdoc.
(regression from 0f0896c26fb260d1bbf31d7a886df3f61837f0f2)

(cherry-picked from 0868a0155a2b57daf7b862d120aead0458372b17
 and 44092833d3a0f0d6074c64bd0e64bbdf11109afe)

Conflicts:

	sw/source/core/layout/paintfrm.cxx
---
 sw/source/core/layout/paintfrm.cxx |  144 +---
 1 files changed, 132 insertions(+), 12 deletions(-)

diff --git a/sw/source/core/layout/paintfrm.cxx b/sw/source/core/layout/paintfrm.cxx
index 1fd7013..797f3af 100755
--- a/sw/source/core/layout/paintfrm.cxx
+++ b/sw/source/core/layout/paintfrm.cxx
@@ -132,6 +132,9 @@
 
 using namespace ::editeng;
 using namespace ::com::sun::star;
+using ::drawinglayer::primitive2d::BorderLinePrimitive2D;
+using ::std::pair;
+using ::std::make_pair;
 
 #define GETOBJSHELL()   ((SfxObjectShell*)rSh.GetDoc()-GetDocShell())
 
@@ -223,19 +226,21 @@ public:
 
 class BorderLines
 {
-::comphelper::SequenceAsVector
- ::drawinglayer::primitive2d::Primitive2DReference m_Lines;
+typedef ::comphelper::SequenceAsVector
+::rtl::ReferenceBorderLinePrimitive2D  Lines_t;
+Lines_t m_Lines;
 public:
-void AddBorderLine(
-::drawinglayer::primitive2d::Primitive2DReference const xLine)
-{
-m_Lines.push_back(xLine);
-}
+void AddBorderLine(::rtl::ReferenceBorderLinePrimitive2D const xLine);
 drawinglayer::primitive2d::Primitive2DSequence GetBorderLines_Clear()
 {
 ::comphelper::SequenceAsVector
 ::drawinglayer::primitive2d::Primitive2DReference lines;
-::std::swap(m_Lines, lines);
+for (Lines_t::const_iterator it = m_Lines.begin(); it != m_Lines.end();
+++it)
+{
+lines.push_back(it-get());
+}
+m_Lines.clear();
 return lines.getAsConstList();
 }
 };
@@ -442,6 +447,121 @@ SwSavePaintStatics::~SwSavePaintStatics()
 
 SV_IMPL_VARARR( SwLRects, SwLineRect );
 
+static pairbool, pairdouble, double 
+lcl_TryMergeLines(pairdouble, double const mergeA,
+  pairdouble, double const mergeB)
+{
+double const fMergeGap(nPixelSzW + nHalfPixelSzW); // NOT static!
+if (   (mergeA.second + fMergeGap = mergeB.first )
+ (mergeA.first  - fMergeGap = mergeB.second))
+{
+return make_pair(true, make_pair(
+std::min(mergeA.first, mergeB.first),
+std::max(mergeA.second, mergeB.second)));
+}
+return make_pair(false, make_pair(0, 0));
+}
+
+static ::rtl::ReferenceBorderLinePrimitive2D
+lcl_MergeBorderLines(
+BorderLinePrimitive2D const rLine, BorderLinePrimitive2D const rOther,
+basegfx::B2DPoint const rStart, basegfx::B2DPoint const rEnd)
+{
+return new BorderLinePrimitive2D(rStart, rEnd,
+rLine.getLeftWidth(),
+rLine.getDistance(),
+rLine.getRightWidth(),
+rLine.getExtendLeftStart(),
+rOther.getExtendLeftEnd(),
+

Re: [REVIEW][3-5] fdo#38215: sw: fix consecutive border line gaps regression

2012-04-20 Thread Caolán McNamara
On Mon, 2012-04-16 at 17:19 +0200, Michael Stahl wrote:
 this fixes a regression in painting border lines in LO 3.4, leading to
 small visible gaps between borders of consecutive paragraphs, and is
 proposed for libreoffice-3-5.
 
 fixed by re-implementing the merging of border lines that are less than
 1.5 pixel apart that was done in the old paint implementation.

 http://cgit.freedesktop.org/libreoffice/core/commit/?id=0868a0155a2b57daf7b862d120aead0458372b17
http://cgit.freedesktop.org/libreoffice/core/commit/?id=44092833d3a0f0d6074c64bd0e64bbdf11109afe

So, looks reasonable to me, except it doesn't apply cleanly to 3-5, can
you tweak it to apply to 3-5 and we can push that then to 3-5. And why
the change from ::std::swap to a manual push_back of each line to new
SequenceAsVector followed by clear on the original ?

 http://cgit.freedesktop.org/libreoffice/core/commit/?id=1d5e263a129c56e561ce145bad9749027c583a75
this at least got pushed along with fdo#38635: sw: printing border lines
gaps regression

C.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: [PUSHED][REVIEW][3-5] fdo#38215: sw: fix consecutive border line gaps regression

2012-04-20 Thread Caolán McNamara
On Fri, 2012-04-20 at 14:56 +0200, Michael Stahl wrote:
 it requires this one first:
 
 http://cgit.freedesktop.org/libreoffice/core/commit/?id=1024c172a5bfb3d85a86fcf7a046aa2b03950edd
 
 but then i still got a trivial conflict, so i've merged the 2 commits
 into one that applies on top of the above, see attachment.

ok, all done. Pushed to 3-5.

 the types of the elements are different, the return value has
 uno::Reference of XFooPrimitive while the member is changed to contain
 rtl::Reference of BorderLinePrimitive 

Righteo.

C.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


[REVIEW][3-5] fdo#38215: sw: fix consecutive border line gaps regression

2012-04-16 Thread Michael Stahl
this fixes a regression in painting border lines in LO 3.4, leading to
small visible gaps between borders of consecutive paragraphs, and is
proposed for libreoffice-3-5.

fixed by re-implementing the merging of border lines that are less than
1.5 pixel apart that was done in the old paint implementation.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0868a0155a2b57daf7b862d120aead0458372b17

the fix first requires this commit because start being the smaller Y
coordinate but the larger X coordinate was very confusing:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1d5e263a129c56e561ce145bad9749027c583a75

also this one because apparently my gcc is unusually un-idiotic:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=44092833d3a0f0d6074c64bd0e64bbdf11109afe

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice