Painting only the necessary regions works fine normal background color,
but not for gradients, as the result is obviously different in case of
gradients.
Change-Id: I624410ed08604c13a810f784d6226d592295c5d3
In Word, the layer that contains a background image is behind the layer
that contains the paragraph background. In Writer, the paragraph
background is painted before the hell layer. Add a compat flag to change
the order, so the DOCX importer can trigger that.
To reproduce, create an XShape, send it to the background, set some
color for a paragraph background, and notice that the background color
is missing where the shape is behind the text.
Change-Id: I9b1fffd9ac9a6e5a1c3d1f65371440047d125b38
How to reproduce: if you have a paragraph of text, and hit Enter in the
middle of the paragraph, the frame around the document below the cursor
position gets darker. Regression from
f23d055dbe.
Change-Id: I41f9972b9be8d3ea02b52c0bc7355b012b41395d
Create a table with a merged cell like in the screenshot in the
bug, with a SAL_DEBUG in SwTabFrmPainter::PaintLines the following
lines are painted:
debug: paint start
1 debug: start: 2749,1488 end: 12387,1488
2 debug: start: 2749,1945 end: 7567,1945
3 debug: start: 7567,1945 end: 12387,1945
4 debug: start: 2749,2015 end: 12387,2015
5 debug: start: 2749,2542 end: 7567,2542
6 debug: start: 7567,2542 end: 12387,2542
7 debug: start: 2749,1488 end: 2749,1945
8 debug: start: 2749,1945 end: 2749,2015
9 debug: start: 2749,2015 end: 2749,2542
A debug: start: 7567,1945 end: 7567,2542
B debug: start: 12387,1488 end: 12387,1945
C debug: start: 12387,1945 end: 12387,2015
D debug: start: 12387,2015 end: 12387,2542
debug: paint end
*11111*11111*
7 B
7 B
*22222*33333*
8 A C
*44444*44444*
9 A D
9 A D
*55555*66666*
The problem is obviously that the Y coordinates of the lines 2, 3
and 4 differ; they should be on the same Y position.
The problem here is that logically horizontal lines must be painted
not centered but "below" the line, and It turns out that
SwTabFrmPainter::Insert cannot correct the positions properly to
do that, because it only looks at borders in a single cell.
When using the UI to set the borders, we get (for innner table borders)
only a bottom border in the cells, but no top borders, so the
top position of the logically vertical borders needs to be corrected
with the width of the bottom border of the cell _above_; a symmetric
correction of the bottom position to the top border of the cell below
is also necessary.
Fortunately if we just leave the positons alone in Insert then
TabFrmPainter will eliminate duplicate lines with equal positions
and so it's only necessary to correct the positions when actually
painting the line in wTabFrmPainter::PaintLines,
where we have the neighboring lines available.
Change-Id: Ia8519f6673db0f3a1ecaa68038896cac39609129
For borders in vertically oriented text it's necessary to correct
positions at different sides, i.e., right and left instead of
top and bottom; refactor SwTabFrmPainter::Insert some more
to handle this properly.
Change-Id: If20b9477415e9bd12e63aab4eed2f070065eb473
There is a special case for i#9860, which is for first line in follow
table (i.e. continued on new page) without repeated headlines:
Here the bottom border of the cell is used as the top border in case
the cell does not have a top border; this is fixed now with a bit of
refactoring, so the correct half width adjustment can be made.
Change-Id: I58ef81b7e13544014ef75973ea793f673a242488
In a table with collapsing borders, the horizontal borders need to be
painted "below" the reference line, and not "centered" on the line like
the vertical borders.
a0486f0243 was apparently an attempt to
fix this, but unfortunately it adjusted both top and bottom borders
with the top border width, which has horrible results if the top and
bottom borders have different widths.
Change-Id: I7605eda6ef8111612ceb1ded79c0811de9ca7b25
Frames with text direction Vertical RTL have their borders mangled while
painting, everything is rotated 90 degrees and so the model "left" border
ends up being painted as top border etc. Clearly the new drawing layer
based painting code is very surprised by this and ends up painting only
points instead of lines.
(regression from 0f0896c26f)
The start and end points of the vertical and adjacent horizontal borders
were apart by 1.5 to 3 twips, leading to small visible gaps in the corners.
This is fixed by using lcl_AlignWidth/lcl_AlignHeight on the border widths,
and by always computing the start/end positions from the outer edge,
which makes the horizontal and vertical start/end points match.
(regression from 0f0896c26f)
Apparently this special case in lcl_PaintLeftRightLine for printer
output devices is no longer necessary with the new drawing layer borders
and causes the vertical border lines to be far too short, leading to
visible gaps in the PDF.
(regression from 0f0896c26f)
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 0f0896c26f)
Painting borders of Flys in the heaven layer cannot be done correctly in
SwRootFrm::Paint, because delaying until then paints over other drawing
objects that are on top of the frame, so do it in SwFlyFrm::Paint,
like the old border painting code used to.
(regression from 804d0a8967)
...as reported by Linux-RHEL6-x86_64@14-with-check tinderbox.
For one, e94c4ab552 "Conver SV VARARR to
std::deque for sw module." did not use rbegin/rend to iterate backwards.
For another, e94c4ab552 and subsequent
1a41271403 "fixed crash due to use of STL deque
for SwLineRects" failed to get the nested loop "Remove all help line that are
almost covered (tables)" at the start of SwSubsRects::PaintSubsidiary converted
correctly. This attempt here at fixing it models the original behavior (before
conversion) more closely, and hopefully gets it right now.
