And I can't find any discussion or comments about this matter.

I think there are people using this option, so deleting it in options and even worse in expert configuration, doesn't look too much fine.

Believe that was Caolán's decision in

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ec950f8ebb2745ccff2275dcc09d2034cd73dfeb

the feature looks to be refactored out.

And the associated Help was updated with
https://gerrit.libreoffice.org/#/c/27754/

https://cgit.freedesktop.org/libreoffice/help/commit/?id=0eb754e971171c3a0fe76419a9830462d2958066

Yeah, it was deliberate. For the specific use case, does it not make more sense to enlarge the font size of the whole desktop and not one application within it ?

(In reply to Caolán McNamara from comment #3)
> Yeah, it was deliberate. For the specific use case, does it not make more
> sense to enlarge the font size of the whole desktop and not one application
> within it ?

No, a desktop change is more complicated and has to be reverted each time because a PC in a classroom will be used by another teacher with a different subject in the next lesson. The font scaling of LibreOffice is my personal user setting and does not affect others and will still be there in my next lesson.

The problem still exists in Version: 5.3.0.0.alpha1+
Build ID: 8a796410ec8f440b4163b15b928347c499da7a8f
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-20_23:07:21
Locale: de-DE (de_DE); Calc: group

Hello Thomas, are you sure? This is not about icon size, but about the font size of the menus.

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

Hi, Caolán. This option was removed in vain. Please, return it in LO. Customize font for OS and customize GUI in LibreOffice are two different things, which different use cases. Thx

No, removing the scaling was correct as it was affecting implementation of HiDPI support.

Believe same effect can/should be achieved with better integration with assistive technology "magnifier" tools of the OS.  And that would probably be the correct way for the project to go especially as HiDPI gains prominence.  

Believe transient exposure to a magnification tool, rather than scaling the whole UI, would have more practical application.

(In reply to V Stuart Foote from comment #9)
> No, removing the scaling was correct as it was affecting implementation of
> HiDPI support.
> 
> Believe same effect can/should be achieved with better integration with
> assistive technology "magnifier" tools of the OS.  And that would probably
> be the correct way for the project to go especially as HiDPI gains
> prominence.  
> 
> Believe transient exposure to a magnification tool, rather than scaling the
> whole UI, would have more practical application.

you offer me to buy a new monitor with HiDPI? i don't have a lot of money for this.
There are a lot of people with bad vision, who use scaling of GUI. They all must to save up for the a new monitor?
you, before delete of option for implementation of HiDPI support, make first good customization of GUI.
Or we create LibreOffice not for users, and for developers?

According to what Stuart wrote, this looks like WontFix?
There should be either that, either decision how to resolve

From UX perspective, I do not see requirement to restore this.

(In reply to V Stuart Foote from comment #13)
> From UX perspective, I do not see requirement to restore this.

from usability for average users I see requirement to restore this.

I was using this to increase the font size to make screenshots easier to read.
Try documenting the navigator with any clarity with that tiny type.

Upscaling a screenshot is not an option as it even further reduces the quality (which is already bad enough).

My vote is bring it back.

Just thought I might chime-in on this as I actually use this feature.

I think that the UI scaling feature remains relevant with the types of monitors in use today.  According to http://www.eizo.com/library/basics/pixel_density_4k/ HiDPI displays for computers have been offered since 2014 so even if such displays render this feature obsolete it will years before such displays are in the majority.  

With the average monitor in service today the various screen magnifying tools can produce mixed results where some things improve but others degrade.  On the other hand, the LO UI scaling feature and zoom feature work very well.  I even reported  bug 101371 related to this mainly because I think this is a quality feature worthy of continuation and maintenance at least until the next generation of display technology becomes common.

Also, ironically, 5.3 has added an scaling option for the sidebar icons.  Surely, if scaling for that UI component is important than it must also be important for the text menus. Text menus are important as they provide a level of program explore-ability "in plain English (or other language)" not possible with unfamiliar icons.  I beg for a reprieve for this feature :)

Magnifying, zooming and font scaling is up to the OS/DE. What other major program provides such a feature?

> What other major program provides such a feature?
Exactly!!
This is a great feature not commonly found in other office software.  It allows the flexibility to configure the LO UI text independently of the OS/DE text which might be desired for any number of reasons. Choice is good. Among the key reasons I use Calc over Excel is that Calc offers a higher level of UI options and easily available customization.

Again, it was removed because it was poorly implemented in source/UI and was interfering with implementation of support for HiDPI.

Yes it could possibly be "restored", but better to redesign and implement a solution that is less of a patchwork and supportable with emerging graphics.

@Caolan, Kendy?

(In reply to Heiko Tietze from comment #17)
> Magnifying, zooming and font scaling is up to the OS/DE. What other major
> program provides such a feature?


Operating system global scaling is rarely a viable option because it has unintended or bad results on too many applications. Applications like Microsoft Word work well because they are created by the same developer and therefore well integrated with the OS zoom features. Other applications, not so much.
And often users don't want to scale everything in the OS (like me).

First applications that came to mind because I use them both ...

Adobe InDesign - UI Scaling setting - allows user to set the interface at 100%, 150%, or 200%.
This enables their users to make the UI scale choice based on the size and DPI of their own display.
Same with other Adobe products.

Vivaldi browser (based on Chrome) - User Interface Zoom setting - scale anywhere between 50% to 200% in 5% increments.

Many applications provide 3 sizes of icons - Inkscape, AutoCAD, Solidworks, etc.


With all the different devices now, the ability for users to set the scaling for the interface would seem to be a requirement.

While the current menu scaling in v5.2 may not be optimal, it is better than nothing.

OK, we'll make this an enhancement of suitable priority.

If a dev wants to pick it up--IMHO it is worth doing, but not at the expense of other more pressing facets of the GUI for HiDPI desktops and mobile devices. Expect doing this correctly to reach all elements of the UI could be quite challenging.

But this might provide framework for implementing other useful scaling and zoom features, for example bug 105610.

(In reply to V Stuart Foote from comment #21)
> OK, we'll make this an enhancement of suitable priority.

Please also remove needsUXEval when you think it's done. 

Besides the doubted use case it's hard to believe that such a feature outperforms what the OS/DE can do, across various platforms. Better we make sure the OS features work well if there is no problem with Word on Windows but LibreOffice.

(In reply to V Stuart Foote from comment #9)
> No, removing the scaling was correct as it was affecting implementation of
> HiDPI support.
> 
> Believe same effect can/should be achieved with better integration with
> assistive technology "magnifier" tools of the OS.  And that would probably
> be the correct way for the project to go especially as HiDPI gains
> prominence.  
> 
> Believe transient exposure to a magnification tool, rather than scaling the
> whole UI, would have more practical application.

It was affecting implementation of hidpi?  Why not leave it in until you can actually support hidpi?  In v5.3, hidpi support is terrible and incompatible with the built in scaling of Windows.  I relied on that setting to adjust the UI of libreoffice because it's the only application I run that doesn't scale nicely out of the box with the Windows scaling setting.

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

I am a teacher of Computer applications.  We use a very large variety of computers (desktops, laptops, virtual machines).  The ability for students to work together is greatly enhanced by scaling.  They can see each others formulas so much better. 

I am now forced to revert to 5.2 till this is solved.

PLEASE bring back the Scaling option in the UI as it is a fantastic feature.

adding me cc

Adding to the cc list as well.

This annoys a lot. It's ok since I use Debian and we're still using the 5.2 branch, but when I use other distros that have the 5.3 branch it's unusable.

My real issue is the icons, though. They look just broken.

(In reply to André Brait from comment #31)
> My real issue is the icons, though. They look just broken.

Under Tools > Options > View you can control the icon size.

(In reply to Heiko Tietze from comment #32)
> (In reply to André Brait from comment #31)
> > My real issue is the icons, though. They look just broken.
> 
> Under Tools > Options > View you can control the icon size.

I've tried that. The icons just look broken in different sizes. I'll post a screenshot as soon as I can get my hands on a live distro with 5.3.x. Kinda like if they had been upscaled by a factor of 1.5 using nearest neighborhood but in a wrong manner.

In 5.2, they look normal.

Created attachment 134865 [details]
manjaro xfce linux font size difference

Hi guys,

I understand that this was causing problems, because of its poor implementation, but...

Please, please, please, re-implement it!!!

LO font size is currently smaller that my desktop font size (see ss)

The font size difference is not that great, but it is enough to bother my aging eyes :-(

I'm on a manjaro xfce linux box, running fresh

(In reply to Spiros Georgaras from comment #35)
> LO font size is currently smaller that my desktop font size (see ss)

That's clearly NOTOURBUG, please check your theme. I'm running LXQt with three places to tweak the font: qt5,qt4,LX, where qt4 is responsible for the kde4 variant of LibreOffice (we do not have a Qt5 binding yet).

It looks like you are right!!!

and thank you for your reply; it pointed me to the right direction!!!

I installed lxappearance, but changing the font with it made no difference...
But then, when i changed the font form xfce native app, LO font changed too!!!

So, yes "That's clearly NOTOURBUG"

Sorry for the noise...

(In reply to Heiko Tietze from comment #36)
> (In reply to Spiros Georgaras from comment #35)
> > LO font size is currently smaller that my desktop font size (see ss)
> 
> That's clearly NOTOURBUG, please check your theme. I'm running LXQt with
> three places to tweak the font: qt5,qt4,LX, where qt4 is responsible for the
> kde4 variant of LibreOffice (we do not have a Qt5 binding yet).

So Libreoffice is supposed to follow the system font size properly? Is this just with the "kde version"? I use the gtk2 "version". It does not work properly - fonts in some places are a very different size to others. It is most noticeable with a very low dpi and huge fonts (try setting your display dpi to 21 and your gtk font size to 52 to compensate). It almost seems like the dpi is only being taken into account in some places but not others.
This has caused desperate people to resort to workarounds like this: https://ask.libreoffice.org/en/question/71652/how-to-change-font-size-for-dialogs-not-just-menus/

The power of this scaling feature to me is that you can move between any system/display and with one simple setting all your documents now display in a standard way with all your other systems/displays.   The coding might have been a compromise, but it’s worth a compromise.  Kudos to the guys that originally saw the value of this and got it done and made it work so well for so long.  Job well done.

Frustration makes the wine taste sweetest, the truth most bitter.

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

My apologies, but do the decision-makers even understand the issue raised here (and in #67372)?? For I, for example, did not understand at all the reason for closing #67372 (which, incidentally, is actually NOT a duplicate of this #101646), and I do not actually understand the argumentation for these options removal.

I *believe* the end-user *might* "legitimately" wish to independently change UI font face AND UI font size AND the scale of UI elements, to better suite one's current requirements on application *usability*.

The bulk of actual work is done in applications, not in desktop environments. And even applications may differ w/r to their requirements for the text display. 

When I'm working with a text or a diagram, I don't even get to see the desktop space, as the app's space is maximised. The OOO is multi-platform, I might work as a guest, with a portable installation, etc.

Now, one actually must have legible text in Writer/Draw menus and dialogs, as those are used frequently, as opposite to, say, web browser. (and no, countless toolbars or whatever they are called now--stripes? ribbons? do not decisively help here; I have many of those switched on, but only for addons; BTW, new LO icons are rather indistinguishable, both from each other and from background)

Also, in OOO you might want to make the graphic parts of dialogs (say, color or hatching samples) bigger, without tying those changes to the text size. Or you might want different UI font face and/or size. And you might want to make those changes just for the brief period, e.g., for the screen-cast, or when your eyes are tired, or when you work in sub-optimal lighting conditions, etc.

Now, I'm a OOO user with about 20 years of experience, principally doing lots of text with graphics. But I do not participate in the OOO development. Does my opinion actually count?

(In reply to Yury from comment #42)
> My apologies, but do the decision-makers even understand the issue raised
> here (and in #67372)?? For I, for example, did not understand at all the
> reason for closing #67372 (which, incidentally, is actually NOT a duplicate
> of this #101646), and I do not actually understand the argumentation for
> these options removal.
>...

bug 67373 was dragged out of WFM status for a user complaining of Calc input line font size--that is exactly bug 106521 already dup'd here. As noted in #67372 refactoring needed to restore UI control to scale menus and dialogs independent of OS/DE control is a substantial undertaking. It was stripped out to support OS/DE control needed for emerging DE (Waynland, gtk3, etc) as well as for HiDPI; restoring it requires NEW development effort.

(In reply to V Stuart Foote from comment #43)
> [..] restoring it requires NEW development effort.

Given the number of discussions scattered in the forums, and bug report duplicates here, all pointing in this direction, it seems clear that many people are affected by the issue.

The question is: given the large number of cases and arguments provided by users, would a new development effort be worth?

(I would argue that's the case)

Windows UI scaling is neither clean nor helpful; it enlarges EVERYTHING, not just the App UI. Even if I do enlarge the fonts alone (which is possible in the OS), that enlarges ALL the fonts, not just the font of the formula bar (which is truly what I need; 9-pt Segoe UI ... &*^*@#$%^!!!).

Currently I'm using a 3rd party utility (from Wintools) to change a category of fonts (this has some side effects, which I can live with) to make the formula bar usable.

The ability to scale the UI separately from the data display, which I understand went away for reasons, was a highly useful setting, and I'd appreciate it being returned to us users in some way, shape, or form.

I think scaling should be pursued as a set of settings. Menu, toolbars, input boxes, default font sizes, and so forth. In fact, if LO copied Excel's choice, that the default font size for a new spreadsheet is the default input font size, that wouldn't be horrid.

Thanks for all your work in development, btw; don't want to minimize that.

This regression highly impact accessibility because making user able to increase size of the interface was a great advantage of LibreOffice compared to Microsoft Office. Also as I understand, LibreOffice design team seems to want to make LibreOffice customisable and adaptable to the user needs.

Best regards,
Alex.

(In reply to Alex ARNAUD from comment #46)
> This regression highly impact accessibility because making user able to
> increase size of the interface was a great advantage of LibreOffice compared
> to Microsoft Office. Also as I understand, LibreOffice design team seems to
> want to make LibreOffice customisable and adaptable to the user needs.

@Alex, this was a conscious developer decision to prune code of an unsupportable feature--in effect for the 5.3, 5.4, 6.0, 6.1, 6.2 and now 6.3 major releases. 
We can not reasonably now call it a regression as it is long gone.

Yes it would be a good enhancement, and worth reimplementing. And, yes it could be considered an Assistive Technology for our low vision users, but best done in context with other needed improvements (like bug 105610).

Refactoring to reimplement UI scaling in a modern fashion (with HiDPI and render engine support) would be a substantial development effort.

I recently updated from 6.1.4 to 6.3 rc2 (Debian XFCE).  Now my formula bar font appears to be ~12 point, considerably larger than the previous version.

And while I completely understand why the comments above are asking for a larger font, I actually now want my old style back, as the new font and size appears ugly on my screen.  As far as I can tell, it is *not* pulling the information from my system UI in any way, as it matches nothing else in my system display nor in the Libreoffice interface.

Could we please just have the option to set the font & size of this bar?  Even if no other scaling is implemented (I understand the arguments against it above), is there a technical reason that this cannot be user set in isolation?  Obviously it can be changed at some stage during software build, so where exactly is it being set?

Hi bchemnet,

I assume you are still using XFCE 4.12 based on GTK2? Since the GTK2 VCL toolkit is deprecated for LibreOffice, TDF won't maintain this old branch. Please migrate to the GTK3 toolkit instead.

Good news ! XFCE 4.14 based on GTK3 has been released some times ago. Just install it from the sid or backports repo and please let us know if this helps.

Regards,

Changing enhancement priority to 'high' since the number of people in CC is higher than 20

William - I can confirm that the font size issue seems to have disappeared when I switched to XFCE 4.14.

Please add keyword needsUXEval and CC libreoffice-ux-advise@lists.freedesktop.org if input from UX is needed.

I'd also benefit from this change. Note: not using any "Desktop Environment", just a traditional X window manager. It is very annoying to have UI text almost too small to see while I can arbitrarily scale content using the zoom slider.

Someone on SU did come up with a workaround involving installing libreoffice-gtk3 and setting GDK_SCALE, which is an improvement over trying to read tiny text in the menu bar, but not a great one and could go away at any time AFAIK.

What makes LibreOffice so special that you expect UI scaling when all other applications use fix values. 

(Rhetorical question that doesn't need to be answered, just to illustrate my position.)

(In reply to Heiko Tietze from comment #54)
> What makes LibreOffice so special that you expect UI scaling when all other
> applications use fix values. 

But they don't, at least not 'all'. 
E.g., Firefox has 'Theme and font size changer' addon.
Every app where one would expect lots of looking at servicing/helping text (word or spreadsheet processor comes to mind!), there should be an option to regulate that text appearance.

(In reply to Yury from comment #55)
> Every app where one would expect lots of looking at servicing/helping text
> (word or spreadsheet processor comes to mind!), there should be an option to
> regulate that text appearance.

Konsole (terminal application on KDE) can scale the font size of the text but not the UI menu. Exactly as we do. The same for browsers and almost every other application.

Allow me to disagree. 
First, terminal emulators and their "UIs" rather aren't a good case here.

Then, every major browser (Chrome, Firefox) has an option to regulate at least the UI font size, be it through a configuration setting or an addon.

Working in word processor means even more looking at menus - and that procedure should be made as convenient as possible.

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

Firefox allows (a) preferences to set a readable minimum front size, and (b) userChrome.css and userContent.css to set a fixed font size. There are some bugs when rendering web pages.

Now what options does LibreOffice have to set readable user interface font sizes?

(In reply to MarjaE from comment #59)
> Firefox allows (a) preferences to set a readable minimum front size, and (b)
> userChrome.css and userContent.css to set a fixed font size. There are some
> bugs when rendering web pages.
> 
> Now what options does LibreOffice have to set readable user interface font
> sizes?

None. This enhancement is to reimplement User Interface scaling but providing HiDPI support in a modern and maintainable fashion.

Created attachment 175110 [details]
Font-size comparison between LibreOffice and other applications

All other applications show menu bar text approx 7 pixels high in my configuration.  Libreoffice menu bar text is 5 pixels and much harder to read.

This issue affects me significantly.  I just let my system update to Bullseye/Debian 11 and the zoom-interface functionality went away with the switch to LibreOffice 7.  I had always had to use this function in LibreOffice apps because the menu bar text (and various other UI bits) was too small.

All other applications are fine for me, whether they're GTK or Qt or whatever.  Just LibreOffice is too small.  See this for comparison:
https://bugs.documentfoundation.org/attachment.cgi?id=175110

On my system, other applications' menu bar text is 7 pixels high.  LibreOffice's is 5 pixels and too small to read comfortably.  I've set the icon sizes bigger, which takes care of that, but the text in the menu bar and controls is too small.

I'm not sure if my system DPI has anything to do with this.  I have older large LCD monitors with pixels that are much denser than an old traditional 72dpi, but not nearly as high as modern 4k monitors that are >>200dpi.  My monitors are about 135dpi.

However, as I said, all other applications are fine.  It's just LibreOffice that's a problem for me.  So bumping up the whole desktop is not really a solution, as that makes other applications too big.

Any resolution of this issue would be greatly appreciated.

While I don't know what old "Scaling" did for sure, and it is the fact desktop apps uses probably plethora of settings (judging by their look) the fact remains -- LibreOffice is an outlier.

To answer Heiko "What makes LibreOffice so special that you expect UI scaling when all other applications use fix values."

LO so far uses the tiniest font possible (as shown in screenshot posted by Charles) and on top of it, it uses gray background like _no_ other app around. This makes "LO so special".

So it is apparent that LibreOffice uses some cryptic settings/customization and it be more than useful to make it clear what config file is the source of font sizes and background color for LO. It would be minimum so we, users, could at least make LO look like other apps.

(In reply to bantu from comment #63)
> LO so far uses the tiniest font possible (as shown in screenshot posted by
> Charles) and on top of it, it uses gray background like _no_ other app
> around. This makes "LO so special".

Okay, those bugs need to be fixed. But a _variable zoom_ on the UI would be the wrong solution.

Those aren't "bugs", those are "wrong solutions", in fact, not in name.

Guys, did you take a pledge against the "variable zoom in the UI", or what?

People are asking you to spare their eyesight, or at least to not throw out old solutions for that, before something new is even in. There is no "ideology" in that, not as far as I can see.

And you hardly can refer to a "lack of human resources", because somebody is always introducing small "impovements" in the "look".

Wouldn't want to judge the look, but the readability isn't getting any better (highly abstract darker gray symbols on gray background as default, oh well).

Sorry, I didn't mean to imply that only a zoom-UI setting would fix the problem for me.

I would be happy for any solution that let my not-so-young-anymore eyes read the interface/menubar easily.  That could be a small-medium-large text size preference, or even just a fixed size if it was as large and contrasty as other apps are, i.e. 7px black-on-white instead of 5px black-on-grey.

Any solution would be great.

(In reply to Charles C from comment #66)
> Any solution would be great.

From what I understand is that you run a special setup where all applications draw text nicely but LibreOffice not. Mind to file a new bug report with hardware/configuration information?

(In reply to Yury from comment #65)
> Guys, did you take a pledge against the "variable zoom in the UI", or what?

Which application does zoom the UI?

> Which application does zoom the UI?
And if the answer be "none", none should ever do, too?
Is it even relevant? 

But fine, fine. Softmaker's Office does. 
Three sizes of controls and UI text size on a slider. 
All laid out nicely in a separate tab in the options, no messing around with font substitution tables or external configs.

Firefox does (or did, until extensions extinction), via ThemeTweaker addon. (Palemoon still does, same way.)

Emacs does (although not always in a straightforward manner), and I don't intend that to be a joke.

There's at least another one desktop I use frequently, but I won't even quote it, as it doesn't rely on menus and dialogs heavily.

So?

@Heiko

"From what I understand is that you run a special setup"

This question was for Charles, but I see similar effect and I don't have anything special. I see this in openSUSE Leap 15.3 and Tumbleweed (generic/minimal desktop setup). I prepared a screenshot, but since it basically shows the same as one provided by Charles, I didn't attach it to avoid clutter.

All it takes to see is -- install VirtualBox, install Tumbleweed, install for example LibreOffice + VLC + FireFox and compare the menus.

So if the new report is indeed needed...

@Charles

... if you post one, please share the link here, thank you.

(In reply to Heiko T from comment #67)
> From what I understand is that you run a special setup where all applications 
> draw text nicely but LibreOffice not.

I'm not sure what you mean by special setup; I don't have anything special going on here.


> Mind to file a new bug report with hardware/configuration information?

Sure.

Hardware:
=========

x86_64 / AMD64 system
Video card: AMD Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X]
Monitors: 30" 2560x1600, approx 100dpi (had this wrong before)

Software:
=========
Debian 11 / Bullseye
Desktop: cinnamon 4.8.6-2
Libreoffice 1.7.0.4-4

Settings:
=========

System/Cinnamon settings regarding this are all defaults (I think).

Font selection:
  Default font: Sans Regular 9pt
  Desktop font: Noto Sans Regular 10pt
  Document font: Cantarell Regular 11pt
  Monospace font: Monospace Regular 11pt
  Window title font: Sans Bold 10pt

  Text scaling factor: 1.0

Accessibility:
  Large text: off
  Desktop zoom: off


Those are all the settings I've found that seem related.

I'm not sure why LibreOffice's menu bar is rendering 30% smaller text than every other application.  It is, however, suspiciously close to the ration of standard old desktop displays (72dpi) to my displays (100dpi).  Maybe it's calculating text size and assuming "less than 200dpi, it's not high-dpi so don't scale the text" or something.

(In reply to Charles C from comment #70)
> I'm not sure what you mean by special setup; I don't have anything special
> going on here.

Let's discuss it in bug 144784.

Agreed sheet tab font is way too small in Libre Office calc. Would love a way to scale the UI there so I don't have to hold my laptop right up to my face.

LibreOffice 7.1.7.2 10(Build:2)
Fedora 34
Thinkpad t480s

thanks!!

What the hell with LO UI font?! The menu bar follows QT5 style, everything else doesn't! I have 96x96 dpi and completely unusable peace of software because of the tiny font I can't change!

Version: 7.2.3.2, QT5, UNIX platform

Miss the old version.:(

I specifically created an account in this bug tracker to say that I am also affected by this. I am on Linux and LibreOffice draws the UI using its own custom widgets (maybe Java ones?) completely ignoring any system settings. Thus the advice of just scaling the system font does not work for me. The effect I am seeing is identical to third attachment.

(In reply to Janek from comment #74)
> ...LibreOffice draws the UI using its own
> custom widgets (maybe Java ones?) completely ignoring any system settings.

Not true for me on KDE. Changing the font size for menu, for example, affects LibreOffice properly.

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

Why not use SAL_FORCEDPI environment variable? Something like that:

SAL_FORCEDPI=150 SAL_USE_VCLPLUGIN=gen libreoffice7.3

You can tweak the value assigned to SAL_FORCEDPI to fit your need, taking into account the actual resolution of your screen.

Best regards. JBF

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

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

(In reply to Heiko Tietze from comment #75)
> (In reply to Janek from comment #74)
> > ...LibreOffice draws the UI using its own
> > custom widgets (maybe Java ones?) completely ignoring any system settings.
> 
> Not true for me on KDE. Changing the font size for menu, for example,
> affects LibreOffice properly.

Maybe so, but on Kali, i.e. mostly Debian(!) with XFCE, no amount of system fiddling is helping scale. I wish that this didn't have to be a show obstinancy by the developers (and, I'm assuming, their supporters), but this is *not* an esoteric feature only needed by a select few who can be safely ignored!  If I struggle to read the GUI, I'm going to struggle to use the program.  I should note I have at this point several days of searching through menus, googling, and trawling forum posts looking for an answer to why of all programs LO seems to not respect font scaling for my desktop

(In reply to count3rmeasure from comment #80)
> Maybe so, but on Kali, i.e. mostly Debian(!) with XFCE, no amount of system
> fiddling is helping scale.

If you start with "SAL_FORCEDPI=144 libreoffice" it will scale up. Installing the gtk3 or kf5 toolkit does an even better job in integrating the UI in the system look and feel (sudo apt-get install libreoffice-gtk3).

This issue has forced me to learn that libreoffice is hard to beat. I've been looking into alternatives to libreoffice specifically because it appears the developers are refusing to re-integrate this feature. All my other favorite apps allow me to manually change the size of the menu text. Why does it make sense that I can increase the icon size through a menu option, while meanwhile the menu font is still so tiny. I'm using arch linux with suckless DWM. I'm happy to see this thread is still active. I think enough people want this feature back that refusing to implement it is anti-customizability and frankly a little anti-accessibility considering how many people with aging eyesight liked having this feature. Why is menu font size so confusing and troublesome to libreoffice users that it makes more sense to fiddle with your package manager and command line options instead?

(In reply to waylon_darien from comment #82)
> All my other favorite apps allow me to manually change
> the size of the menu text.
Which are those?

IMO, this needs to be closed; and instead, every specific case (like comment 73 for Qt5 having different fonts in different UI elements; comment 80 about XFCE, etc.) need own issues about improper handling of system preferences (bugs in existing VCL plugins, or missing integration for some environments). Any case when LibreOffice doesn't follow system preferences is a bug, so people setting their environment according to their preference, should not need to tweak LibreOffice UI settings personally.

The SAL_FORCEDPI workaround is enough (needs better documenting?) for cases not properly supported for now. The projector argument is IMO not a valid one, because it would apply to any displayed software (so any software would need that configuration?), and actually needs setting the projector's resolution accordingly, so that UI elements have a readable size.

(In reply to Mike Kaganski from comment #84)

> ... Any case when LibreOffice doesn't follow system preferences
> is a bug, so people setting their environment according to their preference,
> should not need to tweak LibreOffice UI settings personally.

Agree with that, however there are substantial Accessibility and other use cases (e.g. preparing documentation by screen capture, or live instruction/demos) where ability for LO to selectively scale class (menu, TB, dialog) of UI elements remains legitimate enhancement outside scope of average usage provided by os/DE scaling methods. As enhancement still valid.

> 
> The SAL_FORCEDPI workaround is enough (needs better documenting?) for cases
> not properly supported for now. ...

Unfortunately SAL_FORCEDPI environment variable does nothing for Windows os/DE (just verified it does not [1]). Documentation [2] indicates support for gtk3 & qt5/kf5 plugins only--so not a global workaround.


=-ref-=
[1] Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

no visible change to UI with default, SAL_FORCEDPI=160, or SAL_FORCEDPI=220 env set.

[2] https://wiki.documentfoundation.org/Development/Environment_variables

unrelated to LibreOffice - but maybe zoomit tool 
https://learn.microsoft.com/en-us/sysinternals/downloads/zoomit might be a more flexible solution for most usecases of enlarged UI fonts in just LO.

to answer Heiko Tietze's question: I was thinking of SMPlayer and Firefox, and
Vivaldi in particular at the time. To your point, those seem to be very rare
exceptions, most GUI apps I've found don't provide this feature. Most GUI apps
are wrong.

The solution for me (and hopefully any other arch users on DWM struggling with
this) was to add this to my ~/.xinitrc file xrandr --output eDP-1 --scale
0.80x0.80 &

To be clear, when I say "this feature", specifically I'm talking about the
ability to do something like this: view > options > UI scaling > [ there's an
input field where you can type a percentage ], you type 150%, and the font size
of the menu "file, edit, tools, etc..." increases.

I'm using arch linux with Suckless DWM (dynamic window manager) as my window
manager.

I understand my distro and window manager of choice aren't plug-n-play
beginner-friendly, but oh my god, while i was troubleshooting this, it would
have been so nice to be able to go from libreoffice, view > options > ui
scaling > 150%. Libreoffice was painful to use for weeks and weeks until I
fixed this issue. Maybe I'm a slow learner, but I was struggling with editing
(in vain) random gtk and qt files and doing dozens of internet searches until I
finally learned I could scale everything with xrandr.

As to Caolán's comment that having this feature "confuses people looking for
hidpi settings", I can tell you that for me and anyone else struggling with
this, it can sometimes be so much more confusing to "fix the entire graphical
environment" than it would have been to go view > options > ui scaling > 150%

Fixing graphical environment scaling issues might not always be painless on a
Ubuntu/Gnome or Mint/Cinnamon either. When people are struggling to fix their
ui scaling issues, maybe it would be nice for them to be able to lean on
libreoffice as one of the few apps they can use without squinting their eyes
until they get the root problem fixed!!

Even without the "it confuses people for this feature to exist" objection, this
feature clearly has other very valid use cases. For accessibility, having more
user-customization, allowing the user to more easily control their own
consumption of the app, seems far more accessible to me than forcing them to
fix 'font too small' by changing settings for their entire graphical
environment.

(In reply to waylon_darien from comment #87)
>
> To be clear, when I say "this feature", specifically I'm talking about the
> ability to do something like this: view > options > UI scaling > [ there's an
> input field where you can type a percentage ], you type 150%, and the font
> size of the menu "file, edit, tools, etc..." increases.
>

In essence that is what the SAL_FORCEDPI environment variable already provides. Works well for the Linux vcl backends, not so much for macOS or Win which fortunately have improved their ability to manipulate the os/DE UI and respond to HiDPI displays and GPUs.

But, believe there is further utility to expanding on the SAL_FORCEDPI approach, just applied with more granularity selectively against specific elements of the LibreOffice UI.

It could be by Tools -> Options -> LibreOffice -> View setting, or more likely via the Expert Configuration dialog.

(In reply to Heiko Tietze from comment #83)
> (In reply to waylon_darien from comment #82)
> > All my other favorite apps allow me to manually change the size of the menu text.
> Which are those?

I my case it is Blender where I use the UI scaling option very often.
There is a short clip on YT, showing how this feature is used:
https://www.youtube.com/watch?v=H2y7qyaBoE8

Here's another perspective.  

The function text size needs to be completely and independently adjustable due to number of common characters that are very similar.   (eg, periods, commas, semicolons, colons, single quotes, double quotes, parens, etc)  Also, the function font, at least in my mind, should be mono spaced.   

At least for me, the fonts everywhere else in the Libre Calc menus are fine as they are.   

Having to adjust OS font size makes all the other apps look horrible.

Right now, LibreOffice *mostly* follows Linux font settings, but ignores MacOS font settings.

I have no trouble reading preferences, and at least parts of Base, in Linux, but have a lot of trouble with the tiny jagged text in MacOS. And Base lacks the zoom options and user-specified font options that make Writer, Draw, and Calc usable.

P.S. Okay, it mostly follows Font Selection settings when using Cinnamon on Fedora. Apparently it has or had trouble with some other Linux settings! Sorry.

(In reply to V Stuart Foote from comment #88)
> (In reply to waylon_darien from comment #87)
> >
> > To be clear, when I say "this feature", specifically I'm talking about the
> > ability to do something like this: view > options > UI scaling > [ there's an
> > input field where you can type a percentage ], you type 150%, and the font
> > size of the menu "file, edit, tools, etc..." increases.
> >
> 
> In essence that is what the SAL_FORCEDPI environment variable already
> provides. Works well for the Linux vcl backends, not so much for macOS or
> Win which fortunately have improved their ability to manipulate the os/DE UI
> and respond to HiDPI displays and GPUs.
> 
> But, believe there is further utility to expanding on the SAL_FORCEDPI
> approach, just applied with more granularity selectively against specific
> elements of the LibreOffice UI.
> 
> It could be by Tools -> Options -> LibreOffice -> View setting, or more
> likely via the Expert Configuration dialog.

SAL_FORCEDPI entirly fixed the problem for me !!! I switched to Debian sid/trixie but am still using Suckless DWM.

I know SAL_FORCEDPI had been listed in these forums before but I somehow missed it. For Linux users, having SAL_FORCEDPI accessible through the settings would be nice, or having it easier to find on google. Maybe this should also be added in the arch wiki somewhere if it isn't.

Obviously this doesn't fix the problem for everyone, and having a universally functional setting would be better, but this fixes the problem for me!! Thank you!