Issue 61274 - PDF export shows layers that are marked for not printing
Summary: PDF export shows layers that are marked for not printing
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: OOo 2.0.1
Hardware: All All
: P3 Trivial with 12 votes (vote)
Target Milestone: OOo 3.2
Assignee: wolframgarten
QA Contact: issues@graphics
Keywords: oooqa
: 56597 76088 76154 80768 87838 90099 91709 108011 (view as issue list)
Depends on:
Blocks: 90135
  Show dependency tree
Reported: 2006-01-28 19:39 UTC by markellse
Modified: 2009-12-31 08:12 UTC (History)
6 users (show)

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

Draw file that fails to export properly to pdf (75.28 KB, application/vnd.sun.xml.draw)
2006-01-28 19:40 UTC, markellse
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description markellse 2006-01-28 19:39:15 UTC
In a drawing with several layers, some of the layers can be marked so that they
are neither visible, nor printed. OOo correctly omits the marked layers. But
when the document is exported with the pdf export, these layers become visible.
This should not happen.

Problem file follows.
Comment 1 markellse 2006-01-28 19:40:42 UTC
Created attachment 33645 [details]
Draw file that fails to export properly to pdf
Comment 2 lars 2006-01-29 13:53:36 UTC
confirmed on Windows XP Pro SP2 with OOo-dev 2.0 (m153)
Comment 3 wolframgarten 2006-01-30 08:32:40 UTC
Reproducible. Reassigned.
Comment 4 sven.jacobi 2006-02-02 12:09:51 UTC
sj->aw: I think your changes for #110094# are the reason for this issue. Please
also take care that previews are rendered properly. (e.g. in the left pane)
Comment 5 sven.jacobi 2006-02-02 12:27:09 UTC
changed owner
Comment 6 sven.jacobi 2006-03-06 13:36:52 UTC
*** Issue 56597 has been marked as a duplicate of this issue. ***
Comment 7 Armin Le Grand 2006-05-16 16:02:48 UTC
AW: Changing target
Comment 8 Armin Le Grand 2006-07-04 11:48:54 UTC
Moved target.
Comment 9 Armin Le Grand 2006-10-26 17:26:48 UTC
AW: Took a look, the changes from #110094# are integrated before pdf export
existed (aw003), so that's not the case.
AW: In Principle, this can be done analog to printing in implementing and using
OutputToPDF() similar as OutputToPrinter() at the DisplayInfo class.

AW->MMP: First thing to clarify is if it is WANTED that for PDF export the
Non-Printable settings of shapes is taken care of. PL thinks it's not necessary
to do that at all. I tink PDF is a printing pre-stage (at least it was once, i
know it has many extensions now ...) and thus should not export objects which
are non-printable. As You are the designer of the PDF spec, i ask for Your
standpoint here.
Comment 10 Armin Le Grand 2006-10-26 17:37:12 UTC
AW: P.S.: broken and 'OK in 7 pp5' does not mean much here. In SO7 the PDF
export worked over the printer mechanism, so leaving out non-printable objects
worked by coincidence. Changing the PDF export mechanism was one of the big SO8
changes with the goal to get away from the printer-mechanism limitations.
Comment 11 norbert2 2006-10-27 06:22:53 UTC
"As You are the designer of the PDF spec, i ask for Your
standpoint here."

Please allow me to say my standpoint:

PDF export should be identical with printing, so it should NOT include
non-printing objects!

PDF export is often used to print documents on other machines.
Comment 12 markellse 2006-10-27 11:20:04 UTC
PDF is used to send a document to another person. And often you only want to
send part of the document - for instance you want to send exactly what you would
print out, which is probably only a couple of layers. 
So there are many times you would DEFINITELY NOT want to send certain layers,
for instance if you are making a new drawing and basing it on an old one. You
have the old one there while you make the new one and then send, or print, just
the new layer.
Or you may want to draw a plan with two possible alternative completions. You
need the ability to send each of these versions separately.
Hence it is REALLY IMPORTANT to be able to choose which layers you print, or
which layers you send in a PDF.
Comment 13 norbert2 2006-10-27 11:45:05 UTC
"Hence it is REALLY IMPORTANT to be able to choose which layers you print, or
which layers you send in a PDF."

Yes, in other words this means that NON-printing layers should also NOT be
exported to PDF since PDF export is some kind of printing.
Comment 14 mark_c 2006-10-27 11:52:46 UTC
I recently used Draw to create a CD sleeve that was to be used across five
offices in different locations. So I put the relevant address details and
localised text on different layers, expecting to be able to hide all-but-one at
a time and export a PDF so that the office could then print their own sleeves
from them.

I ended up having to go through a repeated cycle of deleting all-but-one of the
localised layers, then exporting, then undoing the deletion, then repeating.
This was a very tedious, and potentially error prone, procedure.

