Description: A minor error, but aesthetically and functionally is annoying. The end user will find a malfunction and could abandon the new version by returning to a previous one or, worse, to another software package. Steps to Reproduce: Format -> Character Actual Results: The name of the font is not filtered in the list Expected Results: The name of the font located and selected in the list. Reproducible: Always User Profile Reset: Yes Additional Info:
Created attachment 149588 [details] In two versions and an aesthetic problem with the fields to modify the size of the typography. As you can see, there is a problem with the size of the font fields, font style and font size. It is uncomfortable for work. The size options can not be displayed correctly and it is worse when expressed in percentages.
Hello, I can't reproduce this for 6.2.2.0.0+ and 6.3.0.0.alpha0+ Possibly the problem is gone. Not reproduced for 6.2.2.0.0+ Version: 6.2.2.0.0+ Build ID: ba5e640cc4880ef023b5ea501b1b99e0a3ba25bd CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-6-2, Time: 2019-02-13_04:26:01 Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded Not reproduced for 6.3.0.0.alpha0+ Version: 6.3.0.0.alpha0+ Build ID: 8193e697d286595aa62859011761adeb002244e3 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-02-20_19:53:18 Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded
No, it is valid. But this view only appears when Tools -> Options -> Language Settings -> Languages includes just the Default language setting for a Western language. The Western only language mode has always shown the drop list unfiltered. Checking enabled an Asian or a Complex Text Language or both will toggle the View to a filtered listbox with the whole GUI more compact. Believe this dialog has been "welded", so the field sizes have been changed. The Font name field now seems a bit too wide, while the Style and Size fields are reasonable to their content. Not sure if name can be adjusted (is the width arbitrary, or is it sized for "longest" font name)? @Caolán?
The width of a page depends on the max width of all pages in a dialog so the "natural" width of this page is narrower that what it needs, and its stretched wider due to the other pages. What to do with the extra width then, in this case its assigned to the family name where its "more useful" So its not that the fontname listbox has requested some wide size, it has instead ended up using the extra space available. FWIW I don't buy that the dialog in 6.1 is better because it has spread out the extra space to the other two columns as well. The size column is crazy wide. But what's definitely a bug is the obscured end of the text in the size column, that's not intentional and is too cramped. This seems specific to the "gen" backend used here, the "gtk" f.e. is sized better.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/a212011f37d457092e422cba331ca19394d3d97f%5E%21 Resolves: tdf#123711 measure scrollbar for optimal width It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/c2448e2bcedf0167bd099124e89fe88cbce321fc%5E%21 Related: tdf#123711 make border page potentially narrower It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/c9666ae13d0c5c24e876770fc6458bf41f178a57%5E%21 Related: tdf#123711 better optimal size for highlighting tab It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed the size column in master and made a tweak or two in other pages to make the overall character dialog narrower so there is less excess width that ends up stretching column 1. Backports to 6-2 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/8b07376f70f5e1192d9ac1e97bcf34de7a09a8a2%5E%21 Resolves: tdf#123711 measure scrollbar for optimal width It will be available in 6.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/b3ef6fd488cb2b08488fd61494704755b0800712%5E%21 Related: tdf#123711 better optimal size for highlighting tab It will be available in 6.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 123949 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #11) > *** Bug 123949 has been marked as a duplicate of this bug. *** I still can repro it in Version: 6.3.0.0.alpha0+ (x64) Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
(In reply to Roman Kuznetsov from comment #12) > (In reply to V Stuart Foote from comment #11) > > *** Bug 123949 has been marked as a duplicate of this bug. *** > > I still can repro it in > > Version: 6.3.0.0.alpha0+ (x64) > Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0 > CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; > TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09 > Locale: ru-RU (ru_RU); UI-Language: en-US > Calc: threaded Yes, when dialog is opened with just a Western language enabled (default or from checkboxes in Tools -> Options -> -> Language Settings -> Languages) the view of the listbox of fonts is no longer indexed to the active font. Activating the listbox moves the index. In multi-language view, the list box is not displayed--so shows correct position when activated with the downArrow selection button. The bibisect to https://gerrit.libreoffice.org/#/c/62908/ is probably correct for this facet. The other part of a bad "aesthetic" of the Weld has already been corrected here.
(In reply to V Stuart Foote from comment #13) > Yes, when dialog is opened with just a Western language enabled (default or > from checkboxes in Tools -> Options -> -> Language Settings -> Languages) > the view of the listbox of fonts is no longer indexed to the active font. > Activating the listbox moves the index. > > In multi-language view, the list box is not displayed--so shows correct > position when activated with the downArrow selection button. > > The bibisect to https://gerrit.libreoffice.org/#/c/62908/ is probably > correct for this facet. The other part of a bad "aesthetic" of the Weld has > already been corrected here. Why is this report Resolved Fixed?
(In reply to Roman Kuznetsov from comment #14) > > The bibisect to https://gerrit.libreoffice.org/#/c/62908/ is probably > > correct for this facet. The other part of a bad "aesthetic" of the Weld has > > already been corrected here. > > Why is this report Resolved Fixed? The OP here also filed bug 123949 which is *exactly* the same pair of issues. The Weld "aesthetic" was fixed. Now Caolan's call about fixing the opening TreeViewBox indexing position onto the selected font--or not.