Created attachment 33645 [details]
Draw file that fails to export properly to pdf

confirmed on Windows XP Pro SP2 with OOo-dev 2.0 (m153)

Reproducible. Reassigned.

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)

changed owner

*** Issue 56597 has been marked as a duplicate of this issue. ***

AW: Changing target

Moved target.

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.

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.

"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.

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.
Thanks

"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.

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.

The previous two put it much better than I did, but since this is important I
want to make my agreement very clear.
LAYERS WHICH ARE MARKED NOT FOR PRINTING SHOULD NOT APPEAR ON THE PDF OUTPUT.

*** Issue 76088 has been marked as a duplicate of this issue. ***

*** Issue 76154 has been marked as a duplicate of this issue. ***

*** Issue 80768 has been marked as a duplicate of this issue. ***

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.

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!

set target to 3.0

*** Issue 87838 has been marked as a duplicate of this issue. ***

reassigned, retarget

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.

cc myself

*** Issue 90099 has been marked as a duplicate of this issue. ***

*** Issue 91709 has been marked as a duplicate of this issue. ***

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

AW: Moved to 3.2

AW: Taking a look for 3.1 again...

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.

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).

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
functionality...

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() :
mrPageView.GetVisibleLayers();


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() ||
GetPaintWindow().OutputToPDFWriter());
	SetOfByte aProcessLayers(bPrintOrPDF ? mrPageView.GetPrintableLayers() :
mrPageView.GetVisibleLayers());

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.

@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.

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.

Changing target to OOo 3.2

@cl: Please take over.

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

A BIG "THANK YOU" for fixing this!
When is V3.2 due? :-)))

I'm sure you will find some release dates on the wiki pages of openoffice.org.
But my gut feeling is that as always its done when its done :-)

verified in cws, back to qa

Verified in CWS.

Hello
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.
Regards.

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 =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues

Sorry this issue was wrongly closed. This issue will be reopened automatically.
And will be set after that back to fixed/verified.

Set to state 'fixed'.

Set back to state 'verified/fixed'.

Again. Sorry for the mass of mails.

Tested in m52. Closed.

*** Issue 108011 has been marked as a duplicate of this issue. ***