Created attachment 761670 [details] contextual screenshot of 1600x1200 Anaconda software selection screen Screenshot is 1600x1200 resolution of Anaconda's software selection screenshot .png loaded in Firefox on an F19-TC3 KDE installation using only OEM default desktop font settings, as well as Xorg DPI OEM-forced to 96. Note how virtually all text other than Anaconda's is larger than Anaconda's, and black instead of gray, making Anaconda's text the least comfortable reading in the entire image. https://lists.fedoraproject.org/pipermail/test/2013-June/116292.html provides additional description. https://lists.fedoraproject.org/pipermail/test/2013-June/116305.html prompted me to file this. To reproduce: 1-try to install on a high (>96) DPI desktop display screen with valid EDID Actual results: 1-X.log contains string: "DPI set to (96, 96)" 2-overabundant whitespace on most screens 3-tiny text unnecessarily difficult to read with <50th percentile vision on most screens and windows 4-poor conformance to best A11Y practices Expected results: 1-X.log contains "DPI set to (..." string with numbers matching display device's actual pixel density 2-good use of available space for comfortably sized text and other objects 3-no text difficult to read by user who is not legally blind or nearly so 4-good conformance to best A11Y practices
Created attachment 761671 [details] contextual screenshot of 1600x1200 Anaconda software selection screen in accurately configured installed environment The difference between this and attachment 761670 [details] is here desktop display density has been matched to physical display device density, which makes the difference between text sizes on a normal desktop and those in Anaconda more readily apparent.
Created attachment 761683 [details] automagical 1600x1200@96DPI screenshot of current openSUSE Factory software selection screen I consider this top class, without anything remotely approaching equal among all Linux distro installers I've used, including easier to read text on than most.
This is just reviving a decade old bikeshed and isn't going to go anywhere useful at all.
https://www.redhat.com/archives/rhl-devel-list/2006-July/msg00427.html (bikeshed!) https://ask.fedoraproject.org/question/10731/why-do-i-have-gigantic-fonts-in-kde/ (someone who doesn't like 'correct' dpi and wants 96) http://forums.fedoraforum.org/showthread.php?t=249163 (wants 72!) http://forums.fedoraforum.org/showthread.php?t=195239 (wants 96) https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/fWgi6W3BBwU (a mozilla bikeshed about how using 'accurate' dpi causes ugly scaling) https://home.comcast.net/~tomhorsley/game/dpi.html#Rationale (Tom Horsley's longer explanation of why dpi fanaticism is a mistake) https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts (an Ubuntu troubleshooting page for when dpi calculations go wrong: consider why this exists) http://people.gnome.org/~federico/news-2007-01.html (Federico M-Q on why this is an impossible problem to magically solve) ...and so on, and so on.
Created attachment 761724 [details] contextual screenshot of 1920x1200@133DPI Anaconda software selection screen in accurately configured installed pre-retina, expensive laptop environment Made like attachment 761671 [details] but on higher density laptop screen, the gray text is about 7pt. Laptops with densities upwards of 60% higher are multiplying in marketplace availability. Anyone attempting to put F19 as it is today on one of them would be faced with Anaconda text 5pt or smaller.
I don't know what you mean by that alias, but closing this bug doesn't mean anaconda doesn't care about a11y. It means that it's not anaconda's job to deal with display resolutions, and the anaconda team doesn't think that 'fixing' this is the way to deal with a11y issues.
It got no comment here, none on the devel mailing list, and none on the anaconda-devel mailing list. How was the resolution determined?
(In reply to Adam Williamson from comment #3) > This is just reviving a decade old bikeshed and isn't going to go anywhere > useful at all. Since I've been asked to comment on this issue: 1. it's not a bikeshed (this is not a nice way to treat a well-written report) 2. it's a technical choice and the fact kde chose the other option is a strong hint the GNOME choice is not the obviously right choice (hint #2: scribus is a KDE app, GNOME has no contender) 3. since GNOME made this choice (despite years of contrary user feedback in GNOME bugzilla) all the various excuses have been invalidated - windows does not work this way anymore - even if windows did work this way hardware on the market is no longer windows only (see chromebooks) - screens are now dirt cheap and now routinely used as advertisement walls or videoprojector replacements "low resolution projectors" are a thing of the past - even if low res video projectors where still common, 4K video is going to break GNOME's 96dpi resolution assumptions hard. No one is going to buy a bigger wall just so 4k projection still fits in GNOME's ideal - the general case is not broken hardware. The general case is working hardware - if GNOME actually optimized for broken hardware GNOME 3 wouldn't use 3d everywhere - if GNOME actually ignored screen differences colord would not exist - Mozilla excuses about resolution handling were taken as hard fact. But Firefox is single-windowed, single-screen, unlike GNOME. - GNOME hosts many apps with print output. Firefox sucks at print. This is not a problem for Firefox, but GNOME better make some effort to respect font sizes printers expect - even if firefox was remotely similar to GNOME, real world forced a backpedal Mozilla-side anyway https://github.com/jtackaberry/nosquint/issues/75 As before, the simple easy robust way to configure a display is: 1. set the display physical side (via edid or manual setting when edid is wrong, you can provide a set of default sizes if typing is too hard for the user) 2. set the display distance (arm-length or something else for tv/projectors) Here, done, that wasn't hard isn't it ? No need to bother users with angles of view they can't easily measure anyway Now, I won't waste any more time trying to convince GNOME people they are wrong. I'm firmly convinced there is not a sliver of doubt at this stage they are wrong and they'll be forced to change stance whether I waste my time here or not. Finally I'll point out the value of listening to users before accumulating enough ill-will any decision is viewed in a negative light. Acknowledging mistakes graciously never hurt anyone.
Why do you keep talking about GNOME when this bug is filed against anaconda?