This is on OS X 10.10.4 and LibreOffice:

Version: 5.0.0.1
Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
Locale: en-GB (en_GB.UTF-8)

Hi Iandol,

Thanks for filing, but I do not see the problem in a random document on Ubuntu 32 bits.
Do you have a sample document, or is it with all documents?
Ciao,
Cor

Created attachment 116907 [details]
screenshot

This is with any document or a new document. This has got much worse with a longer uptime, restarting LO doesn't seem to improve it. I assume this must be OS X specific.

I still see this in RC2 (after a restart):

Version: 5.0.0.2
Build ID: a26d58f11b99b6aeddf7f7884effea188cc6e512
Locale: en-GB (en_GB.UTF-8)

I suppose we need some other OS X users to see if this is local to my machine...

I have a heading style set to as small of a font size as possible and with a white color so that it will create a bookmark when the document is exported to a pdf but does not show in the main text.  Of course seeing a tiny line in the preview doesn't help much in trying to figure out what that style is doing.  
That may be what is happening it the attached example.  My style name looks exactly the same as in the example, so I can confirm a way to get exactly what is shown. Having a preview, without having a way to disable it, is a poorly thought out "feature."  A sample document is attached.

Created attachment 116961 [details]
sample document

Actually, to get exactly what is shown in the example, the font color should be black so that the line shows up in the list even though it's not selected.

Actually on testing (I used your test.odt) you have a small font which causes this. In my case it is the reverse. I realise the styles that are disappearing are all descended from Heading, and anything >16pt will disappear. I took your test ODT and modified your Heading 1:

1. Make the font blackish to see it.
2. Set it to 130% (base is 14pt so this becomes > 17pt) size from 5%.

And the style name also disappears from the list. Your styles are using Dejavu serif, different to my base font so it is happening to at least 2 different fonts.

So I think that this bug is triggered by fonts too small or large which are not correctly rendered.

Additionally you shouldn't be able to set a font to be white and it disappear from the list, this should have a trigger to outline the font or change the background or force a slight grey colour or something...

Created attachment 116969 [details]
style test odt

This is the slightly modified document where I set the size of Heading 1 to 130% and colour to black. It disappears from list on my machine.

Note the commit that added this feature is:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca95307638207db5d662059aa61594151a13e927

and tomaz.vajngerl@collabora.co.uk the developer.

@tomaz: the people did a nice testing here. Can you please have a look? Thanks,
Cor

(In reply to Iandol from comment #9)
> So I think that this bug is triggered by fonts too small or large which are
> not correctly rendered.

Thanks for shepherding this Cor! Out of curiosity, do you see the problem on Linux with the test documents?

I should have mentioned that I am using Linux, so this is a cross-platform problem.

Ah, OK David -- do you see the problem I see if you make the font size >17pt?

@Iandol, No I do not see that issue with enlarged fonts.  On my system it merely stops increasing the size at some point.  It looks like on your system, instead of stopping at the maximum size, it defaults to the minimum size.

I did notice another problem though.  Since the color was set to black instead of automatic, when the the style is selected, the characters are difficult to read because of the black font being displayed on the dark blue selected background being used by my configuration.  This "feature" really either needs to be removed before it's released as stable or at least have a disable option.

FYI: there is the intention to have this optional in 5.0 release.

5.0 rc3 has been released, and even though there is an option in Tools | Options | LibreOffice | View to disable the preview, it is not working.

(In reply to David from comment #18)
> 5.0 rc3 has been released, and even though there is an option in Tools |
> Options | LibreOffice | View to disable the preview, it is not working.

Hi David, 

I think you refer to preview for font lists.
That is for the drop downs in the toolbar, not in the Styles and Formatting dialog.

Please see my https://bugs.documentfoundation.org/show_bug.cgi?id=91495#c6 as for how I see the situation in general.

Cheers,
Cor

Created attachment 117244 [details]
Heading1 disappears

The exact size the style name disappears seems to depend on the machine, testing with another macbook I found it needed to be > 18pt so I've just increased the size of Heading 1 to trigger this more easily...

Working on Windows 7 sp1, 64-bit en-US with
Version: 5.1.0.0.alpha1+ (x64)
Build ID: 14257152b19c08618a107c6eb0f684de11483da8
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-17_03:23:36
Locale: en-US (en_US)

The "broken" style previews for the smaller sizes being unreadable, and the larger size preview not expanding beyond some fixed percentage for inclusion on the list is also present in Windows, and remains.  But it seems most troublesome in the toggle between font size settings done as percentages rather than points. And of course getting consistent OS X behavior is always a minefield for the devs.

But not sure it is really a bug? Some bounds have to be set or the actual graphical representation of styles on a list becomes useless. And expecting a style with a font formatted white to show against a white panel would be strange.

Anyway ttoggle now provided Expert Configuration org.openoffice.Office.Common "StylesAndFormatting" provides reasonable work around for any customized styles that do not render "correctly" as folks would like as previews. With disabled previews it shows as simple listings of Style (LO system default) in the Sidebar Style and Formatting content panels.

Hope it will be backported early in the 5.0 release.

=-ref-=
http://cgit.freedesktop.org/libreoffice/core/commit/?id=210f42a318cbac62de835ccacbc1fc0e36f713f6

Thank you for the option!  And putting a white font on a white background isn't so strange.  I actually learned that trick from someone else.  How would you propose setting a heading to be used as a bookmark in a pdf file if you didn't want that bookmark to show up in the document?

Created attachment 117307 [details]
screenshot

Heading 1 is 19pt (and the text has disappeared) and heading 2 is 18pt and is visible. This is a bug. I think there should be a min and max size limit, and not just resetting to the smallest size.

On OS X 10.10.3 en-US with master
version: 5.1.0.0.alpha1+
Build ID: 122a15f4a6c09d35db58fe3a7b943b5ea79cbe65
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-07-09_23:56:41
Locale: en-US (en.UTF-8)

Non-rendering of oversize Style previews remains an issue in OS X builds of master/5.1.0alpha1+

When editing attachment 117244 [details] -- StyleTest.odt test file, when style is modified if I switch from pt over to %, the Heading 1 style preview drops to place holder when font is set above > 215%, e.g. 220%. Changing back to <= 215% renders a visible style preview.

Unfortunately the bug 91495 provided Expert Configuration StylesAndFormatting work around is not yet available on an OS X TB build to test suitability.

The rendering is really broken if they styles are viewed any other way other than Hierarchical.  

Create a new document.  Set to view only Applied Styles.  In the character, frame, and list styles there are no styles listed, even though the Default Style should be shown.  

When styles are listed using any filter other than Hierarchical, then there is extra spacing between the names.  The only time the styles seems to be listed correctly is if they are listed with the Hierarchical filter.

I should have checked earlier versions before posting.  It looks like the Default Style was never displayed for character, frame, or list styles when using the Applied Styles filter and there are no other styles being used.

So the problem I see it the extra spacing between the style names when something other than Hierarchical is select.

The spacing now seems to be correct in 5.1.

In doing some further testing, it looks like the application needs to be close and re-started for the spacing to be correct when filtering by styles other than hierarchical.

This now applies also to version 5.0.1, which now also has the option to disable the preview.

On OS X 10.10.3 en-US with

Version: 5.1.0.0.alpha1+
Build ID: ab777c9cecc7377a7bdb0cda2eb26412021c7a73
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-07-21_00:37:19
Locale: en-US (en.UTF-8)

Style preview still poorly rendered above 220% -- sample of the style renders as just an em-dash in the Sidebar content panel.

Able to disable display of style preview--bug 91495, so reasonable work around.

This is probably related: https://bugs.documentfoundation.org/show_bug.cgi?id=96242

Adding keyword 'bibisectRequest'.

*** Bug 96242 has been marked as a duplicate of this bug. ***

Adding keyword bibisected and bisected as the commit has been identified
Adding Cc: to Tomaž Vajngerl

This shouldnt be considered a regression as these same broken style previews are in the character and style dialogs since OOo and in the paragraph style combobox in the toolbar since 4.0, but are only being noticed now in the sidebar because Tomaz enabled previews in the sidebar, where previously they were disabled. Luckily those having problems with these sidebar previews can disable them (bug 91495) and can easily enable/disable them in the sidebar in 5.3 (bug 93845).

Attachment 116961 [details] has Heading 1 set to 5% size and white, so firstly it being white would of course mean that it wont be visible on any of the preview areas which have a white background and secondly it being so small also means that it wont be visible.

So UX has to decide what to do about such scenarios. I'd suggest that previews should always show text at a minimum of 6pt (aka 43%) and show black text unless their is a highlight color (this works in the dialog) or an area fill color (this works in the toolbar and sidebar).

*** Bug 97672 has been marked as a duplicate of this bug. ***

*** Bug 97905 has been marked as a duplicate of this bug. ***

*** Bug 98031 has been marked as a duplicate of this bug. ***

This issue is kind of a duplicate to bug 115507, which was closed as WFM. the sidebar is not meant to be a full preview. It just lists the styles with name, color, size as in the document. And very a small font size was accepted as not readable.

(In reply to Heiko Tietze from comment #39)
> This issue is kind of a duplicate to bug 115507, which was closed as WFM.
> the sidebar is not meant to be a full preview. It just lists the styles with
> name, color, size as in the document. And very a small font size was
> accepted as not readable.

This bug isnt limited to just previews in the sidebar.

Nothing changed in Version: 6.4.0.0.alpha0+
Build ID: f76dbe5dc581845996a8bd5f5109c5e2ff5a27b0
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-09-09_05:13:31

The name of the Heading 1 style is still unreadable in the sidebar when using attachment 116961 [details]:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 06ac18e6302d666c363740644a7976e8c22d1113
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

What do you expect from 5% font size and/or white font on white background?

We could use a minimum font size of 9pt, or the like, on the Stylist and ignore values below. But is this really wanted? I mean there might be a reason to reduce the font size to an unreadable value. 

(We have some maximum value right now, btw.)

When it comes to colors we decided to show what is configured. So white on white produces a white-out same as black on black (or very dark). Using "Automatic" shows the font either in white or black depending on the brightness of the background.

I try to set readable fonts and font sizes, but the ones in that sidebar are even smaller and even harder to read than in preferences. Even if I reduce resolution to 720p on a 24" display, some of the text is less than 2mm high.