Hi Heiko, I'm all for maintaining consistency and I think that it's a good thing if empty entries are shown in the ToC, so the user will know that action is needed to remove them (i.e. apply the correct style to remove these empty entries from the ToC). This is also in line with what Bug 149230 is trying to build.

My only concern is with how DOCX files will be imported. Since the ToC will have been crated by MS Word, the ToC entries must remain as they were created by MS Word. Hence empty entries that were ignored by Word while creating the ToC must not be added during import.

My suggestion is that this feature you're proposing be applied only for ToC created by LO Writer.

(In reply to Rafael Lima from comment #1)
> My suggestion is that this feature you're proposing be applied only for ToC
> created by LO Writer.

Rafael, I won't support this idea. LO should be more than just a pure copy of MS Office and if it is possible to provide a better solution, we should provide it. And also, if we follow yor suggestion, we will get a new bug report: "FILEOPEN DOCX: LO doesn't show empty paragraphs in TOC". I would like to avoid it.

So I support Heiko's suggestion and can confirm the problem with
Version: 7.3.4.1 (x64) / LibreOffice Community
Build ID: 13668373362b52f6e3ebcaaecb031bd59a3ac66b
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Heiko, I set status to NEW. If you think we should take into account Rafael's remark, feel free to change it back to UNCONFIRMED or to discuss it in the meeting of the Design Team.

We should also take into account consistency with outline folding feature (but at the moment I don't have time to check this).

(In reply to Dieter from comment #2)
> LO should be more than just a pure copy
> of MS Office and if it is possible to provide a better solution, we should
> provide it.

First of all: there is no "better" solution for opening *any file* than to show the document exactly as it was intended to be shown by the author.

Which means:

* For external formats: follow the format specification *and the de-facto standard implementation* - which, for OOXML, would be MS Office applications.

* For legacy documents in own format: open them exactly as they were shown previously.

Anything else is simply breaking existing documents and interoperability, so would be unacceptable.

So the *only* way this could be ever implemented is just for newly created own documents, where the document would bear a "new-style" compatibility flag (which missing state would mean "keep hiding the empty paragraphs", making it safe for old documents).

And generally, unless there is a user demand, I see this a WONTFIX - it looks primarily invented problem without any evidence that users need it.

I wonder when this was introduced. Dieter, can you check some older versions?

(In reply to Heiko Tietze from comment #5)
> I wonder when this was introduced. Dieter, can you check some older versions?

It was working that way in Ooo 2.2.0 from 2006, as well as in StarOffice 5.2 from 2000.

The compatibility / document breaking argument is strong. Fear we have to live with the inconsistency between ToC and Navigator.

This started as a user problem:
"The issue with the current LO Writer implementation is that it is not possible to hide such entries, so we end up with a very long Headings list with empty entries, which is not helpful for one who is reading a document and navigating through it."
A solution is to simply change empty headings to normal text with a single action. 

Then we got this one. 
It wasn't explained properly, mainly based on consistency, but not on cases with ODT and DOCX. 
Already noted that MSO doesn't show empty lines in DOCX attachment 180370 [details]. 
LO doesn't show them either.

I am in favor of WONT FIX. 
Curious why LO and MSO don't show them. And no change should be done if that's not clear. 
Until those and questions by Mike are explained, I set Needinfo.

In no way should this be changed, so that next report is "I see blanks in ToC".
An option is OK IMO.

Trying to confuse everyone by throwing more bits to the puzzle ;-P :

Take into account that ToC ds not refresh itself; it is only updated manually (cf. bug 44448). So *possibly* that could justify the proposed change - like "opening files should retain the cached data, making sure old documents open as they were created, and manual update would allow take advantage of new behavior".

In *this* way, the interoperability issue would also likely become not that big: opening external formats, we also use cached ToC data; updating ToC changes it anyway; and when a LibreOffice document is edited using the proposed method of showing empties, the user would likely already fix that, so there would not be a "It shows here, but not there" problem.

Mike, why doesn't ToC show empty heading s now? Cannot make a link out of nothing?

That's one reason. The other is that Word also does the same, so the current behavior is compatible for users migrating from MSO.

It's obviously possibly to make a link to an empty paragraph, as it works with Navigator (tdf#149288), and the latter uses the same machinery. So IMO the other reason Miklos mentioned may be the only one (or, rather, more generally "that would be the users' expectation" kind of reason).

So let's keep the status quo: ToC follows MSO and hides empty headings while the Navigator shows the mistakes.