It is impossible to export a selection of a drawing to PDF.
Steps to reproduce:
1. Create a drawing
2. Select one or more objects
4. Check the "Selection" checkbox
5. Select "PDF - Portable Document Format" from the "File type" list
6. Enter a filename
9. Open the PDF in a PDF viewer
10. The PDF contains the entire page with the entire drawing
11. The PDF should contain only the selected object(s), and the page size should exactly fit the objects
This problem makes it impossible to export drawings to PDF for use as graphics in other applications.
A workaround (which depends on third-party software) is to export instead to EPS, and then use the epstopdf command to convert the graphic to PDF.
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
PDF Export Dialog appears, unexpectedly range "All" radio button
7. select range "Selection" by radio button
JPG, reduced, rest unchecked)
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
- 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.
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.
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-126.96.36.199 (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.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
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 188.8.131.52. 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 184.108.40.206. With File->Export and
File->Export as PDF, only the selection is exported, but the page size is still
Confirmed in Writer of LibreOffice 220.127.116.11 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:
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?
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
Thank you for your help!
-- The LibreOffice QA Team
Problem is still reproducible, exactly as before, with LibreOffice 18.104.22.168.0+ on openSUSE 13.2.
Same bug on Writer, but images and html exports are affected too:
This bug is still present in all lo programs, at least up to Libreoffice 22.214.171.124 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 126.96.36.199 when previous comments have already shown it to be reproducible in 3.4.2 through 188.8.131.52.
That said, I can confirm that the bug still exists in more recent versions (at least up to 184.108.40.206).
*** 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
> 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.
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. ***
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.
Problem still exists in LibreOffice 220.127.116.11.
Could be done as another selection option (also for printing). After "( ) Selection" it lists "( ) Custom Slide show" with a dropdown to pick the custom show at PDF export and an updated dropdown instead of odd/even on printing. For the other export options (WMF, GIF, SVG etc.) we have "[ ] Selection" at the file dialog that needs to become a radio button with another item.
Alternatively, we could offer the export functions at the custom slide show dialog. Sounds a bit more clean to me.
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
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 18.104.22.168. 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).
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.
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 &
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.
So good and tasty. <a title="indisk mad" href="https://www.bindia.dk/">indisk mad</a> We were also nicely surprised by restaurant's customer service. We were fully satisfied after last time but restaurant quickly reacted to make up for everything. We are definitely coming back in the future 😉 Thank you.
<a title="blank apparel" href="https://unikaas.com/">blank apparel</a> Shirts in Bulk or in Singles A lot of times people thinking of wholesale t-shirts and other apparel imagine a bunch of factory seconds but Blank Apparel only offers the highest-quality clothing and accessories. By getting our inventory in bulk, we’re able to pass on the savings directly to our customers. <a title="blank apparel wholesale distributors" href="https://unikaas.com/">blank apparel wholesale distributors</a>
Faisalabadfabricstore.com the top quality t-shirt manufacturer/sourcing agent of clothes and <a title="wholesale t shirts" href="https://unikaas.com/wholesale-t-shirts/">wholesale t shirts</a> bulk dealers all over the world, especially our major exports, are in the UK, USA, UAE, Canada, and Bangladesh.
Find takeaway restauranter i Kongens <a title="takeaway lyngby" href="https://www.bindia.dk/indisk-mad-lyngby-hovedgade.html">takeaway lyngby</a> Premium take away i Lyngby Bor du i Lyngby, og kunne du tænke dig lækker take away leveret direkte til din dør? Så har vi hos Takeout samlet nogle af de bedste og mest kvalitetsbevidste restauranter, der laver take away i Lyngby.
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.
> 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. ***