Upon further testing, this appears to be a problem with the PDF exporter in general.  When selecting objects in, for example, LibreOffice Impress, the PDF "selection" export saves the entire document as a PDF instead of just the selection.

Confirmed for LibreOffice 3.4  340m1(Build:103) on OpenSuse Linux. All images are exported, not just selection.

NOT reproducible with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" 

Using the LibO dialogs I can check the "only selection" checkbox, but when the PDF export dialog appears, radio buttons show "All", and I will have to select "Selection" again, what will work in a perfect way. So the only problem might be that the "Selection only" information will not be transferred to the PDF export dialog.

Same results using WIN dialog.

My steps trying to reproduce (Here sith LibO dialogs):

1. Open attached "sample.odg"
2. select first 2 elements rhomb + smiley on first slide using mouse
   Control points rectangle shows selection
3. Menu 'File -> Export ...'
   File dialog appears
4. Check "Selection" and browse for folder if necessary
5. Select document type PDF
6. <Export>
   PDF Export Dialog appears, unexpectedly range "All" radio button
7. select range "Selection" by radio button
   JPG, reduced, rest unchecked)
8. <Export>
   Export will be done
10. go to foder, open document
    expected: only first 2 elements rhomb + smiley on first slide 
    actual: as expected

So no problem. If PED in step 6 does not appear this one would be a DUP of Bug 36842 - PDF-Export shows no options

@Tristan Miller, @Jeffrey
Please contribute information concerning your 
- OS
- observation details starting with your step 6
- your observation using Menu 'File -> Export as PDF'
- your observations with WRITER, CALC

Created attachment 50910 [details]
sample document, see Comment 3

Rainer, I can confirm that your understanding is correct:  when using File->Export, I check the "Selection" checkbox, but when I click on "Save" a "PDF Options" dialog appears which has the "All" radio button preselected in the "Range" set.  If this button is left as-is, the entire drawing is exported.  It's necessary to change the radio button to "Selection" in order to exclude the non-selected parts of the drawing from the output.

However, this is only a partial workaround:  the page size of the exported document is the entire page instead of the size of the selection.  So it's still impossible to export drawings to PDF for use as graphics in other applications.  This problem appears to be unique to the PDF export; when exporting as EPS or PNG, for example, the image size is the same as the selection size.

So for this bug to be fixed two changes must be made:

1. The value of the "Selection" checkbox in the "Export" dialog must propagate to the subsequent "PDF Options" dialog.

2. The page size of the exported PDF should match the size of the selection.

@Tristan:
Thank you for your feedback. Currently we here will handle the "all radio buttons together" problem. For all other problems (I will decide when your information is complete) I will open separate bugs and set you to CC. To keep this report clear, please do not comment here concerning any other problems.

Still waiting for your information concerning
- Your Operating System (Version, language)
- Your LibO UI language
- Your observations using Menu 'File -> Export as PDF'
- Your observations with WRITER, CALC

Useful might be additional information concerning your selection in Menu 
'Tools -> Options -> -> LibO -> General -> Open/Save dialogs' and may be screenshots.

Dear Rainer,

I respond to your points below:

> Your Operating System (Version, language)
> Your LibO UI language

I can reproduce the problem with the following two systems:

1) LibreOffice 3.4.2 OOO340m1 (Build:203) (installed from the tarballs on the LibreOffice website) using US English interface, running on Ubuntu 10.04 LTS for x86-64 with LANG=en_CA.utf8

2) LibreOffice 3.3.1 OOO330m19 (Build:8) tag libreoffice-3.3.1.2 (installed from openSUSE RPMs) using US English interface, running on openSUSE 11.3 for x86-64 with LANG=en_US.UTF-8

> Your observations using Menu 'File -> Export as PDF'

On my systems File->Export as PDF allows you to export the selection by selecting the "Selection" radio button from the "Range" set.  This works as expected (except that, as mentioned in my last comment, the page size is too large).

> Your observations with WRITER, CALC

The problem of the File->Export "Selection" checkbox value not being propagated to the "PDF Options" dialog occurs in Draw, Writer, Calc, and Impress.  It is necessary to select the "Selection" radio button from the "Range" set on the "PDF Options" dialog in order to have the selection exported.

> Useful might be additional information concerning your selection in Menu 
'Tools -> Options -> -> LibO -> General -> Open/Save dialogs'

