|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Selection background in writer not visible when transparent graphics in view area | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | gsl | Reporter: | andreschnabel <andre.schnabel> | ||||||||||
| Component: | code | Assignee: | stefan.baltzer | ||||||||||
| Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> | ||||||||||
| Severity: | Trivial | ||||||||||||
| Priority: | P3 | CC: | Armin.Le.Grand, eric.savary, hdu, issues, jr, mechtilde, stefan.baltzer, uwefis, wolframgarten | ||||||||||
| Version: | DEV300m60 | Keywords: | accessibility, oooqa, regression | ||||||||||
| Target Milestone: | OOo 3.2 | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Unix, all | ||||||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||||
| Developer Difficulty: | --- | ||||||||||||
| Issue Depends on: | |||||||||||||
| Issue Blocks: | 99999 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
andreschnabel
2009-10-13 20:20:45 UTC
Created attachment 65348 [details]
brocken selection background
Created attachment 65349 [details]
selection background ok
reassigned Looks like a follow-up to issue 88893 AW->OD: Looked in a OOO320 m1 and there seem to be more than this problem. Help is a SW AFAIK, maybe repaint is not adapted for Pre/postPaint at all? Please have a look, i have no idea about help and it's usage of SW. The Help uses the Writer in online view with read-only document. Nothing special here - the same paint routines are used as in the "standard" Writer. I can not reproduce the described defect under Windows 2003 with OOO320m1, OOO320m2, DEV300m60 and DEV300m61. The paint routines in the Writer code are not platform-dependent. Thus, I do not expect that the Writer code is responsible for this defect. OD->SBA, AW: Please further evaluate this problem? On which platforms does the defect occurs? Since which version does the defect occurs? Does the defect also occurs in Writer in online view with similar documents? tried with writer (will attach an example) - and I'm able to reproduce thesame problem. I even happens in print view, edit mode. But I need to zoom the document with an active selection. change sumary, setting accesibility keyword Created attachment 65517 [details]
select some text, then zoom the view
Created attachment 65518 [details]
same example with embedded graphic
I guess you would need a stand-alone Linux box to see this bug. I only have stand-alone Windows PCs and virtual Linux and Solaris displays with very limited graphics capabilities (Graphics Output and Transparency settings on Options-View tab page are grayed out). We don't know which Linux and whether some graphics gimmicks were used by OP. my configuration is: A) kubuntu 9.04 32bit, KDE 4.3, local display, current Xorg X-server, ATI graphics B) RedHat enterprise 3 32bit, KDE 3.5.1, remote display, cygwin XServer on Windows I think, I found what triggers the problem: You need to have a graphic with transparency in the visibla area then the problem occures. Graphics without transparencies are ok. I can reproduce it on my eeepc with the latest attached document. Confirmed on Ubuntu Karmic / OOO320m2. When a help page contains graphics we only have the frame around the selection, in writer the selection is lost upon each focus change. The problem did not exist in OOo3.1.1. A machine for reproduction is available. SBA->AW: Please proceed, thx. This is reproducible on Suse 10.1 and OpenSuse 11, too. This is broken since DEV300_m50 at least (could not find older builds). A variation (maybe help to circle this in): - Open second bugdoc (with embedded graphic) - Unmaximize the application window if needed - Select the first paragraph - Shrink and enlarge the window size so that the graphic gets out of view and back again -> When the graphic is within the view area, the selection background vanishes -> When the graphic is out of the view area, the selection background comes back Note that shrinking the view within the online help brings the same effect. I adjusted the summary to meet the findings. AW->HDU: Checked down to X11SalGraphics::drawAlphaBitmap where the transparent part is visualized using a BitmapEx (checked content, it's correct) which gets painted. Returning false here makes it work, so it happens here somehow. I could reproduce running remote on v60x-so16 and using XMing as XServer. To reproduce: Start SW, type 'dt' + F3 (text expansion), select all (CTRL-A). Hold CTRL, use muse wheel to zoom out (not in), On smallest zoom (page evry small top-left), play with the last 2-3 zoom steps. The visualisation will start to not paint transprency left and top, looks like clipped. In that state, You can use CTRL+SHIFT+R for repaints which will keep the error. Has nothing to do with transparent graphics, but maybe with SW and various XRender implementations. Please have a look. Recycled render pictures need to have their clip regions reset... Fixed in CWS ooo32gsl04. @sba: please verify in CWS ooo32gsl04 Testing hint: test scenarios with clipped antialiased graphics on X11 platforms which support the render extension Verified in CWS ooo32gsl04. verified in OOO320_m6 -> closed *** Issue 105843 has been marked as a duplicate of this issue. *** |