Issue 20209

initial state defaults to new, sorry..

Remember this when implementing the feature:

If you select BLACK and then 100% transparent, the text in the frame 
goes white.

Reassigned to BH

*** Issue 21236 has been marked as a duplicate of this issue. ***

I don't think this is an enhancement; this is a bug.

*** Issue 26094 has been marked as a duplicate of this issue. ***

I haven't noticed this issue in 1.1.4 but I have certainly noticed it in 2.0 
Beta! It annoyed me so much, I went back to 1.1.4 for the time being! I use a 
dark GTK+ and Qt color scheme. For me, OO always defaults to showing the page as 
dark blue instead of white, which I suppose is understandable when you consider 
people who use dark color schemes for accessibility reasons. I can manually set 
the page to white so that's okay. In 1.1.4, this is fine but in 2.0 Beta, any 
frames (both old ones from a 1.1.4 document and newly created ones) have a dark 
blue background, which obviously looks terrible! I agree they should have 100% 
transparency, or at the very least, should use the same color as the page 
itself. Note that in my case, this is purely to do with how the frame is 
*displayed* on the screen in edit mode. When doing Page Preview, it looks 
normal. I'm not sure if that was the case for these other people.

> I haven't noticed this issue in 1.1.4

No wonder, OOo 1.1.4 does not support transparency.

You problem is not related to this issue. As you said: Your issue is a
display-issue. 

Huh? What was all this about if it doesn't support transparency then? And how 
come I can draw shapes and make them transparent? I am also able to make frames 
transparent by using the method described above.

I'm not so sure that my issue is so different from the one originally stated 
here. In OOo 1.1.4, "no fill" seems to use the page color in both edit mode and 
page preview mode. In OOo 2.0 Beta, "no fill" seems to use default page color 
even if it has been overridden but this only happens in edit mode. In page 
preview mode, it uses the overridden page color as before. But in all these 
cases, "no fill" should simply make the background transparent as was stated in 
the original problem. Selecting a color and 100% transparency does give the 
desired effect in all cases but I agree, this is not intuitive at all.

Sorry, forget about my comment, I was thinking of different things...
But still your issue is different, since:

> In OOo 2.0 Beta, "no fill" seems to use default page color 
> even if it has been overridden but this only happens in edit mode

Is not the case on my system. It uses the background color set in the options...
Sure, making "no fill" transparent would solve your problem as well, but still
these issues have a different cause.

Okay but aren't you being a little pedantic? Does it really matter if the causes 
are different when the solution is the same? It doesn't seem worth filing 
another bug report for. Seeing as having "no fill" to mean 100% seems like the 
intuitive option regardless of any of this, can I expect to see this changed or 
am I going to have to go wading through OOo's source code myself? It'd probably 
take me a day to even find the relevant code in the first place.

No.

This bug is about "no fill" not being equal to "100% transparency". In other
words it affects printing and PDF generation. This is not a display problem at
all (even though a display problem would result as a side effect). These are
completely different problems.

"It is the same bug" means that it is not a display problem but rather a
printing/PDF problem that happens to have an effect on the display.

As much as I hate OOo's bug reporting process (such as they close bugs
unreasonably hastily and not allow you to reopen them even if you are the
reporter), the new "wrong background colour" bug does sound like a different,
unrelated bug.

Okay this is going to make me look really stupid. I recently finished my really 
important assignment so I went back to 2.0 Beta and tried this stuff out again.
.. and I can't reproduce the problem I had. I don't know what the hell happened 
last time. I did restart OOo several times with different settings to see what 
worked but nothing did. Now it works fine. Eh? Oh well. Just get the "no fill" 
thing sorted!

Perhaps this issue is not only a problem of beeing not intuitive. How works the 
PDF creation process for PDF? Is the transparent feature used for "100 % 
transparency"? Some printerings (of these i work with) can't work with 
transparency in PDF. (They like to have PDF 1.3, but when I deliver them PDF 
1.4 from OOo, it's mostly accepted if no transparency is used.)

Implementing "no fill"="100 % transparency", it would be a good idea to NOT use 
the transparency feature for PDF export for this special case (and maybe the 
same for printing).

I assume the "transparency feature" you talk about is "PDF transparency"? but
"100% transparency" is very different from any other kind of transparency
(except "0% transparency").

Keep in mind that the bug only concerns the background of frames, etc.

With the current behaviour, when you specify transparency to be "no fill", OOo
paints a white rectangle, then draws the contents of the frame. Why should OOo
paint a white rectangle first? This is the part that's unintuitive; it's wrong
and unnecessary. It's wrong because "no fill" means "no fill", not "white fill";
it's unnecessary because of the next point.

With "100% transparent", OOo just draws the contents of the frame. This already
works perfectly; it is 100% Postscript compatible and should not cause any
problems in any kind of output device. This is the intuitive (truthful)
behaviour and OOo currently handles it 100% correctly.

With any other kind of transparency (1% to 99%), OOo produces PDF files with PDF
transparency (which is not supported by all PDF readers, in particular it's not
supported by Ghostscript), but produces bitmaps when printing to Postscript
(i.e., computes the whole page as a bitmap, then sends the whole bitmap to the
Postscript device), making the output very unsuitable for almost any purpose.
(This is unsuitable even for printing because the output will tend to be of
lower quality than usual.) It's the 1% to 99% transparent frames that cause
problems, and this bug is not concerned with such kinds of transparencies at all.

In summary, this bug says

1. "no fill means no fill, not white fill" and

2. "OOo already handles 100% transparent correctly, and the expected behaviour
of no fill is the existing behaviour of 100% transparent";

3. therefore, OOo should treat "no fill" as "100% transparent".

As far as I can tell, OOo is the only program I have ever seen that has this
strange behaviour of "none" not equaling to "100 transparent". (Note: Most
programs can only handle either 0% transparent and 100% transparent. Both as
easy to handle, as explained above.)

To complete that:

* The current behaviour should be renamed to "automatic color" and 
* a new choice labled "no fill" (that will be equal to choosing a color and 
  100% transparency) should be introduced.

Regarding PDF-Export and transparency: see issue 19696

remember: every problem in a seperate issue

*** Issue 54595 has been marked as a duplicate of this issue. ***

this problem is still there in openoffice 2.0.2. a colleague and i were
convinced it was a bug in openoffice until i found this bug and finally understood.
we saw the transparency %tage option but didn't even try it, we said "no, come
on, it can't be that, 'no fill' is so clear wording"...

well it was that. i think this should be fixed, most people will think that
openoffice is buggy or doesn't support the feature.

by the way, changing "no fill" text to "not set" or "default", or "automatic
color" as was suggested in this discussion is enough to fix the problem!
it's really nothing more than that...

http://qa.openoffice.org/issues/show_bug.cgi?id=53771

Created attachment 47121 [details]
An example of this bug