Draw/Impress has File > Export > Html which leads to the ancient wizard with some limitations (bug 66259). The design team recommends to drop this wizard (similar to what is in progress for Writer in bug 99967) and make the html export like any other export function, i.e. one (successively numbered) document per slide with images in the original size and no cropping. Notes and comments are not exported. Everything else from the wizard is obsolete. It was also recommended to clean up the filters (export, save behave differently). This ticket could be an easyhack. Another, more general issue about what slides to export requires a dialog which goes into another ticket. It's suggested to use svg for users who want to show a presentation in the browser. (In reply to jan iversen from comment #8) > Please add skill<foo> difficulty<foo> > > as well as a code pointer.
What about mentioning it in the next ESC meeting?
(In reply to Xisco Faulí from comment #1) > What about mentioning it in the next ESC meeting? I was instructed to not discuss too many details in the ESC. And actually the recommendation from the design team has be done. But anyway, if we have the time next week...
(In reply to Heiko Tietze from comment #0) > Draw/Impress has File > Export > Html which leads to the ancient wizard with > some limitations (bug 66259). The design team recommends to drop this wizard > (similar to what is in progress for Writer in bug 99967) and make the html > export like any other export function, i.e. one (successively numbered) > document per slide with images in the original size and no cropping. Notes > and comments are not exported. Everything else from the wizard is obsolete. > It was also recommended to clean up the filters (export, save behave > differently). > > This ticket could be an easyhack. Another, more general issue about what > slides to export requires a dialog which goes into another ticket. > > It's suggested to use svg for users who want to show a presentation in the > browser. > > (In reply to jan iversen from comment #8) > > Please add skill<foo> difficulty<foo> > > > > as well as a code pointer. Huh ? there are no comment #8 on this bug ? I am not sure what the scope is here, you talk about different things: a) drop this wizard (easy, remove the menu entry) b) make the html export like any other export function (surely not a easyhack) c) clean up the filters (does not sound like a easyhack) please be specific, what is to be done in this easyhack.
(In reply to jan iversen from comment #3) > a) drop this wizard (easy, remove the menu entry) You would loose the html export option completely, and that's not what we want. Rather the current/selected slides should be exported with default settings, and I was taught it could be an easy hack. The task is to remove everything between start of the wizard and export of slides.
OK, I just wanted to have the scope clarified, and the b) c) versions does not look like easy hacks.
*** This bug has been marked as a duplicate of bug 99967 ***
Not a duplicate. This wizard is still alive and kicking here: https://cgit.freedesktop.org/libreoffice/core/tree/sd/source/filter/html
Please do not delete this wizzard or otherwise supply a working alternative. I have the following usecase. I export to html a presentation and currently chose the 1024x786 resolution. This gives me a lot of nice png images. I use these images to include in an asciidoc book. Actually I would like to propose to add another option to this wizzard, namely to export the images in highres (300dpi). That would really help. Just my € 0,02.... Jeroen Baten
(In reply to Jeroen Baten from comment #9) > ... otherwise supply a working alternative. Give Export to SVG a chance.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
QA response... Remains valid. Current Wizard needs to go for a cleaner export to SVG, and higher DPI and layout size matching canvas layout.
Not a UX topic actually neither keyword set so removing ux-advice.
*** Bug 143181 has been marked as a duplicate of this bug. ***
Dear Heiko Tietze, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/28b6480c6bdd179f3943f768926b7f196226c768 tdf#105303: Drop html export wizard It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/810fdf5e562324b03c7d08ab710ac14eb692bd08 tdf#105303: drop webview files too It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I guess we can close it now.
One thing is to drop the HTML Wizard..... a whole another thing is to DROP THE WHOLE HTML EXPORT!
(In reply to Tomaz Vajngerl from comment #19) > One thing is to drop the HTML Wizard..... a whole another thing is to DROP > THE WHOLE HTML EXPORT! Hello, I talked with Heiko during the hackfest and the conclusion was: if the wizard is dropped, then the "HTML Document" entry in the export dialog should also be dropped. Then if this entry is dropped, the user can no longer export to HTML from the UI, so the filter should also be dropped. @Tomaz, do you think the filter should stay even if it's no accessible from the UI?
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/491f223b3e7a1b272d3050fbaa84be897ef45c2d tdf#105303 (related) Drop HTML Export wizard help pages
(In reply to Tomaz Vajngerl from comment #19) > One thing is to drop the HTML Wizard..... a whole another thing is to DROP > THE WHOLE HTML EXPORT! If you export a slide as HTML the filter calls this dialog. Besides I don't see HTML being a good presentation format- there was some hype 10 years ago but we have PDF, which is felt more reliable, and SVG, which works in browsers too. Can you think of an example where exporting to HTML is needed (and working sufficiently)?
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e53a99c4bbf09763ecfb05a0926e7957b31c1fff tdf#105303 (related) Drop unused translation strings It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Xisco Faulí from comment #20) > Hello, > I talked with Heiko during the hackfest and the conclusion was: if the > wizard is dropped, then the "HTML Document" entry in the export dialog > should also be dropped. Then if this entry is dropped, the user can no > longer export to HTML from the UI, so the filter should also be dropped. > @Tomaz, do you think the filter should stay even if it's no accessible from > the UI? There are 2 different HTML exports that are contained in the wizard - one renders the slides to images and presents those in an HTML document (which is useless when we have much better vector based alternatives available today) and there is the single-document HTML export, which tries to convert the content of the slides to a HTML - not ideal but we can improve on that (which we can't with XHTML export because nobody sane wants to mess with XSLT). The idea of this was to get rid of the HTML wizard, but not the HTML export in general (all the comments here are very explicit about that for a good reason). HTML export should trigger what was the single-document HTML export.
(In reply to Heiko Tietze from comment #22) > If you export a slide as HTML the filter calls this dialog. Besides I don't > see HTML being a good presentation format- there was some hype 10 years ago > but we have PDF, which is felt more reliable, and SVG, which works in > browsers too. Can you think of an example where exporting to HTML is needed > (and working sufficiently)? Is there a need to rehash the design decision from 6 years ago? HTML export is not used only for presentation purposes but also for export of the content for various purposes like document indexing (which is for what the "single-document HTML export" is used).
(In reply to Tomaz Vajngerl from comment #24) > (In reply to Xisco Faulí from comment #20) > > Hello, > > I talked with Heiko during the hackfest and the conclusion was: if the > > wizard is dropped, then the "HTML Document" entry in the export dialog > > should also be dropped. Then if this entry is dropped, the user can no > > longer export to HTML from the UI, so the filter should also be dropped. > > @Tomaz, do you think the filter should stay even if it's no accessible from > > the UI? > > There are 2 different HTML exports that are contained in the wizard - one > renders the slides to images and presents those in an HTML document (which > is useless when we have much better vector based alternatives available > today) and there is the single-document HTML export, which tries to convert > the content of the slides to a HTML - not ideal but we can improve on that > (which we can't with XHTML export because nobody sane wants to mess with > XSLT). > > The idea of this was to get rid of the HTML wizard, but not the HTML export > in general (all the comments here are very explicit about that for a good > reason). HTML export should trigger what was the single-document HTML export. Hello, Thanks for the clarification. I'll revert the filter part and adapt it to use the single-document HTML export
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/608c35665bee5990bd7e2799854e233d1454b6a4 tdf#105303: re-introduce single-document html export filter It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I've been using export to html to get a set of png images for use in YouTube videos since 2020, but my upgrade to 24.x.x killed that. Are there plans to replace this feature? You've forced me to never upgrade past 7.x.x 8( (I even developed a python script to erase everything but the imgX.png files since that was all I really needed)
(In reply to Jim Benson from comment #28) > I've been using export to html to get a set of png images for use in YouTube > videos since 2020, but my upgrade to 24.x.x killed that. Are there plans to > replace this feature? You've forced me to never upgrade past 7.x.x 8( > > (I even developed a python script to erase everything but the imgX.png files > since that was all I really needed) There is an extension which will export all slides to images, so you can juist use that instead.
(In reply to Jim Benson from comment #28) > I've been using export to html to get a set of png images for use in YouTube > videos since 2020, but my upgrade to 24.x.x killed that. Are there plans to > replace this feature? Please also see bug 48015.
> (In reply to Tomaz Vajngerl from comment #29) > (In reply to Jim Benson from comment #28) > > I've been using export to html to get a set of png images for use in YouTube > > videos since 2020, but my upgrade to 24.x.x killed that. Are there plans to > > replace this feature? You've forced me to never upgrade past 7.x.x 8( > > > > (I even developed a python script to erase everything but the imgX.png files > > since that was all I really needed) > > There is an extension which will export all slides to images, so you can > juist use that instead. I'm in the same case here: we're using LibreOffice through JodConverter (https://github.com/jodconverter/jodconverter) in XWiki to perform conversion of presentations and import them directly in the wiki, with slide images attached to the created documents. It's a huge drawback for us to not be able to use that feature anymore, and from what I understand relying on the extension is not an option for us: we cannot provide the extension as part of the wiki, we would need to request our users to first install the extension, and then we'd need to find a way to use it programmatically.
I am quite surprised by this. It is true that the main use for the good old html export wizard was to automatically produce a series of bitmaps of the slides, not necessarily to use the html format in itself. This said, how on earth do I now get the hundred or more bitmap files of my slides??? All other filters (It seems to me the SVG as well) export just ONE single slide at a time!! Or am I missing something??? In fact if I do a search on the web on how to export a whole bunch of slides to image files, the same advice turns out all the times: export to html and then pick the images that were produced. So it is not really a need for the html infrastructure, and if the other export filters would allow to export multiple slides into multiple bitmap files, it would probably be as good (maybe better, since some other export filters have more formatting options). However, the point is... the html export wizard was, as far as I know, the ONLY way to get image files of all slides with no effort! So what can we do now? at the moment I am using an old portable LO6 that I have on an external disk... but why wipe out a somehow useful utility that was already there, causing no harm to anyone?? who is benefiting from this? I have also read the above discussion thread, and I must say I found the reasons for this quite vague and thin... with some comment disagreeing as well. Especially as there is no alternative! Anyway, if I am stupid enough not to realize there is another way to produce bitmap files of your slides automatically, I am more than ready to take the blame. But otherwise, having to export some 150 slides of a presentation one at a time is really no serious option. And, I know the pdf export is there and it is multipage, but you'll agree that a single pdf file is not always the reasonable solution. That's it, thank you for listening,