On System 1, that section has a checkbox field for "Use LibreOffice dialogs".  The box is not checked.  On System 2, there is no section by that name.

> and may be screenshots.

If there's anything in particular you'd like screenshots of, let me know.

not reproduced problem in 3.3.4 and 3.5.0 on Fedora 64 bit
please, verify if problem still persist

Problem still exists with LibreOffice 3.5.2.2.  With File->Export and File->Export as PDF, only the selection is exported, but the page size is still too large.

Problem still exists with LibreOffice 3.6.0.4.  With File->Export and
File->Export as PDF, only the selection is exported, but the page size is still
too large.

Confirmed in Writer of LibreOffice 3.5.4.2 Build ID: 350m1(Build:2), under Ubuntu 12.04.

Is there a plan to fix this?

> Is there a plan to fix this?
No. Bug are fixed without plan.

This bug somehow resembles Bug 30944

As discussed in this forum thread: http://libreofficeforum.org/node/4183 , 
this problem might be related to a bug in poppler: 
https://bugs.freedesktop.org/show_bug.cgi?id=30692

I think it's worth noting that this is a fundamental problem, reported for various applications of LibO: Writer, Calc, Draw. 

Is there anyone working on a fix for this bug?

Problem is still reproducible, exactly as before, with LibreOffice 4.3.5.2.0+ on openSUSE 13.2.

Same bug on Writer, but images and html exports are affected too:
https://bugs.documentfoundation.org/show_bug.cgi?id=89077

This bug is still present in all lo programs, at least up to Libreoffice 4.2.8.2 in ubuntu: when you export to pdf a document while selecting an object, even if you specify the "selection" option in the "range" field of the export dialog, the whole page is exported and not just the selection.

I am attaching the following documents:
- very basic sample lo document
- screnshoot of the export dialog
- resulting pdf (the whole page and not just the selection)

Created attachment 119014 [details]
Sample document to be exported

Created attachment 119015 [details]
Screenshot of the export dialog

Created attachment 119016 [details]
Exported pdf (the whole page instead of just the object)

Antonello, I don't think it's useful to confirm the bug is present in 4.2.8.2 when previous comments have already shown it to be reproducible in 3.4.2 through 4.3.5.2.

That said, I can confirm that the bug still exists in more recent versions (at least up to 5.0.2.2).

*** Bug 79262 has been marked as a duplicate of this bug. ***

