Bug 42750 - Table, border line style double line (inner/outer lines 1 twip wide) still broken
Summary: Table, border line style double line (inner/outer lines 1 twip wide) still br...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: x86-64 (AMD64) Linux (All)
: medium critical
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: bibisected35 bibisected35older targe...
Keywords: regression
: 47966 (view as bug list)
Depends on:
Blocks: 44768
  Show dependency treegraph
 
Reported: 2011-11-09 11:35 UTC by Greg Madden
Modified: 2012-05-11 13:55 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
template made using table funtion (14.61 KB, application/vnd.oasis.opendocument.text-template)
2011-12-21 04:45 UTC, Greg Madden
Details
odg with screenprints from 3 versions (64.53 KB, application/vnd.oasis.opendocument.graphics)
2012-02-06 01:41 UTC, Cor Nouws
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Madden 2011-11-09 11:35:49 UTC
New release 3.4.4, update bug.

The new feature introduce in the 3.4.x series changed the way 'Table Format>Borders>Line' is configured. All my double line borders are very wide, hiding content in some cases.

 The new Line configuration is done  by 'style' & 'width' neither which seem to produce a readable double line border.

This is a feature that has worked here since OOv. 1.02, quite a large archive of documents affected, as are all my templates.

Thank You  for your consideration
Comment 1 Greg Madden 2011-12-21 04:45:12 UTC
Created attachment 54634 [details]
template made using table funtion

Not sure if this process works. This feature change has existed for all of the 3.4 releases and now 3.5. so nothing has been done, or said.

I would like to know if anything will ever be done to make previous versions compatible with 3.4 &  3.5. 

No backword compatability is not a good feature, I can live with it if someone would at least acknowledge it and say so. I can begin the task of manually correcting my archives (9 years) and templates.

thank you
Comment 2 Michael Stahl (allotropia) 2012-01-27 09:02:11 UTC
the attached document has cell borders like this:

 style:border-line-width-left="0.0007in 0.0347in 0.0007in"

2 problems in LO 3.4 and later:

- the double borders are tripled in width.
  this should be fixed with the fix for bug 38542

- the inner/outer lines are 1 twip wide.
  with the fix for bug 38542, these are now no longer painted;
  it seems that 1 twip border lines are generally not painted
  in a visible way (on my Fedora 16 gnome-shell desktop anyway)
  (the third document at bug 38542 has the same problem, without
  a double border even)

this used to work in versions before LO 3.4 => regression.

so since Cedric has set the bug 38542 to fixed already,
i'll say that one was about the tripled double borders,
and this one is about the invisible 1 twip borders.
Comment 3 Greg Madden 2012-01-29 11:28:39 UTC
Updated my testing to include v 3.5.0 RC2. I would test the fixes if there was a build available.
Comment 4 Cor Nouws 2012-01-30 12:44:07 UTC
Hi greg,