So I would also argue that PDF export should behave the same as printing when it
comes to the visibility of layers. Anything other than that is likely to be
unintuitive and non-obvious to most users.
Comment 15 markellse 2006-10-29 13:23:42 UTC
The previous two put it much better than I did, but since this is important I
want to make my agreement very clear.
Comment 16 wolframgarten 2007-04-04 15:41:18 UTC
*** Issue 76088 has been marked as a duplicate of this issue. ***
Comment 17 kpalagin 2007-04-09 04:59:50 UTC
*** Issue 76154 has been marked as a duplicate of this issue. ***
Comment 18 Regina Henschel 2007-08-17 16:17:10 UTC
*** Issue 80768 has been marked as a duplicate of this issue. ***
Comment 19 silmaril42 2007-10-26 09:00:32 UTC
As a matter of fact, Draw PDF export is completely useless for me as it is now.
I would really appreciate, if you could make it behave like the printing feature.
Comment 20 crxssi 2008-01-24 21:06:26 UTC
Add me as a "me too".  I believe that the PDF export in Draw should only export
the layers marked for printing.  Right now, I have to go through a dozen layers
and actually delete them before making a PDF!
Comment 21 Martin Hollmichel 2008-01-27 07:48:15 UTC
set target to 3.0
Comment 22 wolframgarten 2008-04-04 11:01:15 UTC
*** Issue 87838 has been marked as a duplicate of this issue. ***
Comment 23 clippka 2008-05-23 13:13:28 UTC
reassigned, retarget
Comment 24 frank.loehmann 2008-05-23 13:47:42 UTC
PDF documents are a platform independed reproduction of a program's output
normally printed out on paper. So invisible and non printable layers must not be
exported to a PDF file. Writer already does this when not exporting frames to
PDF if the "do not print attribut" is set.
Comment 25 frank.loehmann 2008-05-23 13:48:30 UTC
cc myself
Comment 26 wolframgarten 2008-05-29 10:50:47 UTC
*** Issue 90099 has been marked as a duplicate of this issue. ***
Comment 27 wolframgarten 2008-07-16 11:21:26 UTC
*** Issue 91709 has been marked as a duplicate of this issue. ***
Comment 28 clippka 2008-08-13 12:30:49 UTC
cl->aw: please implement that non printable layers are not visible in pdf
export. I would add the changes myself but I'm unsure how they would conflict
with aw033
Comment 29 Armin Le Grand 2008-12-10 14:56:59 UTC
AW: Moved to 3.2
Comment 30 Armin Le Grand 2008-12-10 17:24:54 UTC
AW: Taking a look for 3.1 again...
Comment 31 Armin Le Grand 2008-12-16 17:22:28 UTC
AW: Took a look in DEV300 m37. Invisible layers are painted in page previews,
printed and PDF exported. I'll take care of these in CWS aw061.
Comment 32 Armin Le Grand 2008-12-17 10:23:38 UTC
AW: Page previews: Here it is wanted to paint hidden layers; the Layer an object
belongs to is defined in the Model (at the object), but the layer visibility is
a view setting, not a model setting. The goal of this is to be able to have the
same model visible in multiple views, where each view defines the visibility of
the layers. Example: in a draw with objects on invisible layers, use window/new
window to open another view. In that 2nd view, You may use other visibilities
for the layers (e.g. to have an extra view to work with only one part of the model).
Comment 33 Armin Le Grand 2008-12-17 10:58:12 UTC
AW: Printing: uses the view layer printability, not the visibility settings from
where the print/PDF export was started from. Printing solely relies on the
view-settings of the layer regarding it's printability (see layer dialog). Works
as defined.

AW: PDF export: Shall be same as printing, adding support for checking for
recording PDF export in SdrPaintWindow (OutputToPDFWriter()) and it's usage in
SdrPageWindow::RedrawAll and SdrPageWindow::RedrawLayer. Building, checking
Comment 34 Armin Le Grand 2008-12-17 12:56:01 UTC
AW->AF: Unfortunately the Get/SetPrintableLayers() at the SdrPageView used for
PDF export is not set correctly. Debuuging reveals: PDF export is done using
SdXImpressDocument::render in sd over UNIOI API. There, a new SDrVioew is
constructed (pView = new ::sd::ClientView(..)). At that view, the correct
visible layers for visibility (SetVisibleLayers()) and for printability
(SetPrintableLayers()) need to be set. These should be copied from the active
view where the PDF export was asked from.

There are two ways to do This:
(1) When setting the visible layers from printable layers
(SetVisibleLayers(rOtherView.GetPrintableLayers())), nothng else needs to be done

