|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | print preview shows control elements with property printable=false | ||
|---|---|---|---|
| Product: | Base | Reporter: | Oliver Brinzing <oliver.brinzing> |
| Component: | code | Assignee: | marc.neumann |
| Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | Armin.Le.Grand, issues |
| Version: | OOo 3.1 | Keywords: | regression |
| Target Milestone: | OOo 3.1.1 | ||
| Hardware: | Unknown | ||
| OS: | All | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
| Issue Depends on: | |||
| Issue Blocks: | 101565 | ||
|
Description
Oliver Brinzing
2009-05-20 10:30:21 UTC
confirmed with DEV300m49 - setting to database access Yet another regression of the drawing layer's refactoring to use drawing primitives :( fs->aw: Obviously, the UnoControlPrintOrPreviewContact in viewobjectcontactofunocontrol.cxx, which formerly used to handle this, is a dummy nowadays (it does nothing special anymore since the move of the code to Drawing Primitives). For the page preview, as well as for a normal document view, a VclPixelProcessor2D is used, which is completely agnostic of the Printable property. So, where's the best place to hook into? I could imagine resurrecting the UnoControlPrintOrPreviewContact, and overloading its createPrimitive2DSequence method to return an empty sequence in case the Printable property is FALSE. This seems the most natural choice to me, but I'd appreciate your opinion as the architect of the Drawing Primitives infrastructure. aw->fs: This would bring no advantages since in the VOC there is also no hint that the view is a print preview. Someone is making new print and print dialog concepts in the last time who investigated not the slightest thoughts about OutputDevice::GetOutDevType() == OUTDEV_PRINTER usages throughout the office at all :-( So, to solve it at the VOC it would also be necessary to make it known there, e.g. at the OC where already methods like 'isOutputToPrinter()' exist, but also rely on the OutDev BEING a printer to return true. What is wanted is more something like 'behave like a printer, but let's get rid of OutDevPrinter'. Despite that it's probably a good idea to get rid of PrinterOutputDevices, as said, the concept maker seem to have not thought about consequences. There is no easy way at all except to continue using printer devices for print preview, but from what is wanted it would be better to teach a pixel primitive renderer to 'behave' like a printer, i think. Who is doing such changes, why and how...? fixed in CWS dba311a find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba311a fs->msc: please verify in CWS dba311a verified in CWS dba311a find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba311a checked w/OOO310m_16, Ubuntu 9.04 Checked with both odt and embedded Base form. Closing |