From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp1.rz.uni-karlsruhe.de (Debian-exim@smtp1.rz.uni-karlsruhe.de [129.13.185.217]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id o6BMHonH031038 for ; Sun, 11 Jul 2010 18:17:54 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1OY4qK-0004R6-7l; Mon, 12 Jul 2010 00:17:48 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.71) (envelope-from ) id 1OY4qK-0006Iu-6a for discuss@mdocml.bsd.lv; Mon, 12 Jul 2010 00:17:48 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.69) (envelope-from ) id 1OY4qK-0006b2-5I for discuss@mdocml.bsd.lv; Mon, 12 Jul 2010 00:17:48 +0200 Received: from schwarze by usta.de with local (Exim 4.71) (envelope-from ) id 1OY4qJ-0005bn-SJ for discuss@mdocml.bsd.lv; Mon, 12 Jul 2010 00:17:47 +0200 Date: Mon, 12 Jul 2010 00:17:47 +0200 From: Ingo Schwarze To: discuss@mdocml.bsd.lv Subject: Re: Raw UTF-8? Message-ID: <20100711221747.GC28881@iris.usta.de> References: <4c33f0f0.0c87970a.3458.fffff43f@mx.google.com> <20100707185815.GA19725@iris.usta.de> <20100707191807.GA18154@britannica.bec.de> <20100707211212.GC19725@iris.usta.de> <20100707211725.GA29241@britannica.bec.de> <20100709210539.GA2465@roadrunner.spoerlein.net> <20100710111118.1930f01c.list-jcr@designtools.org> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100710111118.1930f01c.list-jcr@designtools.org> User-Agent: Mutt/1.5.20 (2009-06-14) Hi Jonathan, J.C. Roberts wrote on Sat, Jul 10, 2010 at 11:11:18AM -0700: > UTF-8 support is very important and many consider it a "requirement" > these days. Not for manual pages, i just don't see the point. That said, i wouldn't oppose a -Tlatin1 or -Tutf8 output mode merely for groff compatibility, as long as it is not too intrusive (which probably it need not be, implementation will be quite local in one corner of the terminal output frontend). But i have no plans to implement, use or maintain it, and i would test it only in so far as it must not break anything else. Also, i would continue urging people to not use it, as manual pages relying on it would sacrifice portability for no good reason. And, of course, i will strongly oppose 8-bit-character input. I'm not willing to deal with multi-byte or wide character support functions anywhere in mandoc's code. > Personally, I think the \(:o syntax is nonsense. Agreed, the reason being that there is no reliable way to render it. Again, i consider it provided for backward compatibility. > Since we now have UTF, it seems better to error out on the archaic \(:o > syntax to prompt change, rather than support it to prolong a bad idea > and yet another syntax everyone needs to learn. No, it is used in too many places, and it would not be nice to deny rendering just because some piece of mdoc(7) or man(7) source code contains syntax we don't like. We are not defining new standards right now, we are re-implementing an existing language. > There's probably an existing IF-THEN-ELSE which could be leveraged > without undue overhead, but you get the main idea... --make the author > provide both the THEN and the ELSE. You mean, like in http://www.openbsd.org/cgi-bin/cvsweb/src/share/man/man4/sppp.4#rev1.20 I don't consider that viable, and jmc and myself agree to remove it from the tree when we find it (unless it comes from upstream). I doubt that people will regularly provide alternatives. Typing in special characters at all is already tedious, providing alternatives will not get done. And even if it is done, the result is incredibly ugly and hardly maintainable. > In many situations, even when a terminal is capable of displaying the > UTF-8, it could still be beneficial to also display the ascii, possibly > in parenthesis. In my opinion, you are vastly overestimating the importance of special characters in manual pages (beware, i'm not talking about typesetting of mathematical papers here!) and you are vastly underestimating the importance of portability and simplicity. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv