Bug 105303 - Drop html export wizard
Summary: Drop html export wizard
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:24.2.0
Keywords:
: 143181 (view as bug list)
Depends on:
Blocks: Draw-File-Handling (X)HTML-Export
  Show dependency treegraph
 
Reported: 2017-01-13 09:32 UTC by Heiko Tietze
Modified: 2024-09-17 17:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2017-01-13 09:32:39 UTC
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.
Comment 1 Xisco Faulí 2017-01-13 11:08:51 UTC
What about mentioning it in the next ESC meeting?
Comment 2 Heiko Tietze 2017-01-13 18:11:50 UTC Comment hidden (no-value)
Comment 3 jani 2017-01-16 07:11:40 UTC
(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.
Comment 4 Heiko Tietze 2017-01-16 08:36:46 UTC
(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.
Comment 5 jani 2017-01-16 08:39:43 UTC
OK, I just wanted to have the scope clarified, and the b) c) versions does not look like easy hacks.
Comment 6 Xisco Faulí 2017-04-22 19:06:42 UTC

*** This bug has been marked as a duplicate of bug 99967 ***
Comment 7 Fakabbir amin 2017-05-26 16:38:20 UTC Comment hidden (obsolete)
Comment 8 Gabor Kelemen (allotropia) 2017-05-26 18:06:44 UTC
Not a duplicate. 
This wizard is still alive and kicking here:
https://cgit.freedesktop.org/libreoffice/core/tree/sd/source/filter/html
Comment 9 Jeroen Baten 2017-10-30 14:27:39 UTC
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
Comment 10 Heiko Tietze 2017-10-30 15:49:42 UTC
(In reply to Jeroen Baten from comment #9)
> ... otherwise supply a working alternative.

Give Export to SVG a chance.
Comment 11 QA Administrators 2018-10-31 03:52:55 UTC Comment hidden (obsolete)
Comment 12 V Stuart Foote 2018-12-25 05:01:35 UTC
QA response...

Remains valid. Current Wizard needs to go for a cleaner export to SVG, and higher DPI and layout size matching canvas layout.
Comment 13 Heiko Tietze 2018-12-30 14:18:08 UTC Comment hidden (off-topic)
Comment 14 V Stuart Foote 2021-07-05 14:56:06 UTC
*** Bug 143181 has been marked as a duplicate of this bug. ***
Comment 15 QA Administrators 2023-08-01 03:16:22 UTC Comment hidden (obsolete)
Comment 16 Commit Notification 2023-09-23 09:04:09 UTC
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.
Comment 17 Commit Notification 2023-09-23 11:48:26 UTC
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.
Comment 18 Xisco Faulí 2023-09-24 02:59:03 UTC
I guess we can close it now.
Comment 19 Tomaz Vajngerl 2023-09-24 19:52:17 UTC
One thing is to drop the HTML Wizard..... a whole another thing is to DROP THE WHOLE HTML EXPORT!
Comment 20 Xisco Faulí 2023-09-25 12:22:32 UTC
(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?
Comment 21 Commit Notification 2023-09-26 06:38:28 UTC
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
Comment 22 Heiko Tietze 2023-09-26 09:20:20 UTC
(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)?
Comment 23 Commit Notification 2023-09-26 14:27:08 UTC
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.
Comment 24 Tomaz Vajngerl 2023-09-26 18:16:10 UTC
(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.
Comment 25 Tomaz Vajngerl 2023-09-26 19:18:12 UTC
(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).
Comment 26 Xisco Faulí 2023-09-27 07:38:23 UTC
(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
Comment 27 Commit Notification 2023-09-28 13:39:27 UTC
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.
Comment 28 Jim Benson 2024-06-30 13:07:23 UTC
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)
Comment 29 Tomaz Vajngerl 2024-07-01 02:52:11 UTC
(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.
Comment 30 Stéphane Guillou (stragu) 2024-07-01 04:51:17 UTC
(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.
Comment 31 Simon Urli 2024-09-04 13:15:22 UTC
> (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.
Comment 32 Andy 2024-09-17 17:57:21 UTC
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,