Issue 83388 - Parent frame with no border causes child frame transparency to go to 100%
Summary: Parent frame with no border causes child frame transparency to go to 100%
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.3
Hardware: All Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-11-06 19:13 UTC by crxssi
Modified: 2013-02-07 21:49 UTC (History)
6 users (show)

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

OO Writer document that will not print properly under OO 2.3 but does print properly under 2.1 (167.73 KB, application/vnd.oasis.opendocument.text)
2007-11-06 19:16 UTC, crxssi
no flags Details
test document, printed from 2.1.0, correct output (2.53 MB, application/postscript)
2008-01-24 15:02 UTC, crxssi
no flags Details
test document, printed from 2.2.0, incorrect output (2.72 MB, application/postscript)
2008-01-24 15:03 UTC, crxssi
no flags Details
test document, printed from 2.3.0, incorrect output (2.72 MB, application/postscript)
2008-01-24 15:04 UTC, crxssi
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description crxssi 2007-11-06 19:13:58 UTC
In OO 2.3 there is a new problem that did NOT occur in 2.1:

How to reproduce:  If you create an OO Writer document, insert a frame, set a
background bitmap image to "area", anchor to page.  Make that frame rather
large.  Then go inside that frame and insert another frame, anchored to
paragraph, set a white background, then set transparency to, perhaps 25%.  Then
type some text in the frame.  Now print the document.  In both 2.1 & 2.3 it will
print properly- you will see about a 25% transparency in the top/white frame.

Now turn off the border on the parent frame that has a background bitmap set and
print the document.  In 2.1 it will print properly.  In 2.3 the top/white frame
will suddenly change to 100% transparency.  It will look OK on the screen or in
a PDF you create from 2.3, but it will not print properly.

I have repeated the test many times, to several printers, as several users. 
This is a fairly severe problem for us, because our company newsletter uses
partial transparent frames like this.  It took me MANY hours of troubleshooting
the documents to finally narrow down this problem so I could find what causes it
and so I could report it.  Users not knowing this information might go crazy
trying to figure out what is broken.

Workaround:  Our only work around has been to turn on a border on the lowest
frame, making it the same color as the paper (white) and with no spacing.  This
workaround is successful on some documents, but not others.

I will attach a sample document to this issue so it can be tried on other
platforms and other OO versions by testers so the root cause can be corrected. 
I would be happy to attach additional documents as needed- more samples, scans
of the prints, postscript of the prints, etc.
Comment 1 crxssi 2007-11-06 19:16:08 UTC
Created attachment 49477 [details]
OO Writer document that will not print properly under OO 2.3 but does print properly under 2.1
Comment 2 michael.ruess 2007-11-08 10:23:21 UTC
MRU->HI: on WinXP it prints fine with OO 2.3 and OO 2.4 dev build 680m236.
Please have a look, if this is different on Linux.
Comment 3 h.ilter 2008-01-18 13:46:23 UTC
Could not reproduce. Please have a look.
Comment 4 kpalagin 2008-01-18 20:05:07 UTC
Confirming with 2.3,0 (Fedora's) on Fedora 8 - as described.
Outputting to .ps shows the problem.
Comment 5 philipp.lohmann 2008-01-21 13:00:20 UTC
pl->od: is this aduplicate to issue 80316 ?
Comment 6 crxssi 2008-01-21 14:43:13 UTC
It is not the same issue at all.  And, I don't even think issue 80316 is valid-
his child frame is clearly marked to wrap "in background", and that is exactly
what OO does.
Comment 7 Oliver-Rainer Wittmann 2008-01-24 08:29:51 UTC
I can confirm, that this issue has nothing to do with issue 80316.

I can not reproduce the problem under the operating system, that are available
to me (WIndows 2003 Server, Solaris - SunRay, Linux - SUSE)
OD->PL: Do you reproduced the defect?

I seems to be system depend defect - the printing routines in Writer does not
contain system-dependent code.

As stated in the given bugdoc, the created PDF looks good, but when it is
printed it fails. Thus, it seems that the printing system of the used system is
not used correct or itself has problems.

OD->PL: Please take back for further investigations.
Comment 8 crxssi 2008-01-24 15:00:15 UTC
I have new information.  The problem also occurs under OpenOffice 2.2.0 under
Linux.  I will attached three postscript outputs for the sample test document
that I first attached.  It is the output of each for 2.1.0, 2.2.0, and 2.3.0.

I would be happy to install additional older OpenOffices if we need to narrow
down exactly when it started between 2.1.0 and 2.2.0.  I would also welcome
someone to send me their generated postscript of the test document from 2.3.0
and I will print it here and see if it comes out correctly or not.

od: I am not sure how the Linux printing system could be the cause of the issue,
unless there is something inherently different between the postscript that 2.1.0
generates and that of 2.2.0.  Hopefully the new attachments would assist someone
that is fluent in postscript to notice the difference.

Also of importance is to note that this is not the only problem we are having
with printing documents with transparencies in newer OpenOffices...  I have some
other examples, too.  But I don't want to complicate the bug reporting yet,
unless there is a need for more information.
Comment 9 crxssi 2008-01-24 15:02:17 UTC
Created attachment 51138 [details]
test document, printed from 2.1.0, correct output
Comment 10 crxssi 2008-01-24 15:03:45 UTC
Created attachment 51139 [details]
test document, printed from 2.2.0, incorrect output
Comment 11 crxssi 2008-01-24 15:04:52 UTC
Created attachment 51140 [details]
test document, printed from 2.3.0, incorrect output
Comment 12 philipp.lohmann 2008-01-25 11:09:23 UTC
Comment 13 Mathias_Bauer 2008-04-21 16:12:31 UTC
changed component
Comment 14 philipp.lohmann 2008-05-27 12:26:58 UTC
The mentioned workaround doesn't work for me either.

pl->thb: since you are currently working on the transparent printing, would you
mind having a go at this problem, too ?
Comment 15 thb 2008-05-27 12:47:03 UTC
Grabbing issue
Comment 16 philipp.lohmann 2008-05-27 13:45:48 UTC
thanks for looking into this.
Comment 17 thb 2008-06-10 00:37:53 UTC
Hm. A bit weird. Linux-only, and setting SAL_DISABLE_NATIVE_ALPHA=TRUE cures the
problem - Xrender cook-up?
Comment 18 thb 2008-06-10 11:05:35 UTC
Indeed. Also limiting the FillRectangle params to the vdev size does not help.
@pl: any clue, short of disabling drawAlphaRect for vdevs?
Comment 19 philipp.lohmann 2008-06-11 21:23:31 UTC
@thb: not immediately. Since drawAlphaRect on RENDER is involved perhaps hdu
might have an idea.
Comment 20 thb 2008-06-23 10:55:49 UTC
Ok - time for 3.0 is almost over, and nobody seems to have an idea on how to
work-around this (assumed) xrender bug. Retargetting to 3.1, whoever needs a
workaround, please set SAL_DISABLE_NATIVE_ALPHA=TRUE in your environment before
starting OOo
Comment 21 crxssi 2008-06-23 14:48:28 UTC
I have not tested this thoroughly, but it appears that
SAL_DISABLE_NATIVE_ALPHA=TRUE does, indeed fix the problem on my system (Linux
00 2.3.0).  This is the first time I have been able to properly print pages with
transparent frames since 2.1.0.  This makes me very happy, even though it really
isn't "fixed".

So, the questions is, what are the side effects, negatives, or consequences of
setting SAL_DISABLE_NATIVE_ALPHA=TRUE ?  Is it going to create other issues that
I am not aware of yet?  What exactly is the purpose of "Native Alpha"?  doesn't say
anything useful.

Comment 22 thb 2008-06-23 15:14:24 UTC
@crxssi: this disables use of XRender extension for things like semi-transparent
selection areas in Calc, or for rendering transparent bitmaps. Depending on your
setup & display (remote, screen size, quality of the Xserver implementation of
XRender), you will notice a reduction in rendering speed.
Comment 23 crxssi 2008-06-23 18:49:39 UTC
thb:  Thanks for the info.  I have been using writer with
SAL_DISABLE_NATIVE_ALPHA=TRUE much of the day now.  I can't say I notice any
difference in rendering speed yet... which is a good thing.  (We use Linux based
thin clients displaying OO 2.3.0 from a central Linux server at 100Mb/s).

I wish there were a way I could help more on a real fix, but I am not a
programmer.  However, if you need any additional testing or sample files, etc,
let me know.

I still think there is a design flaw in OO if it is using the Xserver to render
(in any way) for PRINTING purposes (I know it is, because when I print a huge
newsletter, it creates insane network activity to the local thin desktop and
almost freezes everything- sometimes for minutes).
Comment 24 thb 2008-06-23 19:54:16 UTC
@crxssi: hm, FWICT, the fix needs at least a fair amount of spelunking in X
server code - what might help is a stripped-down version of the code,
preferrably in a plain c file, that exhibits the error against the X server. I'm
just currently totally out-of-time for 3.0 (which has code freeze next week).

Regarding the internal mechanics of printing - well, the rendering has to happen
because PS does not support transparencies at all, so stuff has to be emulated
via giant bitmaps. And although OOo now has a software renderer, the initial
design did not, so the only entity that could render in X11 OOo was - the
Xserver. Unfortunate in your specific case, and fixable in principle - but why
not disabling PS printing altogether on your clients (at your discretion, only
for OOo), and do PDF export instead? Printing those only generates load on the
one dedicated print server...
Comment 25 thb 2009-01-07 17:20:48 UTC
I'm swamped for 3.1 again;

@pl: what was the schedule for pdf printing again, that would clearly alleviate
this problem?
Comment 26 philipp.lohmann 2009-01-07 18:21:11 UTC
"The schedule for PDF printing" needs definition. I assume you are aiming at the
general move from PostScript to PDF as CUPS primary spool file format ? In that
case the schedule for that regarding OOo is "in the fullness of time" (the usual
reason, missing manpower).

Also, even when we have that migration we still need the PostScript path for a
while for older CUPS versions and/or cupsless systems. One could argue though
that even those systems would be able to grok PDF files so we might get away
with PDF output only.
Comment 27 thb 2012-07-13 20:51:31 UTC
Reset to default assignee.