(In reply to comment #3)
> Updated my testing to include v 3.5.0 RC2. I would test the fixes if there was
> a build available.

Those are available here.
http://www.libreoffice.org/download/pre-releases/

But this issues bug is not yet fixed.

And I doubt if the fix for https://bugs.freedesktop.org/show_bug.cgi?id=38542 will be in 3.5.0 RC3 already (did not follow the list the last days)

But feel free to test of course. Thanks
Comment 5 Greg Madden 2012-02-05 16:56:29 UTC
LO 3.5.0 RC3 fixed the extra wide lines used to draw the double border style, on my existing documents & templates, thank you for the fix.

It seems that the on screen rendering of the border lines has changed since 3.3.x series. When creating new tables with double line borders I can no longer tell that there are double lines unless I magnify the view. Printing is the only way to see what the actual results will look like.

The space between the two lines is to small, or smaller than it was prior to the change to Table line styles starting in the 3.4.x series.

IMHO, I support reverting back to the way the Table border line styles were configured. While my archives are readable now, the function is not usable for new table borders.
Comment 6 Cor Nouws 2012-02-06 01:41:37 UTC
Created attachment 56648 [details]
odg with screenprints from 3 versions


hi Greg. Michael
please see the attachment with how the file shows for me.
- what line should I see extra when I print it?
- Looks as if 3.5.0rc3 has a problem ?
Comment 7 Greg Madden 2012-02-08 20:39:19 UTC
(In reply to comment #6)
> Created attachment 56648 [details]
> odg with screenprints from 3 versions
> 
> 
> hi Greg. Michael
> please see the attachment with how the file shows for me.
> - what line should I see extra when I print it?
> - Looks as if 3.5.0rc3 has a problem ?

Hmmm, your 3.3.0 rendering doesn't look anything like mine, double lines work here on thiat ver. My issue started with ver 3.4.x, which is as your attachment shows, including 3.5.0 RC1 & 2.

Version 3.5.0RC3 I get double line borders, as shown between the cells: project & outlet no., the border should extend all the way around the document, it does here, so your examples do not match mine .

I have pdf files of how they render attached in bug #38542.
Comment 8 Michael Stahl (allotropia) 2012-03-13 12:37:59 UTC
looking into the bugdoc a bit more, the results are surprising:

1 twip borders drawn with the following:
- OOo 3.3 print to Postscript file
- OOo 3.3 / OOo 3.4beta display
- LO 3.4 / LO 3.5.1 print to PDF file

1 twip borders NOT drawn with the following:
- OOo 3.3 PDF export
- OOo 3.4beta print to PDF file
- LO 3.4 / LO 3.5.1 display (specifically,
  vertical single borders and inner double borders are drawn,
  not horizontal single or outer double borders)

(it seems OOo 3.4 and LO based on that can't write PostScript any more)

it seems like this bug is in various Hairline drawing
implementations in VCL etc., and what has changed in various
versions is which of these are used to implement printing or display?
Comment 9 Michael Stahl (allotropia) 2012-03-13 12:41:16 UTC
argh, how does the version always manage to change itself...
Comment 10 Michael Stahl (allotropia) 2012-03-15 07:45:50 UTC
reverting 951d117e1c4940290744ebedfb1caef3048abb3c in the libreoffice-3-4
branch (plus 15 minutes of bashing on it to get it to compile)
gives me a LO 3.4 that displays the document almost identically to OOo.
(corresponding commit in core is 0f0896c26fb260d1bbf31d7a886df3f61837f0f2)
also, the PDF looks good as well.
Comment 11 Michael Stahl (allotropia) 2012-03-15 11:10:46 UTC
so it seems the border lines are painted first, then the "subsidiary lines"
are painted over them, which somehow used to work but now doesn't;
i.e. i get visible border lines on master by commenting out these lines:

            // collect sub-lines
            pPage->RefreshSubsidiary( aPaintRect );
            // paint special sub-lines
            pSpecSubsLines->PaintSubsidiary( pSh->GetOut(), NULL );
Comment 12 Michael Stahl (allotropia) 2012-03-16 07:53:26 UTC
the problem is apparently that the drawing of the border lines used to be
delayed, but now is done immediately; the vertical borders were visible
because apparently they are drawn 1 pixel to the right of the subsidiary line,
so they were not overdrawn.

so i've pushed a tentative fix for this now that delays drawing the border
lines until after the subsidiary lines are drawn, so the borders
paint over the subsidiary lines, which seems to work for the bugdoc
here and the one from bug 38542.
Comment 13 Not Assigned 2012-03-16 07:55:14 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=804d0a896731629397c5328c13c04a45bc55f459

fdo#42750: delay painting borders until after subsidiary lines
Comment 14 Greg Madden 2012-03-16 10:50:58 UTC
(In reply to comment #13)
> Michael Stahl committed a patch related to this issue.
> It has been pushed to "master":
> 

Cool, looking forward to testing this.

FYI, since I have been looking into this table border line style stuff, I realize that my double borders have changed even before the 3.4.x issues started. Debian stable has OO v. 3.2.1, which is  Go-Office as I understand things. 

The double line borders choices since 3.2.1 all contain 'dropped shadow?' styles, no double lines with just equal weight. Not sure when the line styles started changing, when I first created my templates years ago the double lines were of equal weight with a certain spacing. 

I only no noticed  this by using AOO dev 3.4 wich displays line styles as originally created, also the line style selector tool contains the double line style I use as a choice, lots of changes it seems in ver of LO.

Thanks for working on this

Greg
Comment 15 Not Assigned 2012-03-20 04:19:05 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c7524ab32f801910673da5c9c68669ada7c98769&g=libreoffice-3-5

fdo#42750: delay painting borders until after subsidiary lines


It will be available in LibreOffice 3.5.2.
Comment 16 Not Assigned 2012-03-23 07:44:18 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

fdo#42750 fdo#45562 fdo#47717: border paint ordering:
Comment 17 Rainer Bielefeld Retired 2012-03-24 08:42:07 UTC
@Michael:
Fix is in 3.5, 3.6, there will be no 3.4.7, so we can close this one?
Comment 18 Not Assigned 2012-03-27 01:10:35 UTC
Petr Mladek committed a patch related to this issue.
It has been pushed to "libreoffice-3-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=47ef805d8ab2f2a41be058ab5f7e0fe061ffe7a0&g=libreoffice-3-5-2

Revert "fdo#42750: delay painting borders until after subsidiary lines"


It will be available already in LibreOffice 3.5.2.
Comment 19 Michael Stahl (allotropia) 2012-04-03 10:13:56 UTC
the fix for this introduced bug 47717, which i've got a fix for,
but then Cedric found another problem while i was on vacation,
and the fix was reverted on the libreoffice-3-5-2 branch.
so this will require some more investigation...
Comment 20 Not Assigned 2012-04-20 06:20:24 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9aacf868fa0dbbbfc6e06ae16042a3ec34991843&g=libreoffice-3-5

fdo#42750 fdo#45562 fdo#47717: border paint ordering:


It will be available in LibreOffice 3.5.4.
Comment 21 Not Assigned 2012-04-24 04:44:28 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-3-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a34e28c9f80542bb8c0b120421f7a02832ad038&g=libreoffice-3-5-3

fdo#42750 fdo#45562 fdo#47717: border paint ordering:


It will be available already in LibreOffice 3.5.3.
Comment 22 Michael Stahl (allotropia) 2012-04-26 07:50:40 UTC
finally fixed in 3.5.3 now.

filed bug 48647 for the other problem with the bugdoc,
the ugly hairline border corners that are not clipped properly.
Comment 23 Michael Stahl (allotropia) 2012-05-11 13:55:45 UTC
*** Bug 47966 has been marked as a duplicate of this bug. ***