Bug 120241 - Chapter numbering not saved as ordered list when saving or exporting to HTML (see comment 5)
Summary: Chapter numbering not saved as ordered list when saving or exporting to HTML ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.2.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Chapter-Numbering HTML-Export
  Show dependency treegraph
 
Reported: 2018-10-01 14:13 UTC by Bernard TREMBLAY
Modified: 2019-10-27 03:37 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Simple headers document without any numbering (1.64 KB, text/html)
2018-10-24 13:46 UTC, Bernard TREMBLAY
Details
Same as 01 but after numbering and save (1.72 KB, text/html)
2018-10-24 13:53 UTC, Bernard TREMBLAY
Details
Example ODT to be saved as HTML (9.83 KB, application/vnd.oasis.opendocument.text)
2018-10-25 10:57 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernard TREMBLAY 2018-10-01 14:13:18 UTC
It seems that the several problems into the titles numbering.

What I observed with HTML editing about the title numbering

I used two titles (chapters ?) numbering and set a configuration :

- I had some difficulties because the titles which were into the text had some text attributes (no easily visible) and the titles numbering was refusing to function normally probably because the attributes of the text of the title are not cleaned. This is another problem.

- I have defined a titles numbering and choose to store the parameters and because of cleaning the titles before I got a clean numbering.
- When I saved the file I got the message about the fact that the file was containing elements which cannot be stored in html format on proposed an "odt" storage, not chosen because file has to be used in a pure html context.  This is curious into a first approach but when we know how functions HTML this can be understood.

- The file has been reopened

- What happens is that the file numbering is not activated into the tools (parameters empty).
If we edit the content (we need to use another editor - like phpstorm - because writer seems not to have anymore an HTML view (just standard and WEB but no html source), we can see that the numbers of the titles are simply written into the text.
So  if we run again the titles numbering we would get twice the numbers written. 

Currently the HTML editing titles numbering does simply a unique and simple numbering which cannot be changed after saving because the result is hard-written into the text of titles.

There no documentation about this and no warning.

Then this can seen in several manners :
- add a warning into the numbering panel
- add documentation : note that the process can be store as odt and save final version in html
- develop a dynamic numbering of titles in html

There are solutions to have a dynamic numbering with respect of HTML.

Best regards
Trebly
Comment 1 Buovjaga 2018-10-23 18:49:21 UTC
Please attach an example document.
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Comment 2 Bernard TREMBLAY 2018-10-24 13:34:47 UTC
Hi,

I can join an example of document but I don't understand how this can be useful.
The reason is that it is the process which is involved.
Then what I would need to provide is a video which shows the whole process.
It seems to me that is shorter to create each one an example mode easy to manipulate.
More without following the process nothing can be shown. The html that I provide has only a list of headers which contents begins by a number generated by the function "numbering chapter"
More if there are several ways to process to have several example will lead to a better confirmation and documentation of the problem.

Anybody can create a very simple example following the steps :

1- create HTML new document, LO writer switches to web mode.
2- in this document create a quick content with a headers hierarchy
3- use tool "numbering chapters", you get a document with chapters (Hx tags) that you can modify dynamically (add new header will change numbering).
4- save the file and close
5- reopen
6- you get the same view but 
   - numbers (can verify in html mode or any editor) are hard coded into the headers contents
   - the "numbering header" previously set values are forgotten
   - naturally if you re-define the "numbering header" you will get duplicate numbering
   - you need to clear old numbering using replace with a regular expression (must chose an easy identification numbering as for "9.9.9...-" /\d+[\.\d+]*\-\s*/ replace by nothing

Remark : this is quite normal but lead to complex operation for numbering. There are way "quite easy" to manage dynamic numbering by saving parameters into the html file and treat the file when re-open and initialize "numbering headers to previous configuration.

Trebly
Comment 3 Bernard TREMBLAY 2018-10-24 13:46:52 UTC
Created attachment 145971 [details]
Simple headers document without any numbering
Comment 4 Bernard TREMBLAY 2018-10-24 13:53:02 UTC
Created attachment 145973 [details]
Same as 01 but after numbering and save

In this file 02 a numbering has been performed and then the file saved.
If it is reopened the numbering is static and to modify text (add headers) you must destroy current numbering (hard codes added to headers to destroy using regular expression to perform replace by nothing) and reset a numbering for your new updating session.
This has to be repeated for each edition.
Comment 5 Buovjaga 2018-10-25 10:57:01 UTC
Created attachment 145995 [details]
Example ODT to be saved as HTML

In a nutshell: Writer does not save chapter numbering as an ordered list when saving as html OR exporting as html.
Having a numbered list done with the toolbar button does not lead to this loss of information.

The ODT was created like so:
1. Create a series of headings
2. Tools - Chapter numbering
3. Change Number: to 1, 2, 3 for levels 1 to 3

Save or export the document to html and you will see the problem.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 9a373521d7a328197a4bf9abeb0a981b7acba896
CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
Built on 19 October 2018
Comment 6 Bernard TREMBLAY 2018-10-25 12:48:27 UTC
Hi,

Sorry but you are right because you don't speak about the same subject.

(In reply to Buovjaga from comment #5)
> Created attachment 145995 [details]
> Example ODT to be saved as HTML
> 
> In a nutshell: Writer does not save chapter numbering as an ordered list
> when saving as html OR exporting as html.
> Having a numbered list done with the toolbar button does not lead to this
> loss of information.
> 
> The ODT was created like so:
> 1. Create a series of headings
> 2. Tools - Chapter numbering
> 3. Change Number: to 1, 2, 3 for levels 1 to 3
> 
> Save or export the document to html and you will see the problem.
> 
> Arch Linux 64-bit
> Version: 6.2.0.0.alpha0+
> Build ID: 9a373521d7a328197a4bf9abeb0a981b7acba896
> CPU threads: 8; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; 
> Locale: fi-FI (fi_FI.UTF-8); Calc: threaded
> Built on 19 October 2018

Hi,

Sorry but you are right because you don't speak about the same subject as me. But with both we can reach the following point.

You tell me about odt exportation while I tell you about working with html files.

The design of odt (file managed by LO writer) defines that "save as" to html format :
1- saves the headers numbered as hard coded into html. so this is an exported file because some functionalities used (headers numbering) is not hold into exported format and there is a warning (this warning tell that there are functionalities hold by odt which type is not explained; this message is curious because you have opened an html file and never an odt, the same as for odt content saved as html; this is a little ergonomic problem, never mind).
2- don't save into html any information about numbering format.

In this concept the consequence is that what I observe is normal : you cannot manage header numbering with html files. You can only set a numbering of the headers using odt feature but when you close the file you lost the numbering functionality and the file must be modified (clear numbers) to get it back to work on.  

The basic enhancement should be in my opinion :
1- document about this
2- warning message when the user -begins- to use the "header numbering" if the file is "html" or xml : "The headers will be numbered during the session but when you will close the numbers will be hard coded into the text of the headers. If you want to save the "header numbering parameters" and be able later to go on save the file as "odt"

Now I know well how to deal with this question taking this in account.

My question was how to managed header numbering with html file and :

- the answer is "you can number header into exported odt file to html" but you cannot manage the html file (save, close, re-open).

The main purpose of this is to use writer/web to create and edit html files with extended features as numbering headers. Files which can be edited partially elsewhere.
This is possible, the way is :
1- define into the headers a "span" with adapted class
2- define "data-" into an hidden html element which defines the numbering structure (json format for example)
3- when the html file is load restore (if exists) from these data (the headers spans easy to get, clear and renum with odt format structure) and the parameters red and converted to internal odt.

Those html files are then full html compatible and have an extended feature when managed with writer/web.

now I do this but a "little" manually :
1- must read numbering rules from written headers
2- clear numbers
3- redefine headers numbering parameters.

Note : with what has been written here I think that there is the contents need to write an article into the help or wiki : "managing html files headers numbering".

I think that my English is not sufficient to write articles but I can write or translate in French.

Best regards

Trebly


Best regards
Comment 7 Buovjaga 2018-10-25 14:06:45 UTC
I speak about the same subject. It does not matter, if you start with Writer Web or Writer. As long as you
1) use chapter numbering
2) save/export into html
you will lose the numbered list information.

If you use normal numbering, this problem does not exist. If you open an html file with <ol><li> numbered list, it will be interpreted by Writer correctly as a numbered list.
Comment 8 Bernard TREMBLAY 2018-10-25 15:09:18 UTC
(In reply to Buovjaga from comment #7)
> I speak about the same subject. It does not matter, if you start with Writer
> Web or Writer. As long as you
> 1) use chapter numbering
> 2) save/export into html
> you will lose the numbered list information.
> 
> If you use normal numbering, this problem does not exist. If you open an
> html file with <ol><li> numbered list, it will be interpreted by Writer
> correctly as a numbered list.

Sorry, we are around the same subject "the numbering" but :

1- the <ol>  and css associated are a part of html and dom
2- numbering header his currently out of the html native field without scripting js, so you cannot save in native html (without scripting) the chapter numbering.

But I explain how if you associate (what the most current) html file with scripting (included or able to be associated) and css context (most often included) it is easily possible to get numbering of chapter but not to edit with same features as possible with lo writer and odt format.
To edit such files need to get script or provide it and the needed parameters by any description or reference.

I mean that : a bridge can easily exist, edit such file is possible. This adds a feature. I currently do it to display documents but when I edit even WYSIWYG I have not the current numbering (versus odt editing), I need to "view display" (more I generates the table of contents).

I am quite sure to be able to write a script basic which can hold this, but I have no time to do this.   

Nevertheless current operation and documentation for commom user are not clear, this is another aspect of the problem.
Comment 9 QA Administrators 2019-10-27 03:37:52 UTC
Dear Bernard TREMBLAY,

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