Agree with Tristan (comment #5). See also the Bounding Box issue.

So do I understand correct that the problem is that the 'Selection' option does not work for an object?
I would expect it does work for selected pages, but that does not work either.
How should I read " all 3 options selected together " ?

(In reply to Cor Nouws from comment #25)
> So do I understand correct that the problem is that the 'Selection' option
> does not work for an object?
> I would expect it does work for selected pages, but that does not work
> either.
> How should I read " all 3 options selected together " ?

Exporting the selection keeps the page size leading to, for instance, an A4 page with a small shape on it that has been selected for export. Other programs like Inkscape or Gimp show a dialog how to deal with the selection where the bounding box comes into play, IMHO.
Tristan's suggestion was also to check export to selection automatically when parts of the drawing are selected. This is quite common and makes sense.

*** Bug 73657 has been marked as a duplicate of this bug. ***

*** Bug 101454 has been marked as a duplicate of this bug. ***

*** Bug 55317 has been marked as a duplicate of this bug. ***

Selection button behavior was not an issue. Only valid issue is of the size of the exported PDF not matching the bounding box of the selected objects. The size to selected objects behavior is correct for other export types--but is wrong for the PDF export filter handling.

I am updating the hardware configurations relative to this bug to "All cpu" / "All OS", as according to comment 3 in duplicated bug 101454 (https://bugs.documentfoundation.org/show_bug.cgi?id=101454#c3) the export to PDF filter does not adjust the page size to selected objects also in Windows and not just in Linux.

PDF export with selection still exports as full page size, as compared with SVG export with ONLY the selection.

LibreOffice Draw
Version: 5.3.1.2
Build ID: 1:5.3.1-0ubuntu2
CPU Threads: 4; OS Version: Linux 4.10; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: en-CA (en_CA.UTF-8); Calc: group

This version of LO is installed with Kubuntu 17.04.

I've taken the workaround to use pdfcrop, as described at https://ask.libreoffice.org/en/question/46081/export-as-pdf-image-instead-of-pdf-page-in-draw/

*** Bug 114729 has been marked as a duplicate of this bug. ***

Problem still exists in LibreOffice 7.0.0.3.

discussed in the meeting.
Since it is not unreasonable to show a part of the slide on export, and other export options for selected objects are available (File>Expect), let us close as WFM.

created https://bugs.documentfoundation.org/show_bug.cgi?id=144102 for the Help

(In reply to Cor Nouws from comment #37)
> discussed in the meeting.
> Since it is not unreasonable to show a part of the slide on export, and
> other export options for selected objects are available (File>Expect), let
> us close as WFM.
> 
> created https://bugs.documentfoundation.org/show_bug.cgi?id=144102 for the
> Help

I'm afraid I don't understand your comment at all, and moreover your talk about "slides" mistakenly assumes that this issue is unique to LibreOffice Impress.

I can still reproduce the issue using both Impress and Draw on LibreOffice 7.1.5.2.  Can you please elaborate on what "other export options for selected objects are available"?  What other options are there for exporting a selected object to a PDF?  (On my system, there's no such command as File->Expect.  There is a File->Export, but it doesn't allow one to export as PDF.)

> Since it is not unreasonable to show a part of the slide on export ...

I think that there may be a misunderstanding in the scope of the bug. I believe this issue is not about slides (that is was not opened thinking of impress), but about drawings (opened thinking of draw). If you check the very first message it says "It is impossible to export a selection of a *drawing* to PDF" and then "Create a *drawing*, not a *slide*. For sure I got here because an issue opened by myself was marked as a duplicate of the present issue, and my initial bug was about draw.

While draw and impress are in many senses similar and possibly sharing a large amount of code, the use cases are quite different.

Indeed it is not unreasonable to have the desire to export a slide including only some elements and not others and for the slide case it may make sense to deliver the whole page in its original size (particularly if the slide includes master objects that span the whole slide).  However, for draw the situation is more complex.

Draw is often used to prepare illustrations in PDF format to be used in other applications (think LaTeX or desktop publishing). For these cases you want just the drawing with a tight bounding box in the final PDF. Because draw does not have a page format button to automatically restrict the page size to the actual drawing and because exporting the selection is anyway required for this task because currently it is the only way to create a PDF without a solid background, in draw it would seem much more logical to provide a tight bounding box with the PDF export of the current selection.

A case more similar to the impress one being mentioned would only occur in the much less frequent case where you have a drawing with a layer including a title block and margin borders. In this case you may be interested in exporting only a part of the drawing maintaining the original page format (size + title block layer).

Please reopen.

Still very much a bug in the PDF export filter.

Page size of the PDF export should match the bounding block of the selected objects--just like it does for the other export/save as filters.

Seems the PDF page is incorrectly set to the page size of the source document.

(In reply to sergio.callegari from comment #39)
> Draw is often used to prepare illustrations in PDF format to be used in
> other applications (think LaTeX or desktop publishing).

Not just desktop publishing, but professional publishing too.  Most publishers of journals and books request that diagrams and other illustrations be submitted as separate files.  All such publishers I have worked with accept PDF files for vector artwork, but none of them accept OpenDocument files, and many of them don't accept any of the vector formats produced via LibreOffice's File->Export command.

Print/Export a selection means to hide the other objects. It does not adjust the page/slide, which is bug 81118 and it's pendant bug 98786. Changing the current behavior would be a regression for many users. => WF

(In reply to Heiko Tietze from comment #42)
> Print/Export a selection means to hide the other objects. It does not adjust
> the page/slide, which is bug 81118 and it's pendant bug 98786. Changing the
> current behavior would be a regression for many users. => WF

But Heiko, as you note in comment 26, retaining the page/slide size is a problem. And in LO we have an inconsistency, the other graphic export/save-as filters honor the bounding box of the selection as the resulting size--only the export to PDF of selected objects retains the full page size of the source document rather than the bounding box!

The PDF export filter needs adjustment to use the bounding box by default, with maybe an option to retain the source document's page size--for the few use cases that is desiered.  The general case it is not.

(In reply to V Stuart Foote from comment #43)
> And in LO we have an inconsistency, the other graphic
> export/save-as filters honor the bounding box of the selection as the
> resulting size--only the export to PDF of selected objects retains the full
> page size of the source document rather than the bounding box!

String argument, but should we treat PDF similar to raster graphics? Feels wrong to me.

(In reply to Heiko Tietze from comment #44)

> String argument, but should we treat PDF similar to raster graphics? Feels
> wrong to me.

s/Stirng/Strong ???

Why assume that the arbitratry page size of the source (Writer, Draw, etc.) is the size you want the selection exported to PDF at?  

We don't for the other export/save-as formats (not just raster WMF, EMF & SVG).  

Believe the page size attribute for the PDF export filter is incorrectly being lifted from the source documents page size. Generally OK for PDF export of fully pages.  But, as with other handling in the UI, when a selection is made "honor the selection"!  Meaning, the PDF export filter needs a tweak to use the bounding box containing the selection when one has been made.

With that flexibility, PDF becomes a good "interchange" format allowing one finished quality graphics (raster/vector) without the overhead and poor support for Encapsulated Postscript (EPS).

(In reply to V Stuart Foote from comment #45)
> Why assume that the arbitratry page size of the source (Writer, Draw, etc.)
> is the size you want the selection exported to PDF at?  
PDF is a document format basically to share text with graphics. And those documents are usually standardized in A4 or letter.

> We don't for the other export/save-as formats (not just raster WMF, EMF &
> SVG).  
Graphics have an arbitrary size.

(In reply to Heiko Tietze from comment #46)
> PDF is a document format basically to share text with graphics. And those
> documents are usually standardized in A4 or letter.


Your definition is considerably narrower than the one used by the PDF standard itself, which calls PDF a format for "document" or "information" interchange, and says that this information may consist of text and graphics, but does not require that it contain both.  As explained in a previous comment, it is common in both desktop and professional publishing for purely graphical information to be stored in a tightly bounded PDF.  This is the de facto standard way of including graphics in LaTeX (which is ubiquitous in many academic fields) and of submitting vector artwork to commercial publishers of books and magazines.  In short, not everyone uses PDF exclusively for standalone text-and-graphics documents intended for printing on A4 or letter paper; other use cases are hardly unusual.

Hm, maybe an option in the PDF export dialog? But I still would prefer a "shrink to content" command requested in bug 81118 before print/export.

(In reply to Heiko Tietze from comment #48)
> Hm, maybe an option in the PDF export dialog? But I still would prefer a
> "shrink to content" command requested in bug 81118 before print/export.

An option for a tight bounding box in the export dialog makes sense to me, though it's probably best if it's *enabled* by default to make the behaviour consistent with how we export to other graphics formats.

A separate "shrink to content" command would be better than nothing, but it's not the best solution as it makes it harder to non-destructively export several selections from the same Draw/Impress document.

The more I look at this, the more I get convinced that rather than having an option in the "export" dialog, there should be a button in the page properties dialog letting the page size be adapted to the actual drawing, as there is in inkscape.

(In reply to Callegar from comment #51)
> The more I look at this, the more I get convinced that ... there should be a 
> button in the page properties dialog letting the page size be adapted to the
> actual drawing, as there is in inkscape.

Callegar, with respect - that's a completely different (though worthy) feature request. Sometimes you want to export a part of a larger page with more content than what's being exported - that's why we have "export selection".

You personally made the feature request resize-to-content in bug 81118, which you probably should have mentioned here.

@Eyal Rozenberg

> that's a completely different (though worthy) feature request. Sometimes you want to export a part of a larger page with more content than what's being exported - that's why we have "export selection".

Clearly, you are right.

To my excuse, must say that, due to other bugs, to me "Export selection" has become synonymous of "Export with no solid background" (that is otherwise always inserted even if the page background is set to none), so I may have lost contact with the original use it was meant for ;-)

I would say that for this use, reducing the PDF bounding box to the selection would almost always be what you want. I expect real world usage for exporting a part of a drawing so that it remains not centered in a much larger white page is probably low, is it? So if you add a tick, the logic could probably be better inverted (default for selection export is tight bounding box, tick to preserve page size when exporting selection).

PDF-Import-Draw is not about exporting, so moving it from being blocked by this one to just being related.

*** Bug 122065 has been marked as a duplicate of this bug. ***

I don't think there is the need of any UI changes. In the export dialog there is already the option to export selection, everything or individual pages. 
If one want to export a page, select page, if one want to export the objects, the page space outside the object shoudn't be included in the output