Date: Mon, 18 Sep 2023 05:45:19 +0000 From: bugzilla-noreply@freebsd.org To: doc@FreeBSD.org Subject: [Bug 273885] Accessibility: review use of italicised green monospace in manual pages Message-ID: <bug-273885-9-OoK4KwfEnU@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-273885-9@https.bugs.freebsd.org/bugzilla/> References: <bug-273885-9@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273885 --- Comment #6 from G. Branden Robinson <g.branden.robinson@gmail.com> --- (In reply to Wolfram Schneider from comment #3) Hi Wolfram! (I will try harder to get your name correct--people misspell mine all the t= ime, so I really shouldn't mess up others' names.) "This is very likely a side effect of the groff 1.23.0 update. I don't know why, I will check. ... I think problem is in the new variable doc-page-topic-font /usr/local/share/groff/1.23.0/tmac/mdoc/doc-nroff .ds doc-page-topic-font \f[I] if you change that to .ds doc-page-topic-font \f[] the title will be displayed without italic fonts ... commit eeb7e34a074014631c5feab8121928a9b2ddc7a2 Author: G. Branden Robinson <g.branden.robinson@gmail.com> Date: Thu Nov 3 07:16:41 2022 -0500" That is indeed the commit that changes the page topic to use the same face = as the _mdoc_ `Xr` macro, which (as of _groff_ 1.23.0) also uses italics by defaults. However, as you've found, this setting is also customizable, and there's nothing wrong with changing it. I would not, however, make the exact change you proposed. .ds doc-page-topic-font \f[] This doesn't make a "null font change": it changes the font to the _previou= sly selected_ font. Sometimes this will have no adverse consequences, but I wouldn't bet on it never doing so, and it's the sort of thing that can be h= ard to track down later. If you want the page topic to render in roman, I would say so explicitly. .ds doc-page-topic-font \f[R] In _groff_ 1.24.0 I hope to get the `MF` string from _groff man_ ported ove= r to our _mdoc_ implementation to improve the package-neutral configurability of= man page appearance. (The reasons this wasn't already done have to do with PDF support for hyperlinks, whether internal or of the "man:ls(1)" kind; it's easier for me to develop features for _man_(7), get the bugs shaken out, th= en port them over to _mdoc_.) If you want to eliminate the appearance of italic text in _mdoc_ documents = as a low-vision accommodation measure (or for any other reason), you might also = want to look at some other string definitions. In _groff_ 1.22.4 (and "nroff mode"), the `Ad`, `Ar`, `Em`, `Fa`, `Ft`, `Pa`, `Sx`, and `Va` also used italics, as did the fixed string `Na` (which writes "NaN"). This list is mostly the same in _groff_ 1.23.0, with the removal of `Sx` and addition of `Xr`. Regarding text appearing in green, that is not anything _groff_ does by default; _groff_ itself does not colorize man pages. (It's overwhelmingly popular among Arch Linux users.) Based on experience with other man-to-HTML converters, I surmise that what's happening is that a tool is telling _grof= f_ to format a man page for a terminal and then interpreting the output to inf= er typeface changes. A CSS style may then be getting applied to the inferred faces. Regarding the accessibility issues of italic text, I think it's important to keep the domain of application in mind. As pointed out in the top link matching your "startpage" query, https://ux.stackexchange.com/questions/62742/are-italics-on-the-web-bad-for= -accessibility ...it seems that some people are interpreting a blanket prohibition against italics for Web content by (arguably) overreading a W3C recommendation.=20 Whether the problems that degrade the readability of italics apply to the FreeBSD web site is something that the FreeBSD project should decide for itself. I will add that in _groff_ 1.23.0 italics are not used by default when rendering to terminals. It can be enabled, however. _grotty_, _groff_'s output driver for terminals, has long supported the production of ISO 6429/ECMA-48 SGR escape sequences for italics, but the switch to enable the= se has not been easy to access. It is now. https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=3D1.23.0#n86 Still, as I said, italics in terminal output are _off_ by default. This mi= ght change in _groff_ 1.24.0, as Lennart Jablonka has proposed patches to make _grotty_ use _terminfo_ to determine the terminal's capabilities instead of firing blindly as it has done to date. https://lists.gnu.org/archive/html/groff/2023-09/msg00027.html Traditionally, "nroff devices" use underscores in place of italics, because= the typewriter-based paper terminals that _roff_ and _nroff_ targeted in the ea= rly 1970s did not support oblique typefaces. Apparently (per the above Stack Exchange thread), at one point the British Dyslexia Association discouraged thae underscoring practice as well...but the link is now dead. Whether this suggests that the corresponding guidance has been withdrawn, I cannot say. Finally, I would emphasize that _groff_, like the _troff_ from Bell Labs th= at inspired it, is a typesetting system. At the aforementioned StackExchange thread, much of the quoted discussion expressing concern with the accessibi= lity of italic text to those with low vision centered on issues of poor font qua= lity or low-resolution glyph rendering. _groff_ is indeed designed to format te= xt even in such limited environments, but it also produces PDF, PostScript, PC= L 5, and TeX DVI, where glyph detail can be of professional quality. I think th= at if italic text were _inherently_ frustrating to low-vision accessibility, w= e'd have learned this fact hundreds of years ago, nearer to the time when itali= c, slanted, and oblique typefaces were first designed and set in lead, instead= of stumbling on the fact suddenly in the wake of Tim Berners-Lee's most famous achievement. Let me know how I can be of assistance. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273885-9-OoK4KwfEnU>