Issue 83388

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.