Description: I want to prepare a Latin text with the corresponding vocabulary and grammatical comments on the same page, with LO writer in order to have the possibility of post editing. Text, vocab-list and comments are prepared by other programs. To do that I prepare a template with three sections: one for the text, the second for the vocab-list and the last. Then I repeat that group of three sections on the next page. To fill easily the sections, I convert the odt template to a html and recognize the tags <div id="Texte">...</div> and <div id="Grammaire"> etc... where I have to put my text, vocab and comments. Then, the last easy step consists in loading the html file into LO Writer and save as odt. It works apparently fine. EXCEPT that the sections are now NESTED. The third one is a sub-section of the second. The fourth one and the fifth one are sub-sections of the third. And the last one is a sub-section of the fifth. This is the case with two pages, i.e. six sections. What will happen with 100 pages ? Steps to Reproduce: 1. Create a odt file with three sections, in the attached example they are called "Texte", "Grammaire" and "Definitions" (the text has a single column format, while the two others have two columns). Copy these three sections at the end of the document, they become "Section1", "Section2" and "Section3". The structure of the sections is flat (see Sections_in_template.png). Save that odt for reference. 2. Save as html this same file. Close that window. 3. Re-open the html file. Almost every thing seems OK (except for the header and the footer that are not present on each page, but it is easily restored). But looking at the structure of the sections they appear NESTED (see Back_in_Writer.png), as if a closing tag </div> has escaped to the detection. Actual Results: Nested sections (see Back_in_Writer.png). As if the html file contained <div id="Grammaire">... <div id="definitions">... </div> while it contains <div id="Grammaire">... </div> <div id="definitions">... </div> Expected Results: The same flat structure of the sections as in the original odt file (see Sections_in_template.png) Reproducible: Always User Profile Reset: No Additional Info: As I save from odt to html and open again the html file in LO writer (even doing nothing in between), I expect a structure of the sections similar to the original one.
Created attachment 169195 [details] Sections as they are in the template (odt file)
Created attachment 169196 [details] Sections as they appear when saved in html and re-opened with Writer
Created attachment 169197 [details] This particular template (but the result is the same with different files)
Created attachment 169198 [details] The HTML file corresponding to the template
Thank you for reporting the bug. Could you please attach the odt-file, you've created in step 1? This would make it easier to reproduce the bug. Thank you. => NEEDINFO
Created attachment 169664 [details] The original odt file used as template (attachment in 169195) Answer to comment#5
As a matter of fact, it was already there as attachment 169197 [details] (comment#3). The HTML file is in 169198 (comment #4).
I confirm it with Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Steps to reproduce 1. Open attachment from comment 3 or comment 5 2. Save as html 3. Reopen it 4. Open navigator => Sections Actual result Hierarchy of sections Expected result all sections on same level (like in original odt-file)
Dear PhVerkerk, 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
Version: 7.4.5.1 / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 8; OS: Mac OS X 10.13.6; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded The bug remains unchanged. Maybe worse in the sense that Writer does not take into account the page format (defined in the HTML) until a fake "Print" is performed (fake, because it does not need to be completed : I can click on the Cancel button, and do not need to actually print the document). The "Apply" button in the page format item is not sufficient.
Still repro. The structure of the saved HTML changed in 4.1 with 15f8a130e2e1a3c920b02ad034d09e547e69ea57 Use <div> instead of <multicol> when exporting multi-column sections This is what causes the nesting in the Navigator. I am not sure, if we can call this a regression.