Bugzilla – Full Text Bug Listing
| Summary: | [HiDPI] Help infocenter has a font scaling problem in IE at 200% | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> | ||||||||
| Component: | User Assistance | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | akurtakov, d.gabriel, daniel_megert, develop, eclipse, gongmd, justin, karl, ldubox-coding101, loskutov, niraj.modi, peter, wim.jongman | ||||||||
| Version: | 4.6 | Flags: | akurtakov:
pmc_approved+
|
||||||||
| Target Milestone: | 4.19 RC2 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows 7 | ||||||||||
| See Also: |
https://git.eclipse.org/r/c/platform/eclipse.platform.ua/+/170371 https://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=25d529a89bee8edb82d38a3ec98a6df2ef5a91f2 |
||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Markus Keller
Created attachment 270990 [details]
Infocenter on Eclipse 4.7
Integrated help look pretty bad on Eclipse 4.7. Along with the font problem in the TOC, there are other issues with icons, toolbars and search toolbar.
200%? Meh, that's at least readable. Try 250%! (Dell XPS) ;-) HiDPI's lots of fun huh? I've been dealing with it a lot too (in Swing). (Ever since getting this laptop, funnily enough...) *** Bug 527465 has been marked as a duplicate of this bug. *** *** Bug 553654 has been marked as a duplicate of this bug. *** *** Bug 498094 has been marked as a duplicate of this bug. *** New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ua/+/170371 (In reply to Eclipse Genie from comment #6) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.ua/+/170371 Problem: The Microsoft Internet Explorer (and probably also legacy non Chromium based Microsoft Edge versions) does scale system fonts (for instance "font: icon") much too large on high-DPI displays, if no font size is specified. This affects the Eclipse embedded help on Windows, since on Windows the browser widget currently uses the Internet Explorer by default. In addition, "font: icon" without a font size affects also the Infocenter since different browsers display it in different sizes. On Windows 10, on my computer "font: icon;" without a font size is displayed in Chrome and Edge in the font size 16px, on the same computer it is displayed in IE and Firefox in 12px by default. Firefox and IE use the system font used to label icons, but in Chrome changing the system icon font does not change the font in the browser (note, in Windows 10 the UI to change the icon font and other fonts has been removed, so only the general font size can be set without editing the registry). On the iPad the font size seems to be 14px and on an Android smartphone it seems to be 16px (Chrome) and 12px (Firefox). The original idea to use "font: icon" without a font size to get as close to the system look as possible does not seem to work anymore due to the mentioned IE bug on high-DPI displays and the lack of support of it in Chrome (including Microsoft Edge). Solution: As a compromise, add "0.875 rem" everywhere where "font: icon" and "font: message-box" is used, which is 14px, as long as the default text size of the web browser of 16px is not changed. This will change the font size in most cases, but in each of these cases only a little bit (either +2px or -2px). Related, but not a CSS issue: bug 567640 I like this patch but I can't test on all platforms. +1 for committing and making it available to us with the next build. It is easy enough to revert in case of severe issues. (In reply to Holger Voormann from comment #7) > As a compromise, add "0.875 rem" everywhere where "font: icon" and > "font: message-box" is used, which is 14px, as long as the default text > size of the web browser of 16px is not changed. This will change the > font size in most cases, but in each of these cases only a little bit > (either +2px or -2px). Please provide concrete steps to verify the solution. I don't see immediately any change (I have no HiDPI on Linux), but also I have no idea where to look for it. (In reply to Wim Jongman from comment #8) > I like this patch but I can't test on all platforms. On which platform / browser / DPI have you tested? > +1 for committing and making it available to us with the next build. It is > easy enough to revert in case of severe issues. I can't test on HiDPI on Linux, but it would be nice if someone would, same for Mac/Windows for both normal/HiDPI monitors. It is better to test basic scenario first before reverting & creating M3a or RC2b packages at very last minute before release. Created attachment 284513 [details] Screenshot before the change, to show where to look (In reply to Andrey Loskutov from comment #9) > ... > Please provide concrete steps to verify the solution. I don't see > immediately any change (I have no HiDPI on Linux), but also I have no idea > where to look for it. > Please check the places where on Windows fonts were previously displayed too large (see attached screenshot): - Search bar: "Search:" label, input field, "Go" button, "Scope:" link - Tab (side bar) titles, e.g. "Contents" - Drop-down menus of the print and search buttons - TOC items - Breadcrumb that is shown inside of the topic For me it looks good on Windows 10 on high-DPI and non-high-DPI displays in Internet Explorer, Edge, Firefox and Chrome. Also on the iPad (Safari, Chrome and Firefox) and on a Motorola Android smartphone (Chrome and Firefox) I did not notice anything that was broken by this change. (In reply to Andrey Loskutov from comment #9) > > > +1 for committing and making it available to us with the next build. It is > > easy enough to revert in case of severe issues. > > scenario first before reverting & creating M3a or RC2b packages at very last > minute before release. What I meant is, if we accept now, everyone running on I-Builds will have it tomorrow. I assume all committers and many contributors are running their IDE on I-Builds. Maybe the quickest way to have more eyes on this. M3 is only November 27, no need for M3a. I'm fine either way, it just is a low risk patch. The fix for this bug has now been tested on all platforms (Windows, Linux and macOS plus for the Infocenter on iOS and on Android): https://git.eclipse.org/r/c/platform/eclipse.platform.ua/+/170371 Would it be possible to get it accepted for 4.18 (RC1)? Windows is a widely used platform and high-DPI displays are becoming more and more common. Without the fix "Help > Help Contents" is almost unreadable on Windows on a high-DPI display. As it's IE specific Niraj would you please review and consider whether it's worth adding it for RC2? I don't see any negative impact on my Fedora 33 non hidpi system. Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.ua/+/170371 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ua.git/commit/?id=25d529a89bee8edb82d38a3ec98a6df2ef5a91f2 (In reply to Alexander Kurtakov from comment #14) > I don't see any negative impact on my Fedora 33 non hidpi system. For me, "Help >> Help Contents" is readable with and without the patch. - As tested on Win10 with IE11 @200 zoom: Also I don't see any negative impact of this patch, so should be good on this. Can we close this bug for 4.19 and create new bugs to track pending items(if any)? Thanks! |