| Summary: | Update embedded manifest on win32 builds to declare dpiAware | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Emily Bowman <SilverbackNet> |
| Component: | LibreOffice | Assignee: | Andras Timar <timar74> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bjoern.michaelsen, dtardon, michael.meeks, petr_kraus, timar74 |
| Priority: | medium | ||
| Version: | Master old -3.6 | ||
| Hardware: | Other | ||
| OS: | Windows (All) | ||
| Whiteboard: | target:4.1.0 target:4.0.4 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 44446 | ||
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. |
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.