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
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
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.
Updated my testing to include v 3.5.0 RC2. I would test the fixes if there was a build available.
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
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.
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 ?
(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.
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?
argh, how does the version always manage to change itself...
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.
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 );
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.
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
(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
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.
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:
@Michael: Fix is in 3.5, 3.6, there will be no 3.4.7, so we can close this one?
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.
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...
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.
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.
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.
*** Bug 47966 has been marked as a duplicate of this bug. ***