Bug 86973

Perhaps we're misunderstanding, but the problem we see is that when the Writer document is converted to HTML the information about what character is used for each list item is lost... so any CSS hack like what Andras Tamar suggested wouldn't work because the data about what the list item character was would already have been lost.

Setting to NEW.
Lowering severity per: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Solution would be to use this CSS property and image files or SVGs:
https://developer.mozilla.org/en-US/docs/Web/CSS/list-style-image

I've been wondering why this bug hasn't been fixed yet (it seems like it would be very easy to fix!) and see that it's categorized as "Trivial"... this is not correct I think, it should be a "Medium/Normal".

I checked the Bug Triage flowchart linked to above and one of the criteria is "Does it make it harder (or more severely, prevent) a user from doing high quality work"... yes it does! Whenever I open a document in LibreOffice I have to manually inspect all the text to see if the text has been accurately rendered.

Accurate rendering of characters seems like it should be the most fundamental property of a document tool, but this ticket implies that mis-rendering one character for another is not a big deal. But it can be!! For example, it's not uncommon to have nested lists (bullets at one level, diamonds or flowers at another), and when OpenOffice fails to distinguish between them it can (in extreme cases) hide the conceptual organization of the material we are presenting.

And re: my first point; isn't this an easy (trivial??) bug to fix? 

If it is, can the Document Foundation *please* fix this bug so we no longer have to visually compare documents to make sure our new document versions are faithful to the originals!?  

Thank you very much, we do appreciate the good work you do.

Sorry, I left out the most important thing, distinguishing empty (circle) bullets vs. filled in ones when talking about nesting lists... what I get for writing at the end of a long week!

(In reply to d from comment #3)
> If it is, can the Document Foundation *please* fix this bug so we no longer
> have to visually compare documents to make sure our new document versions
> are faithful to the originals!?  

TDF will not fix the bug, see this: https://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/

"The Document Foundation (the non profit organization behind LibreOffice) has zero (yes, not one) paid developer. The implication of this is that there is literally not one single person on the project who can dictate how bugs are fixed."

We might think this is an easy improvement, but as non-developers we are not in a good position to make such an assessment.

I'll add needsDevEval whiteboard so devs will hopefully review this for inclusion to easyHacks.

I logged on the site to report another bug with HTML export (also confirmed, #95860);

if that earns me any good karma, could this ticket please be evaluated to see if it is indeed (as I expect) something that would be very easy to fix (it's pending evaluation for "easyHacks").

Thanks much!

(In reply to d from comment #6)
> I logged on the site to report another bug with HTML export (also confirmed,
> #95860);
> 
> if that earns me any good karma, could this ticket please be evaluated to
> see if it is indeed (as I expect) something that would be very easy to fix
> (it's pending evaluation for "easyHacks").

It would be more effective to find some local C++ developer, buy drinks to them and coax them into promising they will fix this.

Migrating Whiteboard tags to Keywords: (needsDevEval)
[NinjaEdit]

Just realized there is a previous report and now a developer interested in solving it.

*** This bug has been marked as a duplicate of bug 66822 ***