|
Bugzilla – Full Text Bug Listing |
|
Description
Stefan Hundhammer
2019-02-06 16:28:15 UTC
Created attachment 796144 [details]
Screenshot 01: System Roles
Created attachment 796145 [details]
Screenshot 02: Suggested Partitioning
Created attachment 796146 [details]
Screenshot 03: Local User
Created attachment 796147 [details]
Screenshot 04: Installation Settings (Proposal)
Not many explicit font size specifications in any of the .qss files on that image; only for the headings which look alright to me:
0:f184:/usr/share/YaST2/theme/current/wizard # grep -C 3 font installation.qss
YQDialog { background: #EEEEEE; color:#333; }
* {
font-family:"Source Sans Pro",sans;
}
#LogoHBox {
--
}
.current-step-name {
color:#fff;
font-family:"Source Sans Pro Semibold",sans;
}
.done-step-name {
color:#fff;
font-family:"Source Sans Pro Light",sans;
}
.todo-step-name {
color:#fff;
font-family:"Source Sans Pro Light",sans;
}
.steps_heading {
font-family:"Source Sans Pro",sans;
color: #35b9ab;
font-weight:bold;
}
.todo-step-status {
max-width: 14px;
--
#DialogHeadingLeft {
font-family: "Open Sans Condensed", Sans-serif;
font: 25px;
color: #333;
qproperty-alignment:AlignLeft;
font-weight:bold;
}
#DialogHeadingTop {
font-family: "Open Sans Condensed", Sans-serif;
font: 25px;
color: #333;
font-weight:bold;
}
QSpinBox,
--
{
qproperty-drawBase: 0;
/* Duplicate QTabBar::tab property.
Without this property, the tab space is calculated narrower and bold font
display messes up. See bnc#888589, bsc#948311 and QTBUG#8209 */
}
QTabBar::tab {
--
QGroupBox::title {
subcontrol-origin: margin;
subcontrol-position: left top;
font-weight: bold;
color: #333;
}
So it appears to rely on whatever Qt chooses.
Please notice that this was a libvirt / QEMU installation over ssh -X.
https://github.com/openSUSE/branding/commits/tumbleweed/yast/installation.qss Last change: 2018-12-14 "Use correct fonts from branding" When I open the style sheet editor (Ctrl-Shift-Alt-S) in that running YaST, load "installation.qss" and remove that section * { font-family:"Source Sans Pro",sans; } and hit "Apply", it looks quite alright to me. Created attachment 796153 [details]
Screenshot: Installation Settings (Proposal) after editing the QSS style sheet
Back in the old days when the X server was providing X11 fonts, this could possibly be attributed to font fallback cascades where that font was not available and another one with different metrics was chosen. But today that font rendering is all done on the client side AFAIK, so that can't be the problem. But not specifying a font size can be. Probably just explicitly specifying the standard font size should fix this. * {
font-family:"Source Sans Pro",sans;
font: 14px
}
looks good to me. Maybe even as small as 13px, but 12px is already too small.
Created attachment 796154 [details]
Screenshot: Font size 14px
Created attachment 796155 [details]
Screenshot: Font size 13px
This still needs some testing in scenarios other than over remote X, at least in the normal QEMU viewer and preferably on real hardware. Created attachment 796191 [details]
screenshot showing impact of px sized fonts not scaling according to display density
The TW 20190205 installation screenshot image of "Installation Settings" displayed in the two Firefox viewports was made using a 2560x1440 resolution 27" screen. In this screenshot, the larger of the two installation images measures 23" diagonally on my 24" 1920x1200 screen, nicely emulating what the installation screen would look like on a 23" display. The smaller measures 15.4", nicely emulating what the installation screen would look like on a 15.4" laptop. My point is to show the increasingly painful result of designs for display screens using px units to declare sizes - they do not scale according to display density. Other sizing options, such as keywords like small and large, and ems and percentages, all scale - automatically. The computer figures out how many pixels are needed to produce appropriate size instead of the designer choosing arbitrary px numbers that work for him on his display but become illegible on high density displays.
(In reply to Felix Miata from comment #13) > The computer figures out how many pixels are needed to produce appropriate > size instead of the designer choosing arbitrary px numbers that work for him > on his display but become illegible on high density displays. I really wanted to use em for stylesheets, but I can't do that, because of ``` However, Qt is limited to font sizes in pt and px and any other size must be in px, em or ex. ``` From: http://doc.qt.io/qt-5/stylesheet-reference.html#length That basically means that even if we change the fonts to use em, they will be out of size compared to everything else (checkboxes, logos, scrollbars, arrows for sliding widgets etc). Unfortunately the only way to keep that at least somewhat consistent is to use px measurements. That is entirely Qt's fault, css has long ago adapted to using em's for all the elements' sizing being possible. I will take a look at font sizes soon, Source Sans Pro is in fact smaller than previous Sans font we used for the interface, which is an issue. (In reply to Stasiek Michalski from comment #14) > I really wanted to use em for stylesheets, but I can't do that, because of > ``` > However, Qt is limited to font sizes in pt and px and any other size must be > in px, em or ex. > ``` > From: http://doc.qt.io/qt-5/stylesheet-reference.html#length Then we should probably prefer "pt" over "px", that should better work on HiDPI monitors I guess. BTW does anybody has access to some HiDPI monitor? At least for testing? Um, in the SLE theme we have "font-size: 90%" does that actually work? (https://github.com/yast/yast-theme/blob/417a6acf63fc759e2e8ae014d2d24da859517ae5/theme/SLE/wizard/installation.qss#L542) Created attachment 796233 [details]
Screenshot: YaST2 in virt-viewer (QEMU with X) with default font size
Created attachment 796234 [details]
Screenshot: virt-viewer 12px
Created attachment 796235 [details]
Screenshot: virt-viewer 13px
Created attachment 796236 [details]
Screenshot: virt-viewer 14px
Created attachment 796237 [details]
Screenshot: virt-viewer 9.5pt
Created attachment 796238 [details]
Screenshot: virt-viewer 10pt
Created attachment 796239 [details]
Screenshot: virt-viewer 10.5pt
Created attachment 796240 [details]
Screenshot: virt-viewer 11pt
I tested with virt-viewer, i.e. in the normal X11 environment that a QEMU installation starts up with; that gives us 1024x768 screen resolution. In that environment, 13px (see screenshot) or 10.5pt looks about right to me. My first screenshots were taken with my normal work environment and "ssh -X" on my Xfce desktop with two 1920x1200 monitors side by side. Even there it had looked alright before the style sheet change; now the fonts are too small. I suppose Qt just made a poor choice in the absence of a desktop environment to get settings from; starting with Qt5, it tries to do that. But in the inst-sys there is no desktop environment to communicate with, so it has to fallback to defaults, whatever exactly that is. So, for the inst-sys, we should definitely explicitly specify font sizes, otherwise the result will be more or less random. Since that new font appears to have different font metrics, obviously the Qt default font sizes don't fit anymore. Felix, you are definitely right that screen resolution does make a difference, but please don't forget that this is the inst-sys with a much more restricted environment and no KDE/GNOME/Xfce/whatever desktop to get any defaults from. (In reply to Ladislav Slezák from comment #15) > Then we should probably prefer "pt" over "px", that should better work on > HiDPI monitors I guess. We have those HiDPI settings enabled in the Qt UI which should take care of that (but then, I am not absolutely sure). > BTW does anybody has access to some HiDPI monitor? At least for testing? lnussel has one in his office for exactly that purpose. We can go down there and test with an ISO (with integrated DUD) on a USB stick. (In reply to Stefan Hundhammer from comment #25) > Felix, you are definitely right that screen resolution does make a difference, That's incomplete, thus inaccurate. Standing alone, screen resolution makes no difference. It's the combination of screen resolution and screen size that make a difference. The two combined are called display density, measured in DPI or PPI, commonly labeled HiDPI when the display's actual physical number is some arbitrarily above average number, likely the angularly defined reference pixel density 96 from CSS specifications times two, 192. 192 is reached on 4K screens at just under 23". On 2560x1440 192 is at just under 15.3", and 1920x1080 just under 11.5". Note in my comment #13 screenshot the reported 120 DPI is a logical DPI resulting from software settings. Logical DPI is the "knob" used for GTK/Gnome "scaling". Under the covers that knob is xrdb's Xft.dpi, which QT/KDE respond to when present, and indeed is implementor of the KDE desktop settings font tab value for "DPI". Physical PPI is the important number determining usability, the actual physical pixel density. > but please don't forget that this is the inst-sys with a much > more restricted environment and no KDE/GNOME/Xfce/whatever desktop to get > any defaults from. I get that. I think QT has a built-in initial value of 9pt, maybe 10pt, based on what I remember appears in the fonts tab when qt5ct is initialized on a virgin installation. (In reply to Felix Miata from comment #27) > I get that. I think QT has a built-in initial value of 9pt, maybe 10pt, > based on what I remember appears in the fonts tab when qt5ct is initialized > on a virgin installation. I am sure it has some fallback if nothing else is set, but of course such a fallback font size also depends on the font metrics. And since we have a different default font now during installation (as Stasiek confirmed in IRC), it's probably as simple as this font having different font metrics. I learned some time ago in another life while tracking down font problems that many font attributes are purely at the whim of the font designer; there appears to be a great degree of latitude what the font designer can choose. So a 9pt font might look drastically larger or smaller than another 9pt font of another font family. It depends on where the font designer chooses to set the font base line / top line / understroke line and also the amount between-lines spacing. While in theory a 9pt font should always be 9/72 inches high, there is quite some room for interpretation what exactly that means, and theory is also just that: Theory. Created attachment 798069 [details]
Leap 15.0 comparison screenshot: License Agreement
For comparison in the exact same environment:
License agreement from Leap 15.0
Created attachment 798071 [details]
Leap 15.0 comparison screenshot: System Role (Desktop Selection)
Created attachment 798073 [details]
Leap 15.0 comparison screenshot: Suggested Partitioning
Created attachment 798076 [details]
Leap 15.0 comparison screenshot: Local User
Created attachment 798077 [details]
Leap 15.0 comparison screenshot: Installation Settings
Legal requirements in Germany (I am pretty sure they are the same in the entire EU): http://publikationen.dguv.de/dguv/pdf/10002/215-450.pdf Section 8.6: Fonts Recommended character size in regard to viewing distance Viewing Distance (mm) Character Height (mm) 500 3.2 .. 4.5 600 3.9 .. 5.5 700 4.5 .. 6.4 800 5.2 .. 7.3 " Which corresponds to point sizes (1 pt = 1/72 in): 500 9.07 .. 12.75 600 11.05 .. 15.59 700 12.75 .. 18.14 800 14.74 .. 20.69 For myself, I measured 620 mm from my eyes to the monitor. My office colleague Arvin measured 650 mm. According to this, we should not go below 11 pt. Taking limited screen space into account for low screen resolutions, the 10.5 pt from comment #25 sound very reasonable. Source file for this style sheet: https://github.com/openSUSE/branding/blob/tumbleweed/yast/installation.qss (For SLE, this would be in the yast2-theme package in https://github.com/yast/yast-theme/blob/master/theme/SLE/wizard/installation.qss) Pull request: https://github.com/openSUSE/branding/pull/107 Notice that the pull request contains a lot of screenshots: Before, with the fix, and Leap 15.0 for comparison. Submit request against Factory: 679419 This is an autogenerated message for OBS integration: This bug (1124508) was mentioned in https://build.opensuse.org/request/show/682375 Factory / branding-openSUSE |