Please update the embedded manifests on sbase, scalc, sdraw, simpress, smath, soffice, sweb, and swriter for win32 builds to the following: <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" > <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel> </requestedPrivileges> </security> </trustInfo> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity> </dependentAssembly> </dependency> <asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>true</dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly> I've disabled the DPI virtualization (which is what the asmv3: section does) on my end and I haven't seen any problems with large font sizes, across all of the dialog boxes I normally use, so I believe that there is no reason not to declare dpiAware. This only affects Windows 7 and up, as Vista and XP do not have DPI virtualization. By declaring it, we will see XP-style font/UI sizing again. (This can also be globally set by the user, or manually forced via compatibility settings for individual executables, but that's not good UX.) Rationale: On Windows 7 and up, setting a large font size forces DPI virtualization on non-DPI aware apps. (See this page: http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx ) This shows up as a very blurry interface as font size increases, whereas declaring it results in a very crisp and usable interface. As screen dot pitch shrinks and the ability to use large fonts on Windows has substantially improved, this is becoming very important.
It is waiting for a gbuild expert, I suppose.
It scales LibreOffice content too. For example it renders horrible font on Impress presentation in fullscreen especially with contribution of Bug – 46817 to that.(I run LibreOffice 4.0.1.2 on Windows7 x64 SP1.) Actually DPI aware should be enabled by default, because developers do not usually program/test with DPI scaling in mind and it can( does in some applications ) thus even cause GUI layout to break.
It looks like (from solenv/gbuild/platform/com_MSC_class.mk) - that if a .manifest file is around - then we will use it already: $(if $(filter Executable,$(TARGETTYPE)),&& if [ -f $(1).manifest ]; then mt.exe $(MTFLAGS) -nologo -manifest $(1).manifest -outputresource:$(1)\;1 && touch -r $(1) $(1).manifest; fi) \ So - (I guess) this is a matter of dropping this manifest XML file in the right place to be used here, and checking it in (right?). Andras - what do you want a gbuild expert for ? :-) I'd love to get this MAB closed ... :-)
$(1).manifest is a generated file (the linker generates it). We need to add an extra manifest file to some targets (to all GUI executables?).
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d044918751da4bbdf87f7fb12382abf6c4068c07 fdo#46553 Update embedded manifest on win32 builds to declare dpiAware The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c905068b9d3b7406d629728e01a5f9460521de8f&h=libreoffice-4-0 fdo#46553 Update embedded manifest on win32 builds to declare dpiAware It will be available in LibreOffice 4.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.