Bug 50380

NOT reproducible with "LibreOffice 3.5.4.2 (RC2) German UI/Locale [Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18] on German WIN7 Home Premium (64bit) 
Also not with 3.4.5

I created 2 small example tables 1 cell and 3x3, added tab stops to the cells and some characters, applied striekthroug / bold - Drop Caps / strong emphases. All wihout influence to tab stops

@reporter:
Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list
Please:
- Write a meaningful Summary describing exactly what the problem is
- Attach a sample document (not only screenshot) or refer to an existing 
  sample document in an other Bug with a link.
- Attach screenshots with comments if you believe that that might explain the 
  problem better than a text comment. Best way is to insert your screenshots
  into a DRAW document and to add comments that explain what you want to show
- Contribute a document related step by step instruction containing 
  every key press and every 
  mouse click how to reproduce your problem (due to example in Bug 43431)
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
  -- what EXACTLY is unexpected
  -- and WHY do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your PC 
  -- concerning your OS (Version, Distribution, Language)
  -- concerning your LibO version (with Build ID if it's not a public release)
     and localization (UI language, Locale setting)
  –- Libo settings that might be related to your problems 
    (video hardware acceleration ...)
  -- how you launch LibO and how you opened the sample document
  -- everything else crossing your mind after you read linked texts

Even if you can not provide all demanded information, every little new information might bring the breakthrough.

May be you can test <https://www.libreoffice.org/get-help/bug/> for submitting bug reports?

Please report Bugs with stats UNCONFIRMED

@reporter:
please ingnore my nonsense test comment, but contribute requested information

Created attachment 62185 [details]
This one works.

Created attachment 62186 [details]
This one doesn't.

Sorry, I'm having trouble with this system. The files I just uploaded are two examples of the situation. The tables I'm talking about are not ordinary tables, but rather the automatically-populated Indexes and Tables type of tables (Insert > Indexes and Tables...)

In the first file, you can see I've created a table of contents for which level-one entries have two different character styles applied (there's a second style applied to the tab stop itself). The second file is the document I'm working on, in which the bug appeared. When I applied a character style to the tab stop, it became corrupted.

You will not see the bug appear right away when you open the second file. To replicate the bug, open the second file and edit the table of contents. Go to the tab labeled "Entries." Apply the character style "_TOC: Chapter heading entry, no italics" to just the tab stop on level-one entries in the table. Voilà! The tab stops with all their periods disappear, and a number appears immediately after the entry. There is no way to restore the tab stop without deleting the level-one tab stop and re-adding it to the formatting.

Comment on attachment 62186 [details]
This one doesn't.

Heh, whoops, I left a password in that document. Doesn't matter, I changed it, and anyway if you want to log into my choir's Twitter account you must be *really* bored.

Interesting update: I deleted the character style that I was using for the tab stop, created a new character style from scratch, and used that instead. Now the tab stop appears styled properly. So it appears there was something wrong with the character style I'd defined. There's still a bug here, but this narrows it down (it's not a corruption of the entire file).

Also, can we take a second just to appreciate the developers' work on the table-of-contents system? The fact that you can have automatically generated tables, with such control over what constitutes an entry and how they are displayed in the table, is stunning. It's a really wonderful part of Writer. Thanks, dev team.

I will mark this one INVALID because it's simply too expensive to find out what the problem is. 

@bram.wayman:
I gave you detailed hints how to co contribute a useful, unfortunately you ignored the hints completely. A general hint: do not describe what you experience, describe what we have to to to reproduce your problem. And comments like "works" and "does not "work" are not useful, we expect something like "I expect to see xxxx" because "yyyy" but I see "zzz" or similar.

Al we need a sample document and a simple instruction
1. open
   > you see
2. Select string "xyz" in Heading so and so
3. <f11>, Apply (charaqcter?)style "abc" from list
  Expected: this and that
  Actual: something different

Please feel free to reopen this bug if you find out that the problem still exists with the current stable LibreOffice version (3.6.6 or later) and if you can contribute REQUESTED additional information due to <http://wiki.documentfoundation.org/BugReport> (especially BugReport Details)!