From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 515bd6e1 for ; Mon, 19 Jun 2017 12:06:14 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1dN07w-0003lf-VK; Mon, 19 Jun 2017 19:06:14 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1dN07u-0002bw-G3; Mon, 19 Jun 2017 19:06:10 +0200 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1dN07u-0006Ee-9E; Mon, 19 Jun 2017 19:06:10 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 93ed718b; Mon, 19 Jun 2017 19:06:10 +0200 (CEST) Date: Mon, 19 Jun 2017 19:06:10 +0200 From: Ingo Schwarze To: "Anthony J. Bentley" Cc: tech@mdocml.bsd.lv Subject: Re: Rendering of math symbols in ASCII mode Message-ID: <20170619170610.GF97447@athene.usta.de> References: <72240.1497830663@cathet.us> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72240.1497830663@cathet.us> User-Agent: Mutt/1.6.2 (2016-07-01) Hi Anthony, Anthony J. Bentley wrote on Sun, Jun 18, 2017 at 06:04:23PM -0600: > This beauty shows up in erf(3): > > .Bd -filled -offset indent > .if n \{\ > erf(x) = 2/sqrt(pi)*\|integral from 0 to x of exp(\-t*t) dt. \} > .if t \{\ > erf\|(x) := > (2/\(sr pi)\|\(is\d\s8\z0\s10\u\u\s8x\s10\d\|exp(\-t\u\s82\s10\d)\|dt. \} > .Ed > > My first instinct was to replace it with eqn(7), I agree with that direction. While eqn(7) is better avoided where it can reasonably be avoided, it is the best solution for those unusual cases where non-trivial mathematical formulae are essential content of a manual page. > a pleasant way to write non-trivial equations: > > .EQ > roman erf ( x ) = 2 over {sqrt pi} int sub 0 sup x e sup {- t sup 2} dt > .EN Why roman? Aren't function names usually set italic in mathematic papers? > This looks great in groff -Tpdf and mandoc -Thtml, and is serviceable > enough in mandoc -Tutf8. Unfortunately, in ASCII it looks like this: > > erf ( x ) = 2/(sqrt(n)) I_0^x e^(- t^2) dt > > As per mandoc_char(7), the integral symbol is replaced with I and pi > is replaced with n. Awful! Awful indeed, but not our choice. Look at this in /usr/local/share/groff/1.22.3/tmac/tty-char.tmac: .\" These definitions are chosen so that, as far as possible, they: .\" - work with all of -Tascii, -Tlatin1, -Tutf8, and -Tcp1047. .\" - work on devices that display only the last overstruck character .\" as well as on devices that support overstriking .\" - represent the character's graphical shape (not its meaning) > While I'm inclined to think that attempting to render equations in pure > ASCII is somewhat futile, the human-readable nature of eqn(7) suggests > the possibility of simply displaying the symbol name for certain symbols > like Greek letters and integrals. > > erf ( x ) = 2/(sqrt(pi)) int_0^x e^(- t^2) dt I agree that is a clear improvement. > This would make it practical to use eqn(7) in certain libm manuals, > which I think could be a nice improvement. Viewing the math-heavy libGL > manuals on man.openbsd.org is a real pleasure. > > Thoughts? Currently, words like "integral" are translated to character escape sequences by the parser, independent of the output format. Moving that translation to the formatters in order to avoid it for -Tascii would cause code duplication because several formatters need the same translation: -Tutf8, -Tpdf, -Thtml... Besider, eqn(7) advertises that "the character escape sequences documented in mandoc_char(7) can be used, too", in addition to the translated words, so moving the tranlation to the formatters would only solve part of the problem and leave people in the rain who - legitimately - use \(is or \[integral] directly. So i think the rendering of special characters in -Tascii needs to be improved, but that requires building consensus with groff first, hoping that they might be willing to move away from the "graphical shape, not meaning" paradigm. Here are some of the unintelligible renderings: \(Ah N ALEF SYMBOL \(fa V FOR ALL \(pd a PARTIAL DIFFERENTIAL \(te 3 THERE EXISTS \(mo E ELEMENT OF \(st -) CONTAINS AS MEMBER \(sr \/ SQUARE ROOT \(ca (^) INTERSECTION \(cu U UNION \(is I INTEGRAL \(sb (= SUBSET OF \(su =) SUPERSET OF \(ib (_ SUBSET OF OR EQUAL TO \(ip _) SUPERSET OF OR EQUAL TO I don't think any of these allow intelligible one- or two-character ASCII renderings. Multi-character descriptive renderings cause a problem with spacing. For example, rendering \[sr]2\[mo]R as sqrt2element ofR is not very readable. For some character escape sequences that render to nothing in groff -Tascii, i decided to use descriptive renderings enclosed in angle brackets in the past: \(sc SECTION SIGN \(de DEGREE SIGN \(ps PILCROW SIGN \(CS BLACK CLUB SUIT Do you consider that desirable for cases like the above, too? \(Ah ALEF SYMBOL \(fa FOR ALL \(te THERE EXISTS \(mo ELEMENT OF \(sr SQUARE ROOT \(ca INTERSECTION \(cu UNION \(is INTEGRAL \(sb SUBSET OF \(su SUPERSET OF There is a similar problem with small greek letters. e^iomegat is not very readable. Or is it good enough? Is e^it better? If so, what about pi? cos(2pi) = 1 is obviously fine, but exp(2pii) = 1 would arguably be more readable as exp(2i) = -1 It might be a good idea to form consensus here before approaching the groff community with patches. Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv