Apache OpenOffice (AOO) Bugzilla – Issue 83388
Parent frame with no border causes child frame transparency to go to 100%
Last modified: 2013-02-07 21:49:27 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.
Created attachment 49477 [details] OO Writer document that will not print properly under OO 2.3 but does print properly under 2.1
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.
Could not reproduce. Please have a look.
Confirming with 2.3,0 (Fedora's) on Fedora 8 - as described. Outputting to .ps shows the problem.
pl->od: is this aduplicate to issue 80316 ?
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.
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.
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.
Created attachment 51138 [details] test document, printed from 2.1.0, correct output
Created attachment 51139 [details] test document, printed from 2.2.0, incorrect output
Created attachment 51140 [details] test document, printed from 2.3.0, incorrect output
target
changed component
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 ?
Grabbing issue
thanks for looking into this.
Hm. A bit weird. Linux-only, and setting SAL_DISABLE_NATIVE_ALPHA=TRUE cures the problem - Xrender cook-up?
Indeed. Also limiting the FillRectangle params to the vdev size does not help. @pl: any clue, short of disabling drawAlphaRect for vdevs?
@thb: not immediately. Since drawAlphaRect on RENDER is involved perhaps hdu might have an idea.
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
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"? http://wiki.services.openoffice.org/wiki/Environment_Variables doesn't say anything useful. Thanks!
@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.
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).
@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...
I'm swamped for 3.1 again; @pl: what was the schedule for pdf printing again, that would clearly alleviate this problem?
"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.
Reset to default assignee.