Currently if I have a 10 sheet drawing or 10 sheet presentation and I want to export all the sheets as png files I have to export one sheet at a time. For each sheet I have to enter the resolution and page size. It is very tedious. Enhancement: Add ability to select slide to the bitmap export dialog (png, bmp, jpg, etc) similar to how you select pages in the print dialog. Default could be "Selection" which is similar functionality to what is current. If you select more than one slide it will automatically append the slide number to the filename. For example if you type in slides 2,7,8-12,14 and you enter the filename of "My Exported Slides" when you export a png, it will output the followings: My Exported Slides02.png My Exported Slides07.png My Exported Slides08.png My Exported Slides08.png My Exported Slides10.png My Exported Slides11.png My Exported Slides12.png My Exported Slides14.png
Until someone will work on this enhancement request, you can use export the html. This does not only generate the html-files, but generate a picture from each slide. You can choose, whether it is png or jpg. They are simple named img0.png, img1.png,...
(In reply to comment #1) > Until someone will work on this enhancement request, you can use export the > html. This does not only generate the html-files, but generate a picture > from each slide. You can choose, whether it is png or jpg. They are simple > named img0.png, img1.png,... Reporter: Does this solution satisfy your needs?
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
No, close but this is just not the same thing. I need 300dpi export of every page to make the legal documents requirements. html has too limited control of export format. Right now only way to export is with controlled size and resolution is one page at a time. If document is 50 pages that is very tedious.
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO
Not certain why closing as "invalid" but here is information requested. Now if developers are rejecting the enhancement then I suppose that would need to be set to "Wontfix". for now I will set to unconfirmed as the instructions recommend. Here are responses to questions for reopening: > a) Provide details of your system including your operating system and the > latest version of LibreOffice that you have confirmed the bug to be present Affects all operating systems and versions up to 4.0.3 > b) Provide easy to reproduce steps – the simpler the better 1. Open or create a drawing with many pages. 2. Select page 1. 3. Select File/Export 4. Set file type to .png 5. Set file name to something like "page1.png" 6. Set the options for page size and resolution (this will reset everytime). 7. Repeat steps 2 to 6 for every page. > c) Provide any test case(s) which will help us confirm the problem Any drawing with multiple pages, best test case need >10 pages. I often deal with >50 sheet drawing. > d) Provide screenshots of the problem if you think it might help Would not help > e) Read all comments and provide any requested information Biggest comment was if exporting as html is acceptable work around as that creates thumbnails of all the pages. This does not however allow you to set the page size and resolution as you can exporting one page at a time. Other work around is export one page at a time which is very tedious and can take a great deal of time if you have lots of sheets/pages in your drawing. The other comment as "NeedsInfo" warning which I provide. If not clear and I can try to post a video demonstrating out tedious it is to manually exporting one sheet at a time.
changed to NEW: seems to be an interesting improvement proposal
Working with: http://extensions.libreoffice.org/extension-center/export-as-images
Sounds like an EASYHACK.
NEEDINFO for the code pointers.
FWIW I've never heard of NEEDINFO being used for code pointers. This is precisely what needsDevEval is for and placing it in NEEDINFO risks the bug being closed as INVALID after 7 months from auto purge. A lot of the times needsDevEval lasts a year or longer just because experienced devs are really busy and can't find the time to dig into code to give code pointers. Just my thoughts - not sure how NEEDINFO adds anything on top of "needsDevEval" in keywords
(In reply to Joel Madero from comment #11) > FWIW I've never heard of NEEDINFO being used for code pointers. This is > precisely what needsDevEval is for and placing it in NEEDINFO risks the bug > being closed as INVALID after 7 months from auto purge. A lot of the times > needsDevEval lasts a year or longer just because experienced devs are really > busy and can't find the time to dig into code to give code pointers. > > Just my thoughts - not sure how NEEDINFO adds anything on top of > "needsDevEval" in keywords It was the ESC decision how to handle proposed easyhacks. Samuel also warned about this procedure. We could introduce PROPOSED_EASYHACK. CC'ing Jan.
Okay - I don't follow any of those decisions any more. Couple notes then: 1) ESC or someone else should figure out what to do about needsDevEval (which again is literally the exact same thing in this case); 2) Markus before was really against using any other term that had "easyhack" in it because searches become difficult so again, ESC should deal with it. My guess is lots and lots of bugs will be inadvertently closed with this method but that's no longer my issue.
(In reply to Joel Madero from comment #13) > Okay - I don't follow any of those decisions any more. Couple notes then: > > 1) ESC or someone else should figure out what to do about needsDevEval > (which again is literally the exact same thing in this case); Actually not, only for easyhacks. When I look at bugs with needsDevEval there are typically questions about more than just code pointers. > 2) Markus before was really against using any other term that had "easyhack" > in it because searches become difficult so again, ESC should deal with it. The much simpler solution is to remove easyhack, after having monitored easyhacks closely for half a year, it is my experience that code pointers are very seldomly added later (see the current NEEDINFO and how old they are) > > My guess is lots and lots of bugs will be inadvertently closed with this > method but that's no longer my issue. lots and lots is a bit high, we have at the moment ca. 15 issues missing code pointer. And if a code pointer is not supplied in 7 month, why should it be supplied later. Adding more keywords like proposed_easyhacks just means more maintenance and complexer searchs, but I am quite indifferent as long as we have a fixed definition.
(In reply to jan iversen from comment #14) > (In reply to Joel Madero from comment #13) > > Okay - I don't follow any of those decisions any more. Couple notes then: > > > > 1) ESC or someone else should figure out what to do about needsDevEval > > (which again is literally the exact same thing in this case); > > Actually not, only for easyhacks. When I look at bugs with needsDevEval > there are typically questions about more than just code pointers. Hm - no idea. I know that when needsDevEval was proposed it was meant to replace propsedEasyHack....if it's not being used that way, I have no idea. > > 2) Markus before was really against using any other term that had "easyhack" > > in it because searches become difficult so again, ESC should deal with it. > The much simpler solution is to remove easyhack, after having monitored > easyhacks closely for half a year, it is my experience that code pointers > are very seldomly added later (see the current NEEDINFO and how old they are) That's not my call to make. If easyHacks are leaving, then so be it ;) You and ESC can make that call. I suspect some advocates won't be happy. > > > > My guess is lots and lots of bugs will be inadvertently closed with this > > method but that's no longer my issue. > lots and lots is a bit high, we have at the moment ca. 15 issues missing > code pointer. Fair > And if a code pointer is not supplied in 7 month, why should it be supplied > later. The problem is that these bugs are entirely valid but will be closed as INVALID if they go to NEEDINFO and sit there for 7 months. So, the bugs are inappropriately closed as INVALID (because they are entirely valid) they just don't have code pointers. > > Adding more keywords like proposed_easyhacks just means more maintenance and > complexer searchs, but I am quite indifferent as long as we have a fixed > definition. I didn't say anything about adding new keywords - I said we have one already that at least in theory should be used for (see https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords#needsDevEval)
So we better go back and set proposed easyhacks as a comment plus needDevEval. And the dev sets EASYHACK along with all required information. Confirmation by ESC assumed... Jan?
No need to add needsDevlEval for easyhacks (but ok it does not hurt). need code pointer, difficulty<foo>
Adding the menu entry is an easyHack, but making the code loop is non-trivial.
Removing keyword 'needsDevEval' as this bug is an easyHack
there is an extension "Export as image" https://extensions.libreoffice.org/extensions/export-as-images try it
Please add keyword 'needsUXEval' and CC 'libreoffice-ux-advise@lists.freedesktop.org' if input from UX is needed.
*** Bug 137007 has been marked as a duplicate of this bug. ***
*** Bug 67614 has been marked as a duplicate of this bug. ***
*** Bug 67942 has been marked as a duplicate of this bug. ***
*** Bug 81825 has been marked as a duplicate of this bug. ***
*** Bug 93589 has been marked as a duplicate of this bug. ***
*** Bug 105359 has been marked as a duplicate of this bug. ***
*** Bug 109071 has been marked as a duplicate of this bug. ***
*** Bug 118804 has been marked as a duplicate of this bug. ***
*** Bug 130084 has been marked as a duplicate of this bug. ***
*** Bug 132401 has been marked as a duplicate of this bug. ***
*** Bug 154176 has been marked as a duplicate of this bug. ***
Let's set the priority to "high" given the 10 duplicates, and the fact that the HTML export wizard is being deprecated in 24.2 and it is currently used as a way to export all slides as images at once (see e.g. comment 1 and bug 157440 and the article https://www.libreofficehelp.com/export-libreoffice-impress-slides-images/).
*** Bug 157993 has been marked as a duplicate of this bug. ***
(In reply to Stéphane Guillou (stragu) from comment #33) > Let's set the priority to "high" given the 10 duplicates, and the fact that > the HTML export wizard is being deprecated in 24.2 and it is currently used > as a way to export all slides as images at once (see e.g. comment 1 and bug > 157440 and the article > https://www.libreofficehelp.com/export-libreoffice-impress-slides-images/). But as noted comment 20 The "Export As Images" extension [1] already provides this functionality of exporting an entire sd Draw or Impress document one image at a time (though its SVG export is wonky). Alternatively, the Impress Export to SVG generates a dated SMIL 2.0 compliant [2] slide show of SVG images. But as for bug 117708 the feature needs rework. Both in its UI, and compliance with more current SMIL 3.0 While the Draw Export... to SVG munges a multi-page drawing selection into a single image (similar to the Extension's handling, likely same export filter). =-ref-= [1] https://extensions.libreoffice.org/en/extensions/show/export-as-images [2] https://en.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language
*** Bug 160574 has been marked as a duplicate of this bug. ***
One thing to keep in mind regarding the "Export As Images" extension is that it is 100% useless for exporting draw pages having transparent backgrounds. It always provides white backgrounds regardless.
(In reply to xordevoreaux from comment #37) > One thing to keep in mind regarding the "Export As Images" extension is that > it is 100% useless for exporting draw pages having transparent backgrounds. > It always provides white backgrounds regardless. No, I think it depends on the export format chosen, e.g. BMP looks to keep the transparent bg just fine.
(In reply to V Stuart Foote from comment #38) > (In reply to xordevoreaux from comment #37) > > One thing to keep in mind regarding the "Export As Images" extension is that > > it is 100% useless for exporting draw pages having transparent backgrounds. > > It always provides white backgrounds regardless. > > No, I think it depends on the export format chosen, e.g. BMP looks to keep > the transparent bg just fine. And in my use-case scenario, all I will ever export to is PNG.
(In reply to xordevoreaux from comment #39) > > And in my use-case scenario, all I will ever export to is PNG. Sure YMMV, the filters linked to the GraphicExportFilter.idl calls [1] used in the macro extension could use some work. For now the extension's BMP, TIFF, and JPEG do look to parse the bg transparency color and apply it as a bg color, though they drop any alpha channel for the bitmap. While PNG munges the bg color and drops transparency (though it should support it that I can tell). And GIF does write out transparency but incorrectly. So if you just need the colored bitmap image, export to one of the three that include image "translucence" then use an external program to convert the rasters. E.g. ImageMagick's convert to some other format. But yes, alpha channel transparency is not currently well supported in the API. But the extension provides what OP asks, though with limitations. And a native export dialog (to include alpha channel transparency and improved SVG handling) still is needed. =-ref-= [1] https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1drawing_1_1XGraphicExportFilter.html#a6aa9321da133d8081166f37c910c11c2
In command-line help for libreoffice command, still you can see the option `--convert-images-to`, but I was truly unable to use it in order to extract the images. (I'm already aware of the extension for that purpose). Either must be out if the command-line help to avoid confusions (maybe this functionality has been deprecated), or the command-line help must be very specific in it usage. However, if this functionality can be restores, MUST BE. It's quite useful to distribute the images in wiki pages, html web pages, etc. Here's what you can read in command-line help (`$ libreoffice --help`) ``` --convert-to OutputFileExtension[:OutputFilterName] \ [--outdir output_dir] [--convert-images-to] Batch convert files (implies --headless). If --outdir isn't specified, then current working directory is used as output_dir. If --convert-images-to is given, its parameter is taken as the target filter format for *all* images written to the output format. If --convert-to is used more than once, the last value of OutputFileExtension[:OutputFilterName] is effective. If --outdir is used more than once, only its last value is effective. For example: --convert-to pdf *.odt --convert-to epub *.doc --convert-to pdf:writer_pdf_Export --outdir /home/user *.doc --convert-to "html:XHTML Writer File:UTF8" \ --convert-images-to "jpg" *.doc --convert-to "txt:Text (encoded):UTF8" *.doc ```
(In reply to Lobaluna from comment #41) That option was added in tdf#109202. Your comment is off-topic here.
Why offtopic? The functionality has being deprecated in 24.2, that's the point of the topic! And because of the amount of duplicates, I would guess the functionality is missed by a lot of people and its worth to reimplement, even there is a plugin, that works (currently).
(In reply to eddie8+DF from comment #43) > Why offtopic? Because you tried to discuss '--convert-images-to', which is completely unrelated, and is only to define the file type in case the images get generated.
The "Export As Images" extension is now dead in the water. Simply selecting the extension from the drop-down from the menu produces the following basic error: Basic Runtime Error An exception occurred Type: com.sun.star.container.NoSuchElementException Message:ExportImages Dies on line 87: oLibContainer.loadLibrary( sLibName) Please work multi-page export functionality from Draw as a standard function. I have 40 drawings in one draw program that I wish to export. Manually is tedious and export as HTML makes more work post-export than it's worth.
(In reply to xordevoreaux from comment #45) > The "Export As Images" extension is now dead in the water. Mind to report on the extension site?
Actually, I do mind. Keeping this broken, ancient extension limping along is not the solution. A practical, complete, error-free, in-house implementation programmed directly into Draw is the solution. That is the goal. That is what you should be working toward, not hoping the author of the original extension is even alive much less caring to update old code. Bring it in house and call it a day.
@Neil, @Mike K. With a 26.2.2 or a 26.8.0 install, I am getting the error noted when the 'Export as Images' extension is loaded and its Basic macros are run for the export. JPEG works, but PNG and BMP were choking with this error: Basic runtime error Variable not defined. Don't believe Sergii Kuznietsov remains active. Since past consensus has been to keep this as an Extension might this be a good feature to consider reimplementing and distributing as an embedded extension, done while bringing the graphics handling and filters current? And maybe good one for port to Python?
For what it’s worth, the extension seems to work fine for me. I was able to export a presentation with multiple slides to jpg, png and bmp. I agree it seems like it would be a good idea to add this functionality directly to LibreOffice seeing as there are so many duplicates of the bug report. The extension is GPL so presumably it would have to be a “clean room” implementation instead of a port to make it MPL. On the other hand I don’t think that adding it to the LO codebase will magically mean that there will be people to work on it and maintain it. If contributors that work on parts of the core code disappear then it is just as much a problem as if an extension developer disappears.
I was on Windows builds of 26.2.2 or recent 26.8.0 with the 1.01 build of the extension installed. Trying to get the PNG export to choke again, now not sure what I'd done that triggered it. For sure the extensions BMP export is having an issue with its RLE selector. The undefined variable bmpRLB, seems that should be bmpRLE to match its dim?
For me, on: Version: 26.2.3.2 (X86_64) Build ID: 70e089b17412e4cb7773e41413306b17a2328c34 CPU threads: 24; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded All I had to do was: 1. create a new draw document 2. immediately select export as images Boom. --- Sub ShowDialog() REM library container oLibContainer = DialogLibraries REM load the library oLibContainer.loadLibrary( sLibName ) REM get library oLib = oLibContainer.getByName( sLibName ) REM get input stream provider oInputStreamProvider = oLib.getByName( sDialogName ) REM create dialog control oDialog = CreateUnoDialog( oInputStreamProvider ) REM show the dialog oDialog.Model.Step = 1 imgType = "jpg" imgColor = true bmpExMode = 0 StopMark = false dirText = oDialog.Model.getByName("dirTextField") nameText = oDialog.Model.getByName("nameTextField") oDialog.getControl("dirTextField").setText(docDir) oDialog.getControl("nameTextField").setText(docName) if oDialog.execute()=1 then OK else StopMark = true endif End Sub It died on the line: oLib = oLibContainer.getByName( sLibName ) Ditto situation when I actually created content prior to export attempt.
The File > Export... command should export the entire document, in every one of the LO modules. My new bug 172242 was filed due to my surprise at not finding a slide export function anywhere else, and this command actually exporting a single slide.
@skiani it should be a choice. Some of my documents, no two slides/pages are topically related and I just wish to export that one. Other times, everything is very much topically central and yes in those cases I wish to export the entire document as separate PNG files, one per slide.