http://bugzilla.opensuse.org/show_bug.cgi?id=992519 Stephan Kulow <coolo@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|coolo@suse.com |sknorr@suse.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c7 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |accessibility Whiteboard| |A11Y --- Comment #7 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Stefan Knorr from comment #1)

From my view, the font requirements are correct. The release notes should require

Recommends/suggests should be sufficient, particularly when the installation selection is minimal.

everything necessary to make them look their best by default...

Historically and still today, "look their best" is particularly subjective with fonts. As screen density increases, differences among and within fonts can change considerably. Fonts actually big enough to see can look vastly different from the tiny ones most programmers and web stylists think the whole world should be served. How can release notes "look their best" with Google Opensans when the major DEs offered are configured to use Noto, Roboto and/or Cantarell? What's the difference?

Can we close as WONTFIX or are there specific use cases where people need release notes installed locally but can't afford 2.7 MB extra space?

This is not about the amount of space these packages consume. It's about usability, visual acuity and an admin's ability to choose among the variety of possibilities offered. I require the fonts I require for legibility and other reasons, among which space consumed is trivial. Included among my requirements is for selected fonts to not be available, among which kde-oxygen-fonts is another. Requiring certain fonts in order to acquire a certain "look" is an onerous usurpation of usability and choice. Recommends or suggests should be sufficient for those of the opinion that look is more or even as important as function. Does any distro have a hard requires for any particular font just to have release notes available? I don't use openSUSE because of the way it looks. I choose openSUSE because of what it offers, the ways it works, as well as a few things it doesn't do. If I chose a distro based on looks, openSUSE would be among the last candidates rather than #1. (In reply to Ludwig Nussel from comment #6)

3) Even though it has nothing to do with this bug I'd probably also drop the PDFs. I kind of doubt anyone want's to print release notes :-)

