* Bullets everywhere @ 2011-01-10 22:11 Ulrich Spörlein 2011-01-23 14:40 ` Ingo Schwarze 0 siblings, 1 reply; 5+ messages in thread From: Ulrich Spörlein @ 2011-01-10 22:11 UTC (permalink / raw) To: discuss Hello, 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 HTML output of groff is kinda ridiculous: <p style="margin-left:14%;">one</p> <p style="margin-top: 1em" valign="top"><b>•</b></p> It's not even using <h1> for the document title ... HTML for mandoc 1.10.9: <ul style="margin-top: 0.00em;margin-bottom: 0.00em;" class="list list-bul"> <li class="list-bul" style="margin-top: 1.00em;"> one</li> Not that bad, except that I think one shouldn't use multiple <h1> in one document, but that's not the point of this email. Postscript! groff's output is nice (the old one, newer groff has an mdoc error trying to produce postscript, might be my port is broken ...). The bullets are Postscript bullets and `--' dashes also use the correct font symbol. Mandoc however is producing bold `o's as bullets for Postscript ... yuck. So what I'm mostly interested about is the +/o overprinting that groff is trying to do. This won't work on my xterm, obviously. Was this something that older printers could be coaxed into? Or teletypes, of course? Regards, Uli -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bullets everywhere 2011-01-10 22:11 Bullets everywhere Ulrich Spörlein @ 2011-01-23 14:40 ` Ingo Schwarze 2011-01-23 17:22 ` Ulrich Spoerlein 0 siblings, 1 reply; 5+ messages in thread From: Ingo Schwarze @ 2011-01-23 14:40 UTC (permalink / raw) To: Ulrich Spoerlein; +Cc: discuss 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. > HTML for mandoc 1.10.9: > Postscript! No comment on my part. :) Yours, Ingo Index: chars.in =================================================================== RCS file: /cvs/src/usr.bin/mandoc/chars.in,v retrieving revision 1.13 diff -u -p -r1.13 chars.in --- chars.in 20 Sep 2010 20:43:38 -0000 1.13 +++ chars.in 23 Jan 2011 14:32:06 -0000 @@ -387,7 +387,7 @@ CHAR("rs", "\\", 92) /* Text markers. */ CHAR("ci", "o", 9675) -CHAR("bu", "o", 8226) +CHAR("bu", "+\bo", 8226) CHAR("dd", "=", 8225) CHAR("dg", "-", 8224) CHAR("lz", "<>", 9674) -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bullets everywhere 2011-01-23 14:40 ` Ingo Schwarze @ 2011-01-23 17:22 ` Ulrich Spoerlein 2011-01-24 15:07 ` Kristaps Dzonsons 0 siblings, 1 reply; 5+ messages in thread From: Ulrich Spoerlein @ 2011-01-23 17:22 UTC (permalink / raw) To: Ingo Schwarze; +Cc: discuss 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. Regards, Uli -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bullets everywhere 2011-01-23 17:22 ` Ulrich Spoerlein @ 2011-01-24 15:07 ` Kristaps Dzonsons 2011-01-25 14:35 ` Ulrich Spörlein 0 siblings, 1 reply; 5+ messages in thread From: Kristaps Dzonsons @ 2011-01-24 15:07 UTC (permalink / raw) To: discuss 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. -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bullets everywhere 2011-01-24 15:07 ` Kristaps Dzonsons @ 2011-01-25 14:35 ` Ulrich Spörlein 0 siblings, 0 replies; 5+ messages in thread From: Ulrich Spörlein @ 2011-01-25 14:35 UTC (permalink / raw) To: discuss 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-01-25 14:35 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-10 22:11 Bullets everywhere Ulrich Spörlein 2011-01-23 14:40 ` Ingo Schwarze 2011-01-23 17:22 ` Ulrich Spoerlein 2011-01-24 15:07 ` Kristaps Dzonsons 2011-01-25 14:35 ` Ulrich Spörlein
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).