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: 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 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! Warm Regards, QA Team MassPing-UntouchedBug
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
Dear Iandol, 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 https://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! Warm Regards, QA Team MassPing-UntouchedBug
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.
Dear Iandol, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Iandol, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp