Issue 71056 - tab fill in text box has wrong background color
Summary: tab fill in text box has wrong background color
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: OOo 2.0.4
Hardware: All Linux, all
: P3 Trivial with 8 votes (vote)
Target Milestone: 4.2.0
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2006-10-31 23:26 UTC by Joe Smith
Modified: 2017-05-20 10:35 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.0-dev
Developer Difficulty: ---


Attachments
Document with screenshots demonstrating problem (52.95 KB, application/vnd.oasis.opendocument.graphics)
2006-10-31 23:27 UTC, Joe Smith
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Joe Smith 2006-10-31 23:26:54 UTC
Text paragraphs in text box objects may have tab stops and fill styles set. When
a tab fill is specified, the tab space is rendered with a white background
color, no matter what color is specified for the text box area fill. Tab spaces
with no fill are shown correctly, with no change in the area fill color.

The same effect happens for colored objects which are behind the text box: the
tab fill is rendered with a white background, obscuring any objects underneath.

Steps to reproduce:
1) File > New > Drawing
2) Create a text box ("T" toolbar icon)
3) Enter text: A<tab>B<tab>C
4) Format > Paragraph
5) Create two tab stops (e.g. 2cm, 5cm)
6) Change the tab fill style for one tab to ".........."
7) Select the text box; change the area fill to color, default (anything but white)
8) See that the unfilled allows the area fill color to show, while the filled
tab has white space where the fill characters are shown.

This problem is evident in  Writer text boxes as well.

The problem occurs in at least OOo 2.0.2 and 2.0.4.
Comment 1 Joe Smith 2006-10-31 23:27:50 UTC
Created attachment 40203 [details]
Document with screenshots demonstrating problem
Comment 2 Joe Smith 2006-10-31 23:29:38 UTC
Note that there is evident in the attached document a separate problem with the
tab fill character spacing, already submitted as a separate issue: Issue 71055
Comment 3 wolframgarten 2006-11-01 07:31:37 UTC
Reassigned.
Comment 4 christian.guenther 2006-11-01 17:21:14 UTC
Set to new and change the target.
Comment 5 christian.guenther 2006-11-01 17:22:18 UTC
I can reproduce the bug.
Please have a look.
Comment 6 tompouce 2007-03-01 09:02:09 UTC
Please have a look on this bug. Is it possible to target the issue?

This white background for tab shape is very bad for my work.

Hope this is simple to fix it.
Comment 7 clippka 2007-03-01 10:54:19 UTC
This really looks weird and simple to fix

cl->tl: Any reason why we paint those dots with a white background?
Comment 8 thomas.lange 2007-12-03 15:23:51 UTC
.
Comment 9 thomas.lange 2008-01-14 14:02:40 UTC
No more issues accepted for OOo 2.4 unless there are serious problems.
Comment 10 lars.nooden 2008-02-07 15:28:19 UTC
This is present in OOo 2.3.1-3ubuntu3 Impress for x86 Kubuntu

When setting a fill for the tabs, a background color is given instead of
remaining transparent.  

Steps:
Format->Paragraph->Tabs->Fill character->.....

Comment 11 Joe Smith 2013-09-12 21:12:24 UTC
Testing AOO 4.0 on Fedora Linux 17.

The original problem is not present but there is a slightly different problem relating to tabbed text: the leader is visible ONLY when the paragraph is in editing mode. Once the text edit mode is finished, the tab leader disappears.
Comment 12 Joe Smith 2014-04-17 21:25:46 UTC
Testing with AOO 4.1beta: Tab fill characters do not appear at all, either in editing view, print preview (print dialog), or pdf export.
Comment 13 mroe 2014-04-18 12:22:20 UTC
Setting keyword regression due to comment 11 and comment 12.
Comment 14 Armin Le Grand 2014-04-22 15:35:52 UTC
Indeed a regression, a surprisingly old one. This must have been broken when I changed the text rendering to primitives, years ago (this is frightening a little bit by itself). The missing part is that the layouting in the EditEngine does not create the needed primitives in the primitive creation mode. In edit mode (EditEngine is in paint mode) the needed content is created and painted.
It would be possible to add a specialized primitive here that holds the fill space, fill character and font info and which decomposes to the needed char sequence, but for now I will just use what we have and directly create the needed string and data. Additionally a DXArray creation is needed to make the fill chars a stretch text.
The white background is not really 'white' but the system's default DocumentBackgroundColor (set on my machine different from white to see stuff like that). In edit mode this is shown by purpose (AFAICT). With the added code for primitives the correct stuff is created, with all the attributes from the text (overline, underline, strikethrough, ...).
Checked, preparing commit...
Comment 15 SVN Robot 2014-04-22 15:36:36 UTC
"alg" committed SVN revision 1589174 into trunk:
i71056 also create TabSpace's fill characters if used
Comment 16 Armin Le Grand 2014-04-22 15:36:57 UTC
Okay, done.