On 26/03/12 11:42, Cedric Bosdonnat wrote:
> Hi Michael,
>
> On Fri, 2012-03-23 at 17:44 +0100, Michael Stahl wrote:
>> On 20/03/12 12:19, Cedric Bosdonnat wrote:
>>> On Fri, 2012-03-16 at 23:29 +0100, Michael Stahl wrote:
this fix introduces a new array to store the borders and paints them
after the subsidiary lines are done, effectively on top of the
subsidiary lines.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=804d0a896731629397c5328c13c04a45bc55f459
>>>
>>> Thanks for the patch. I apologize as I should have done that a lot
>>> earlier. I cherry-picked and pushed it to -3-5.
>>
>> unfortunately it turns out that the patch introduced a regression,
>> fdo#47717, which is hopefully fixed with this one (as is fdo#45562,
>> which is about borders vs. hellish drawing objects), so please consider
>> it for libreoffice-3-5-2:
>>
>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=1024c172a5bfb3d85a86fcf7a046aa2b03950edd
>>
>> because up until a week ago my knowledge of Writer's drawing code was
>> precisely zero, it would be a good idea to test this a bit. in case
>> something is still wrong i'd strongly consider reverting the original
>> commit (0f0896c26fb260d1bbf31d7a886df3f61837f0f2).
>
> The patch fixes the mentioned bugs, but I still found a buggy case. See
> this document:
> http://people.freedesktop.org/~cbosdo/frame-to-back.odt
thanks, i think i've fixed this problem now (and attached your bugdoc,
slightly enhanced, to fdo#45562 as well), so please consider this for
libreoffice-3-5, which basically results in painting the borders in
almost exactly the same places as the old OOo code, and thus looks safe
to me wrt. layering:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5913506b2193e93ca2767ab7365ab2e76ed7848f
there is also some old border painting code in SwFlyFrmFmt::MakeGraphic,
which looks unnecessary to me because the borders are painted by
SwFlyFrm::Paint already; the patch also happens to fix the following
obscure regression introduced by my earlier patches:
1. create new writer document
2. Insert->Frame
3. OK
4. Edit->Image Map
5. crash
> IMHO, the best effort we could do on that border / subsidiary lines
> painting is to avoid buffering any line / subline. I'm still unsure if
> it's possible at all without having weird corner cases. I still believe
> in "each objects paints itself completely in one shot" idea, but that
> would mean to remove all the subsidiary lines code and consider those as
> the normal lines.
>
> Any thought on that? I we go in that direction, I'ld revert the patch as
> you mention in 3.5.2 and target that work for 3.6: it's still a bit
> risky and will need heavy testing.
i don't believe this is possible, as there is code that combines
adjacent borders if there is a sufficiently small gap between them (see
SwLineRect::MakeUnion), which is now mostly unused since
0f0896c26fb260d1bbf31d7a886df3f61837f0f2, and results in regressions
such as fdo#38215, about which i'll send another mail.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
