Bug 31856 - VIEWING: Wrong table border color for OOo document
Summary: VIEWING: Wrong table border color for OOo document
Status: CLOSED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.3.0 Beta3
Hardware: All All
: medium minor
Assignee: Cédric Bosdonnat
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2010-11-23 01:49 UTC by Rainer Bielefeld Retired
Modified: 2012-05-07 09:51 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Test kit with sample document and screenshots (104.06 KB, application/x-compressed)
2010-11-23 01:49 UTC, Rainer Bielefeld Retired
Details
sample odt, screenshot of problem (181.32 KB, application/x-zip-compressed)
2011-10-13 06:25 UTC, Michael Chudobiak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2010-11-23 01:49:13 UTC
Created attachment 40497 [details]
Test kit with sample document and screenshots

My "LibreOffice 3.3.0Beta3 - WIN XP DE [OOO330m9 (build 3.2.99.3)]" shows particular table border with wrong color "red" instead of black.

Steps to reproduce:
1. Open sample.odt" (created with OOo 3.x) from test kit
   Expected: Bottom border should be black
   Actual: Bottom border should is red

Please also see screenshots.

Problem not visible with OOo 3.4-Dev
Comment 1 Guy Voets 2011-03-12 01:24:42 UTC
I confirm that on screen the bottom line is red, while the table border dialog box pretends the line is black.
However, when I ask for a print preview, the line is black indeed. I didn't try to print, as I have a b/w printer.

This is LibO 3.3.1 330m19 (Build:8) tag 3.3.1.2 (dutch language pack)on an Intel iMac, OSX 10.6.6 (Snow Leopard)
Comment 2 Rainer Bielefeld Retired 2011-03-12 01:49:07 UTC
I still see that  with "LibreOffice 3.3.1  – WIN7  Home Premium  (64bit) English UI [OOO330m19 (build 8 / tag 3.3.1.2)]", also with documents I created with OOo, but in between I intensively edited with LibO

Minor problem, because it seems to be without influence to output (print, PDF)

MY Graphic Card: NVIDIA GeForce GT 430

@Guy Voets:
Thank you for confirmation and additional information
Comment 3 Steve Edmonds 2011-03-16 22:44:17 UTC
With LibreOffice 3.3.0, OOO330m19 (Build:6), tag libreoffice-3.3.0.4
I see this issue.

Seems related to a line at the bottom. If you make the line elsewhere (top, all around) it workds ok.
Also seems like the bottom line goes global (so to speak).
If you make another table and make the line green all around the bottom line of other cells in this and other tables with a line set also go green.
Comment 4 Luc Novales 2011-03-17 02:57:06 UTC
Confirmed on Debian Squeeze/64 with LibreOffice 3.3.1, OOO330m19 (Build:8), tag libreoffice-3.3.1.2 (French Language)
Comment 5 Rainer Bielefeld Retired 2011-03-17 04:04:11 UTC
@Cédric:
We have several confirmations, may be you can have a look?
Comment 6 Michael Chudobiak 2011-10-13 06:25:13 UTC
Created attachment 52290 [details]
sample odt, screenshot of problem

This problem is causing me a lot of grief.

I have attached a zip file with a sample document, which has a table on the second page. The table is supposed to have a black border. However, parts of this border are sometimes rendered as blue - see the screenshot in the zip file.

Also, export-as-pdf renders this border as blue in the PDF.

- Mike
Comment 7 Michael Stahl (allotropia) 2012-03-24 13:42:43 UTC
this is the most surprising borderline regression:
i can not reproduce it in LO 3.4.3, but can in
my LO 3.4.6 build with reverted 0f0896c26fb260d1bbf31d7a886df3f61837f0f2,
so it looks like this is actually fixed by that commit!

Rainer please check that it's really fixed and close.
Comment 8 Michael Stahl (allotropia) 2012-05-02 03:16:56 UTC
resolving this as WORKSFORME
Comment 9 Rainer Bielefeld Retired 2012-05-02 03:48:39 UTC
@Michael
H have not seen that for a very long time, thank you for closing.
Comment 10 Roman Eisele 2012-05-07 09:51:11 UTC
This is (at least at the surface) a Writer issue, therefore changed the 'Component' field accordingly.