Created attachment 115025 [details] proofpic Since some point in linux 4.* series (definitely in 4.3 and 4.4) the UI font in menubar is not affected by 'font substitution' setting in 'tools->options'. I'm setting the substitute for 'Segoe UI', and the menus dropping down from menubars, and everything else is in substituted font, but main menubar items are not. Looks bit silly :)
I can't find, where I could change the font family for menus. Please give detailed steps on how to do it. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Because you can't set the font in main menubar (!) separately, and the erroneous behaviour of same is what I'm filing a ticket about. Go to 'Tools->Options->LibreOffice->Fonts', set substitution for 'Segoe UI', check 'always'. Verify that in 'Tools->Options->LibreOffice->View' you have unchecked 'Use system font for user interface'. Now you should have (as I have) substituted font in all menus, dialogs etc., but not in the main menubar (!) itself, like it is shown on proofpic.
Ok, this feature was removed: https://wiki.documentfoundation.org/ReleaseNotes/5.0#Feature_removal_.2F_deprecation The obsolete, StarOffice-inherited option “Use system font for user interface” was removed. LibreOffice will always use the system’s font to display its user interface element
Well... Remove this and remove that. The feature was useful on linux, as who wants to dig in all those gtk/qt/whatever entrails? I've been easily setting the easy on eyes font in OOO/LO 'for ages'. Thank you, team, for taking this from me. And I'm almost willing to bet the 5.0 series will be even bigger in the sense of diskspace and cycles -- not being bigger in the sense of functionality.
(In reply to Yury from comment #2) > Go to 'Tools->Options->LibreOffice->Fonts', set substitution for 'Segoe UI', > check 'always'. Verify that in 'Tools->Options->LibreOffice->View' you have > unchecked 'Use system font for user interface'. What font did you place in the Font field? (In reply to Yury from comment #4) > Well... Remove this and remove that. The feature was useful on linux, as who > wants to dig in all those gtk/qt/whatever entrails? I've been easily setting > the easy on eyes font in OOO/LO 'for ages'. Thank you, team, for taking this > from me. I believe it should be simple for you to change the system-wide font on linux and doing so would change not only the menubar but also the menubar menus. Just as a reference, this functionality was changed with bug 87016 and i think having the ability to change it on linux may be beneficial as the font situation on linux isnt the best and it would be beneficial for bugs like bug 70857, where not being able to uncheck this causes sluggishness in the UI. Will through it to ux-advise to let them give their input into it.
(In reply to Yury from comment #4) > Well... Remove this and remove that. The feature was useful on linux I am a Linux user myself, and can hardly believe that removing it affects functionality at all; precisely one of the main features of Linux desktop environments is the ability to change, *globally*, the fonts used by the software programs you use. All of them allow that: GNOME, Unity, Enlightenment, KDE… It doesn’t make sense, at this point on time, to continue supporting a half-baked, inbuilt mechanism to have the same functionality that your environment has. > And I'm almost willing to bet the 5.0 series will be even bigger in the sense > of diskspace and cycles -- not being bigger in the sense of functionality. You’re being annoyingly disrespectful to the hundreds of contributors who are dedicating their time to improve this software project. And it seems you haven’t even dedicated five minutes to read our release notes.
(In reply to Jay Philips from comment #5) > (In reply to Yury from comment #2) > What font did you place in the Font field? Usually, one of the squarish, blackish fonts with easily distinguishable i/l shapes etc., in (in fact, Chicago and Charcoal analogues -- think Grana Padano, Virtue, MacType). I work with OOO/LO texts and formulas a lot, and consider such setup easier on eyes (I use the analogous setup in Firefox, BTW.) Text window is the focus of attention, and UI doesn't get in the way but is readable. This is about the opposite of what's expected of 'system' font, which is used for menus, dialogs, etc., through which we convey our meaning to system. There the 'system' font is the main medium, for all applications in system-wide context, so there are different requirements to it. > (In reply to Yury from comment #4) > I believe it should be simple for you to change the system-wide font on > linux and doing so would change not only the menubar but also the menubar > menus. But I already know I can. :) I chose the GTK system font like 15 years ago, and tug the config along through my homedirs. Same with qtconfig. But in fact, I regret there is no capability in system to change the applications' fonts individually -- and I mean change easily, like it was done on OS/2 20+ years ago. > Just as a reference, this functionality was changed with bug 87016 and i > think having the ability to change it on linux may be beneficial as the font > situation on linux isnt the best and it would be beneficial for bugs like > bug 70857, where not being able to uncheck this causes sluggishness in the > UI. > > Will through it to ux-advise to let them give their input into it. Bug 87016 was somewhat dubiously formulated and got about zero discussion before it was fast-tracked into the code. I didn't know about that urge to remove the option, or I would chime in. Now it seems it's too late.
(In reply to Adolfo Jayme from comment #6) > (In reply to Yury from comment #4) > > Well... Remove this and remove that. The feature was useful on linux > > I am a Linux user myself, and can hardly believe that removing it affects > functionality at all; precisely one of the main features of Linux desktop > environments is the ability to change, *globally*, the fonts used by the > software programs you use. All of them allow that: GNOME, Unity, Which may be considered -- unexpectedly for some, perhaps -- not the optimal solution for the complex problem of UIs (plural) legibility. There was an additional LO functionality on linux, now there is no more. Big cheers to what? > > And I'm almost willing to bet the 5.0 series will be even bigger in the sense > > of diskspace and cycles -- not being bigger in the sense of functionality. > > You’re being annoyingly disrespectful to the hundreds of contributors who > are dedicating their time to improve this software project. And it seems you > haven’t even dedicated five minutes to read our release notes. I am myself a contributor, so don't take that tone with me, please. In fact, don't take that tone with anybody, please, even with non-contributors, even with plain dumb users. To the business. Release notes for this (major) release do not take 5 minutes reading, rather 1 or 2. I've reread them just now, for the sake of argument. I do not believe I see the revolutionary changes there -- and how much will the 5.* installation take on disk? in memory? So, is there anything there on years-long problems with Word format interoperability -- which recently got SHOWSTOPPINGLY worse with #88697? Now I can't send even a moderately complex text with bibliography to the editors requiring word without re-setting by hand all bib entries (and what if they should be numbered?). Formulas in word import/export -- don't get me started. And it is word interoperability (not word UI mimicry) that buys you users, not pretty themes or translations, even. Enough, I think.
(In reply to Yury from comment #7) > Usually, one of the squarish, blackish fonts with easily distinguishable i/l > shapes etc., in (in fact, Chicago and Charcoal analogues -- think Grana > Padano, Virtue, MacType). > > I work with OOO/LO texts and formulas a lot, and consider such setup easier > on eyes (I use the analogous setup in Firefox, BTW.) Text window is the > focus of attention, and UI doesn't get in the way but is readable. > > This is about the opposite of what's expected of 'system' font, which is > used for menus, dialogs, etc., through which we convey our meaning to > system. There the 'system' font is the main medium, for all applications in > system-wide context, so there are different requirements to it. Well i tried what i could but still wasnt able to get the substitution to work. On my Mate desktop the menu font is the 'Application font' and it is Sans 9pt, but setting that to do the substitution didnt work after unchecking using the system font for UI. > But I already know I can. :) I chose the GTK system font like 15 years ago, > and tug the config along through my homedirs. Same with qtconfig. But in > fact, I regret there is no capability in system to change the applications' > fonts individually -- and I mean change easily, like it was done on OS/2 20+ > years ago. Well that is a limitation of the OS and not a feature that other apps provide. > Bug 87016 was somewhat dubiously formulated and got about zero discussion > before it was fast-tracked into the code. I didn't know about that urge to > remove the option, or I would chime in. Now it seems it's too late. Well as stated by Adolfo, it was a decision that the UX team had taken in 2012 and hadnt been implemented. Well the change is an attempt to clean up the options dialog which is quite complicated. (In reply to Yury from comment #8) > To the business. Release notes for this (major) release do not take 5 > minutes reading, rather 1 or 2. I've reread them just now, for the sake of > argument. I do not believe I see the revolutionary changes there -- and how > much will the 5.* installation take on disk? in memory? There are many changes that havent been included in the release notes yet, but will be added closer to the release. 5.* will take up a similar amount of disk space and memory as 4.*. @Stuart, Cor, Heiko: Any input on this issue, as i was thinking to bring it to the design meeting.
(In reply to Jay Philips from comment #9) > (In reply to Yury from comment #7) ... > Well as stated by Adolfo, it was a decision that the UX team had taken in > 2012 and hadnt been implemented. Well the change is an attempt to clean up > the options dialog which is quite complicated. It will remain complicated, even with this option gone. What would you expect to be there -- one checkbox? :) Summing up, there was a convenient feature, now it'll be gone. But what's one more inconvenience? What really would benefit from simplification is fonts' processing. I've browsed the respective part of the LO source a couple of years ago -- wanting to (1) know why raster fonts are not allowed (on linux) to be used as UI font in LO, and to (2) know why font lists in styles have no influence on glyph substitution. And I couldn't make heads nor tails of it. I bet developers are afraid of touching this code, either. :) If you have some say in it, Jay, please, kindly have a look into the (closed/notourproblem) #56076.
(In reply to Yury from comment #10) > It will remain complicated, even with this option gone. What would you > expect to be there -- one checkbox? :) > Summing up, there was a convenient feature, now it'll be gone. But what's > one more inconvenience? Yes i dont think its worth ripping things out of this complicated dialog, but instead to have an easy mode for regular users. (bug 90989) > What really would benefit from simplification is fonts' processing. > I've browsed the respective part of the LO source a couple of years ago -- > wanting to (1) know why raster fonts are not allowed (on linux) to be used > as UI font in LO, and to (2) know why font lists in styles have no influence > on glyph substitution. > > And I couldn't make heads nor tails of it. I bet developers are afraid of > touching this code, either. :) Well the devs are aware of how difficult it maybe to fix such problems, so that is something i leave to them to decide. > If you have some say in it, Jay, please, kindly have a look into the > (closed/notourproblem) #56076. I'm not a dev so i dont really have anything to say about the technical issues discussed in that bug report, but the devs listed in their are quite knowledgeable and have been working on the code for many years.
(In reply to Yury from comment #0) > I'm setting the substitute for 'Segoe UI', and the menus dropping down from > menubars, and everything else is in substituted font, but main menubar items > are not. Confirmed with 4.4.6.1 under Fedora 23. (In reply to Yousuf (Jay) Philips from comment #5) > Just as a reference, this functionality was changed with bug 87016 The commit there only removed the UI part (and it was still possible to use through expert config). What actually removed it is http://cgit.freedesktop.org/libreoffice/core/commit/?id=e2a41b4415f59c2c6a75f40775a19c8ce4cbdb42 (and some follow-up stuff). > and i > think having the ability to change it on linux may be beneficial as the font > situation on linux isnt the best and it would be beneficial for bugs like > bug 70857, where not being able to uncheck this causes sluggishness in the > UI. There is also another request from a Mac user in Bug 94114, and also another use-case in [1]. So if there is a user demand, maybe we can retain this at least as an expert config thing? @Jay: What do you think? [1] http://lists.freedesktop.org/archives/libreoffice/2015-August/069928.html
(In reply to Maxim Monastirsky from comment #12) > There is also another request from a Mac user in Bug 94114, and also another > use-case in [1]. So if there is a user demand, maybe we can retain this at > least as an expert config thing? > > @Jay: What do you think? If reverting it all is off the table, then atleast retaining it as an expert config would be useful for people that need it. It would be useful to also include an easier means of setting the font to be used (i.e. expert config), rather than users having to go into Tools > Options > LibreOffice > Fonts, as i wasnt able to get it working.
(In reply to Yousuf (Jay) Philips from comment #13) > It would be useful to also > include an easier means of setting the font to be used (i.e. expert config), > rather than users having to go into Tools > Options > LibreOffice > Fonts, > as i wasnt able to get it working. There is already - in expert config search for "UI_SANS" (the key is still there, but it doesn't work right now, because the code that used it is removed). The 'font substitution' trick is from the days that expert config wasn't easily accessible to users.
(In reply to Maxim Monastirsky from comment #14) > (In reply to Yousuf (Jay) Philips from comment #13) > > include an easier means of setting the font to be used (i.e. expert config), > There is already - in expert config search for "UI_SANS" (the key is still > there, but it doesn't work right now, because the code that used it is > removed). The 'font substitution' trick is from the days that expert config > wasn't easily accessible to users. So how do I access this expert option, and is it working, actually?
(In reply to Yury from comment #15) > So how do I access this expert option, and is it working, actually? Tools - Options - LibO - Advanced - Expert config.
(In reply to Yury from comment #15) > and is it working, actually? Please re-read my last comment. I explicitly said that it doesn't work. BTW I have a WIP commit locally that makes font substitution work again for UI. I also identified the exact commit that broke the menubar. Sadly I don't have more time to spend on it, but I can give code pointers to whoever wants to take this task.
(In reply to Maxim Monastirsky from comment #17) > (In reply to Yury from comment #15) > > and is it working, actually? > Please re-read my last comment. I explicitly said that it doesn't work. BTW > I have a WIP commit locally that makes font substitution work again for UI. > I also identified the exact commit that broke the menubar. Sadly I don't > have more time to spend on it, but I can give code pointers to whoever wants > to take this task. First, thank you, guys, for helping. I've changed the setting and am already more comfortable. And I'd appreciate code pointers -- leading to the code doing the font face substitution (like, on non-existent glyphs). I have to have odd glyphs in my texts sometimes, and there is this silliness with LO neither showing me the fact of substitution, nor allowing me to affect its functionality. So -- on my unchanging setup -- I might get 'not-existing' glyphs substituted sometimes (which is a quirk, actually), and sometimes I just get substitutions of completely different family altogether. I'm not filing the issue on this. Did this once, got some cold shoulder. I might get lucky with a hack, though.
(In reply to Yury from comment #18) > leading to the code doing the font face > substitution (like, on non-existent glyphs). For this you should better ask on the dev. mailing list. I'm sure there are people there that familiar with this stuff.
** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
The font substitution works correctly and includes the main menu. On a Windows system a substitute for Segoe UI with a serif font--Liberation Serif shows the replacement for the system font. Assume it also behaves on the various Linux DEs
(In reply to V Stuart Foote from comment #21) > The font substitution works correctly and includes the main menu. > > On a Windows system a substitute for Segoe UI with a serif font--Liberation > Serif shows the replacement for the system font. > > Assume it also behaves on the various Linux DEs Sorry that was testing on both Windows 10 and Windows 8.1 with Version: 5.3.2.2 (x64) Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: en-US (en_US); Calc: group