Likely it's rare, but what about those struggling with an offline install trying to repair fonts that render corrupted or are otherwise illegible on screen? Putting the pdf on a USB stick to put in a printer is likely to produce exactly what's needed, and simply. (In reply to Simon Lees from comment #4)

I don't think its really worth that effort to save 2.7 MB on a system.

It ought to be worth maximizing configurability for those with visual issues. Accessibility isn't just about accommodating the blind or deaf. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c11 --- Comment #11 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 687487 --> http://bugzilla.opensuse.org/attachment.cgi?id=687487&action=edit proof of concept - replaces px font sizing with respectful font sizing in /usr/share/doc/release-notes/static/css/style.css (In reply to Stefan Knorr from comment #9) ...

or to peruse the text version of the release notes.

Better yet, shrink the CSS down to a respectful, non-abusive size, following the valued guiding principles "respect for others" and "making users happy", by making having a lot of fun less like work. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c15 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Leap 42.2 |Leap 15.0 Summary|obsolete font package |onerous font package |requirements |requirements --- Comment #15 from Felix Miata <mrmazda@earthlink.net> --- "Obsolete" doesn't do justice to the problem. Onerous is better, and it's a bit late to fix for 42.2 - > 15.0. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c17 --- Comment #17 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Simon Lees from comment #16)

This still seems reasonable to me, although maybe the font requirements could be somewhere else. We ship a unified look and feel across all desktops part of which having a unified default font is part of it, this also helps

How it _works_, _accessibility_ and _usability_ ought to trump unified *look* and *feel*. Recommends *should* be sufficient to fulfill the stylist's look and feel objective. People with cataracts, macular degeneration, trifocals and other old age deteriorations have enough trouble using PCs without needing to try to figure out why their needs and preferences are so hard to have utilized, much less what if anything they can do to have them utilized. Those who find particular fonts unsuitable should not be forced absent heroics to nevertheless have them. (In reply to Stefan Knorr from comment #1)

The release notes should require everything necessary to make them look their best by default

"Look their best" is purely subjective. What is "best" to a stylist is not the same thing as best for everyone. Web pages are not photographs or PDFs. CSS was designed to be styling _suggestive_, not imperative. As spelled out in the senior bug duped here Bug 926792 non-adherence to a theme is not functionality breakage. body, h1, h2, h3, h4, h5, h6 {font-family: 'Source Sans Pro',sans-serif;} as exists currently in https://www.opensuse.org/build/css/openSUSE.min.css and utilized on https://www.opensuse.org/ fulfills the "look and feel" intent reasonably, but only for opensuse.org site visitors who have Source Sans Pro installed, which probably means most visitors not who do not use openSUSE. If a certain look and feel is so important, the site should be using a web font via an @font-face declaration. Web fonts can be disregarded by the visitor's browser, yet can be utilized by any visitor, whether openSUSE user or not. On https://en.opensuse.org/Main_Page the rule functionally equivalent to that above is html, body { font: 1em "Lucida Grande", Arial, "DejaVu Sans", Verdana, sans-serif} from https://static.opensuse.org/themes/bento/css/base.css . Between the two, that's a total of 5 base-level fonts that openSUSE stylists think are better than the visitors' browser defaults. B.O.O. show_bug pages declare three additional base-level fonts: body, td, th, input, select, option, optgroup, .text_input { font-family: "Open Sans", "Helvetica Neue", Arial, Helvetica, sans-serif} https://bugzilla.opensuse.org/skins/contrib/openSUSE/global.css 42.3's file:///usr/share/doc/release-notes/openSUSE/RELEASE-NOTES.en.html has yet another unique base-level CSS declaration: body {font-family: 'Open Sans', 'DejaVu Sans', 'Verdana', sans-serif} file:///usr/share/doc/release-notes/openSUSE/static/css/style.css Consistent "look and feel" is thus absent from opensuse.org and openSUSE's distributions, so is not a legitimate reason for release-notes-openSUSE to _require_ at the rpm level installation of particular additional fonts that aren't part of any functionally necessary font pattern. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c19 --- Comment #19 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Ludwig Nussel from comment #18)

AFAICT there are no font requirements of release-notes-openSUSE in TW or Leap so I think this bug can be closed. Felix, could you please confirm?

Senior bug 926792 dup'd to this was exactly about that: # grep RETT /etc/os-release PRETTY_NAME="openSUSE Leap 42.3" # zypper in release-notes-openSUSE Loading repository data... Reading installed packages... Resolving package dependencies... Problem: release-notes-openSUSE-42.3.20170911-6.1.noarch requires google-opensans-fonts, but this requirement cannot be provided uninstallable providers: google-opensans-fonts-1.0-14.3.noarch[OSS] Solution 1: remove lock to allow installation of google-opensans-fonts-1.0-14.3.noarch[OSS] Solution 2: do not install release-notes-openSUSE-42.3.20170911-6.1.noarch Solution 3: break release-notes-openSUSE-42.3.20170911-6.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c] (c): c

Also please feel free to file tickets for the mentioned online services.

Tickets for what for the online services, that they don't all use the same stylesheets? That they don't declare the same base-level (html,body) fonts? If yes to the latter, which fonts are they supposed to be declaring as first choice? Lucida Grande and Helvetica Neue are Mac fonts. Source Sans Pro and DejaVu Sans AFAIK are the only two declared that may be part of a minimal X openSUSE installation, and Open Sans is only installed because of the release-notes-openSUSE require. Who's responsible to determine what "look and feel" desires? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c21 --- Comment #21 from Felix Miata <mrmazda@earthlink.net> --- https://lists.opensuse.org/opensuse-kde/2018-07/msg00000.html has discussion about the number of KDE/Plasma packages that supposedly "break" if hack-fonts is not/will not be installed in TW20180701, somewhere between 1 and 202. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c23 Simon Lees <simonf.lees@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Simon Lees <simonf.lees@suse.com> --- (In reply to Felix Miata from comment #22)

This now applies in both TW and 15.1 to yast2-qt-branding-openSUSE, which *requires* adobe-sourcsanspro-fonts in order to not "break". YaST2 *works* fine without adobe-sourcesanspro-fonts installed: # zypper ll | grep fonts 5 | adobe-source*-fonts | package | (any) 6 | agfa-fonts | package | (any) 18 | intlfonts* | package | (any) 19 | kde-oxygen-fonts | package | (any) # rpm -qa | grep fonts | grep noarch | sort agfa-fonts-2003.03.19-94.noarch dejavu-fonts-2.37-1.8.noarch fonts-config-20190119-1.2.noarch google-droid-fonts-20121204-5.12.noarch liberation-fonts-1.07.4-2.3.noarch linux-libertine-fonts-5.3.0-8.11.noarch xorg-x11-fonts-7.6-35.3.noarch xorg-x11-fonts-core-7.6-35.3.noarch # zypper -v dup ... Problem: yast2-qt-branding-openSUSE-84.87.20180403-1.2.noarch requires adobe-sourcesanspro-fonts, but this requirement cannot be provided not installable providers: adobe-sourcesanspro-fonts-2.020-1.11.noarch[OSS] Solution 1: Following actions will be done: remove lock to allow installation of adobe-sourcesanspro-fonts-2.020-1.11.noarch[OSS] remove lock to allow installation of google-opensans-fonts-20180610-1.3.noarch[OSS] Solution 2: Following actions will be done: deinstallation of yast2-qt-branding-openSUSE-84.87.20180403-1.1.noarch deinstallation of yast2-theme-4.2.2-1.2.noarch deinstallation of kdebase3-SuSE-lang-11.3-100.1.noarch Solution 3: keep obsolete yast2-qt-branding-openSUSE-84.87.20180403-1.1.noarch Solution 4: break yast2-qt-branding-openSUSE-84.87.20180403-1.2.noarch by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/3/4/s/r/c] (c): 4 Applying solution 4

I have confirmed this is intentional and correct, its now the font used for most of the installer branding hence the requirement. I'm going to close off this bug, since the patterns changes as many of these issues as possible should be cleaned up. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gp@suse.com, | |mrmazda@earthlink.net -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=992519 http://bugzilla.opensuse.org/show_bug.cgi?id=992519#c27 --- Comment #27 from Felix Miata <mrmazda@earthlink.net> --- (In reply to Simon Lees from comment #26)

It, itself is still not a bug, your locking the wrong thing, as far as I can see nothing requires yast2-qt-branding-openSUSE so why don't you remove and lock that instead?

# zypper rm yast2-qt-branding 2 additional packages to remove: yast2-theme yast2-x11 Seems to me that would mean no GUI YaST2, one of, if not the, openSUSE traditionally top feature/attraction/selling point. And what about the others in the bug 1153854 attachment?: gtk3-metatheme-adwaita requires cantarell-fonts gtk3-metatheme-adwaita is the default theme for non-Gnome users of gtk apps, e.g. Firefox in KDE. plasma5-integration-plugin requires hack-fonts and noto-sans # zypper rm plasma5-integration-plugin 5 additional packages to remove: frameworkintegration-plugin plasma5-desktop plasma5-session plasma5-workspace No plasma5-integration-plugin means no Plasma at all! Any font should be no more than suggested or recommended, unless functional loss would result from a particular font package's absence, such as might occur (?) with postscript/ghostscript/pdf apps. Are you suggesting this or bug 1153854 should be a metabug and bugs specifically against yast2-qt-branding-openSUSE, gtk3-metatheme-adwaita and plasma5-integration-plugin are the appropriate path to take? Bug 1153854 is about apparent policy that allows hard requires of any specific font rather than any generically compatible font. -- You are receiving this mail because: You are on the CC list for the bug.