Issue 102089 - print preview shows control elements with property printable=false
Summary: print preview shows control elements with property printable=false
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 3.1
Hardware: Unknown All
: P3 Trivial (vote)
Target Milestone: OOo 3.1.1
Assignee: marc.neumann
QA Contact: issues@dba
Keywords: regression
Depends on:
Blocks: 101565
  Show dependency tree
Reported: 2009-05-20 10:30 UTC by Oliver Brinzing
Modified: 2009-07-23 19:21 UTC (History)
2 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description Oliver Brinzing 2009-05-20 10:30:21 UTC
oo 3.1 shows control elements (for example a pushbutton) with property
printable=false in print preview but does not print it.
so print preview is different from print result.
so 7 for example does not show controls with printable=false
Comment 1 Oliver Brinzing 2009-06-06 10:41:29 UTC
confirmed with DEV300m49 - setting to database access
Comment 2 Frank Schönheit 2009-06-08 13:27:26 UTC
Yet another regression of the drawing layer's refactoring to use drawing
primitives :(
Comment 3 Frank Schönheit 2009-06-08 14:33:03 UTC
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.
Comment 4 Armin Le Grand 2009-06-08 15:27:54 UTC
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
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...?
Comment 5 Frank Schönheit 2009-06-10 13:39:55 UTC
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:
Comment 6 Frank Schönheit 2009-06-24 10:30:33 UTC
fs->msc: please verify in CWS dba311a
Comment 7 marc.neumann 2009-07-01 09:55:56 UTC
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:
Comment 8 drewjensen.inbox 2009-07-23 19:21:43 UTC
checked w/OOO310m_16, Ubuntu 9.04

Checked with both odt and embedded Base form.