(2) When keeping visibility and printability layer information seperated,
(SetPrintableLayers(rOtherView.GetPrintableLayers())) needs to be dne, and in
inx/source/svdraw/sdrpagewindow.cxx two places wich are now

	// get to be processed layers
	const sal_Bool bPrinter(GetPaintWindow().OutputToPrinter());
	SetOfByte aProcessLayers = bPrinter ? mrPageView.GetPrintableLayers() :

need to be replaced with

	// #i61274# get to be processed layers. Use print visibility for printer
    // and (do not forget) PDF exports
	const bool bPrintOrPDF(GetPaintWindow().OutputToPrinter() ||
	SetOfByte aProcessLayers(bPrintOrPDF ? mrPageView.GetPrintableLayers() :

I would of course prefer (2) and copying visibility and printability
information. I guess, the layer visibility information will need to be added to
the uno::Sequence< beans::PropertyValue > which is handed over to
SdXImpressDocument::render, but i do not know enough about the used PDF export
mechanism to do that safely.
Comment 35 groucho266 2009-01-30 15:59:20 UTC
@AW: One problem with your proposed fix remains: in
ImplRenderPaintProc::createRedirectedPrimitive2DSequence(...) in
sd/source/ui/unoidl/unomodel.cxx the visibility is checked twice:

SdrPage::checkVisibility(..) takes the process layers into account

IsVisible(..) and IsPrintable(..) do not and thus all shapes are not exported
that are
neither printable nor visible.

I am not shure if the calls to IsVisible and IsPrintable are really necessary here.

You probably know this better.
Comment 36 Armin Le Grand 2009-01-30 17:51:38 UTC
AW->AF: The ImplRenderPaintProc::createRedirectedPrimitive2DSequence(...) is
part of a callback mechanism (based on VOC's and
sdr::contact::ViewObjectContactRedirector) which CL initially used at the time
of Paints (before primitives) to do what he needed ho hide/change paints of e.g.
frames for PresObjs and stuff like Header/Footer/Time/date/PageNumber fields in
different kinds of view (i had to migrate that callback to primitives where not
only visibility may lead to not return any primitives, but also implementations
in SD exist who create extra/alternative primitives). So You will have to ask CL
about SdrPage::checkVisibility(..) and the local usage of IsVisible and
IsPrintable in ImplRenderPaintProc.
General visibility for DrawingLayer is checked using the implementations of
ViewObjectContact::isPrimitiveVisible(...) where the most used is probably
ViewObjectContactOfSdrObj::isPrimitiveVisible(..). Each VOC may implement it's
own version. The default versions already check layer visibility when the
ViewObjectContactOfSdrObj version is used. Geometric visibility (aka BoundRect
and ViewRange) is also checked in VOC, but independent from isPrimitiveVisible.
I will add CL to CC to answer the question. In my opinion - when
ViewObjectContactOfSdrObj::isPrimitiveVisible(..) is called already - it should
not be necessary.
Comment 37 groucho266 2009-02-23 09:58:22 UTC
Changing target to OOo 3.2
Comment 38 groucho266 2009-02-25 12:16:27 UTC
@cl: Please take over.
Comment 39 clippka 2009-04-17 10:36:32 UTC
I used solution one, now shapes on layer that are either not visible or not
printable are not exported to pdf.

fixed in cws impress171 for OOo 3.2
Comment 40 marwerno 2009-04-20 01:30:38 UTC
A BIG "THANK YOU" for fixing this!
When is V3.2 due? :-)))
Comment 41 clippka 2009-04-20 09:31:16 UTC
I'm sure you will find some release dates on the wiki pages of
But my gut feeling is that as always its done when its done :-)
Comment 42 clippka 2009-06-03 16:21:54 UTC
verified in cws, back to qa
Comment 43 wolframgarten 2009-06-05 09:39:49 UTC
Verified in CWS.
Comment 44 cianoz 2009-07-20 14:31:57 UTC
I just searched and found this issue because i recently verified this bug on my
own. Anyway, i wanted to report that the problem also afflicts export to any
graphic format, not only PDF export. If you export for example to TIF, JPEG o
something else you will have the same problem. I didn't realize if this has been
considered here.
Comment 45 thorsten.ziehm 2009-07-20 14:52:00 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
If you want to know more about the handling of fixed/verified issues =>
Comment 46 thorsten.ziehm 2009-07-20 15:35:06 UTC
Sorry this issue was wrongly closed. This issue will be reopened automatically.
And will be set after that back to fixed/verified.
Comment 47 thorsten.ziehm 2009-07-20 15:39:40 UTC
Set to state 'fixed'.
Comment 48 thorsten.ziehm 2009-07-20 15:43:59 UTC
Set back to state 'verified/fixed'.

Again. Sorry for the mass of mails.
Comment 49 wolframgarten 2009-07-21 07:47:49 UTC
Tested in m52. Closed.
Comment 50 Rainer Bielefeld 2009-12-31 08:12:47 UTC
*** Issue 108011 has been marked as a duplicate of this issue. ***