From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from acme.spoerlein.net (acme.spoerlein.net [88.198.49.12]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id p0PEZJIL001620 for ; Tue, 25 Jan 2011 09:35:20 -0500 (EST) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id p0PEZJep073006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 15:35:19 +0100 (CET) (envelope-from uqs@spoerlein.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=spoerlein.net; s=dkim200908; t=1295966119; bh=jbROy1KNaNJge0WzDisJNtF2/DwN7LTwi9pQAnXqhEY=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=a9Jup+6CCZ7ItYr8Mny5slEFWUQz/zWbV/P6oX5yhYL3iZRRKCQ+vVIiIFIceEKOV JNcNCbKzUrrMNswSK93gys0g6oVfNEHQ5koAI/GycHk9gKtHqZRbM1HKfFTjnC6GZB mk316v9nHVifi9kZGQ4gvS6gcJVcBDi2Q7UGE6i8= Date: Tue, 25 Jan 2011 15:35:19 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: discuss@mdocml.bsd.lv Subject: Re: Bullets everywhere Message-ID: <20110125143519.GJ65811@acme.spoerlein.net> References: <20110110221110.GJ23329@acme.spoerlein.net> <20110123144048.GB4205@iris.usta.de> <20110123172251.GE65811@acme.spoerlein.net> <4D3D95A4.3070300@bsd.lv> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D3D95A4.3070300@bsd.lv> User-Agent: Mutt/1.5.21 (2010-09-15) On Mon, 24.01.2011 at 16:07:16 +0100, Kristaps Džonsons wrote: > On 01/23/2011 06:22 PM, Ulrich Spoerlein wrote: > > On Sun, 23.01.2011 at 15:40:48 +0100, Ingo Schwarze wrote: > >> Hi Ulrich, > >> > >> Ulrich Spoerlein wrote on Mon, Jan 10, 2011 at 11:11:10PM +0100: > >> > >>> prompted by some gratuitous differences in groff vs mandoc output, I > >>> wanted to ask for the rationale here (if any). > >>> > >>> .Bl -bullet > >>> .It > >>> one > >>> .El > >>> > >>> will print the following raw output: > >>> > >>> mandoc: o^Ho one > >>> groff[1] -Tascii: +^H+^Ho^Ho one > >>> groff[1] -Tutf8: ·^H· one > >>> groff[2] -Tascii: ^[[1m+^Ho ^[[22mone > >>> > >>> [1] is groff 1.19.2 (the last GPLv2 release) > >>> [2] is groff 1.20.1 > >> > >> We don't do -Tutf8, so that part is not relevant. > >> > >> Regarding groff-1.20.1 (which i'm using as my reference groff, too), > >> you should always use > >> > >> /usr/local/bin/nroff -c -mandoc -Tascii > >> > >> which will produce "+\b+\bo\bo" just like groff-1.19.2 (though i > >> admit i never tried 1.19, i only use 1.15 and 1.20). > >> > >> Indeed, i have been regarding that difference as annoying for a long > >> time. It is one of the main sources of noise in automatic comparisons, > >> so it is a real hindrance when trying to find bugs, and even worse, > >> when making sure to prevent regressions. For example, fixing it > >> reduces the size of the /usr/src/bin diff from over 1000 to less > >> than 600 lines. > >> > >> Even if terminals capable of showing two glyphs on top of each other > >> are probably rare nowadays, so "+\b+\bo\bo" vs. "o\bo" will rarely > >> make a noticable difference for the user, i strongly feel like > >> committing the following diff, just for binary compatibility. > >> > >> At some point in the past, Kristaps voiced concerns that a similar > >> but less elegant diff i sent out might wreak havoc in the terminal > >> frontends because term.c / term_flushln() would rely on the fact > >> that backspace only occurs in the usual underline and bold sequences, > >> not as a standalone character. Actually, this is not an issue. > >> The only guarantee needed by term_flushln() is that you don't go > >> back more than you advanced, so the diff poses no risk. > >> Besides, the diff also works fine with term.c / encode(). > >> When processing "+\bo", the plus will be encoded, the backspace > >> passed through, and the circle encoded, just as we want it, > >> to produce "+\b+\bo\bo" or "_\b+\b_\bo". > >> > >> So, do you agree with this diff? > >> It survived an OpenBSD build, and the output looks good. > > > > Works for me. But there should be a small comment, explaining that this > > is for groff compat and won't do much on xterms and Co. > > Please don't check this in: it causes assertions in -Tps and -Tpdf. Let > me look into another solution, as passing raw escapes to the backend > makes for unhappy backends. I'm not even saying that it should go in, as it only makes diffs between groff/mandoc easier to read. It has no actual effect on terminal output, and I'd rather see the time spent on making the Postscript output use real bullets instead. Perhaps the groff maintainers can be persuaded to drop this feature from their terminal output? If people want "bullets" to appear in print, they should just use HTML or PS output, IMHO. Bye, Uli -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv