Created attachment 116872 [details]
Heading 1 is broken here for example
For some styles, the style preview is broken and all that is shown is a - thus the user can't see what that styles name is!
This is on OS X 10.10.4 and LibreOffice:
Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
Locale: en-GB (en_GB.UTF-8)
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?
Created attachment 116907 [details]
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):
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]
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:
and email@example.com the developer.
@tomaz: the people did a nice testing here. Can you please have a look? Thanks,
(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.
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.
Created attachment 117244 [details]
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: 220.127.116.11.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.
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]
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
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
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 93844 has been marked as a duplicate of this bug. ***
*** 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.
** Please read this message in its entirety before responding **
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!