Bullets everywhere

Bullets everywhere

[Ulrich Spörlein]

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>&bull;</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

Re: Bullets everywhere

[Ingo Schwarze]

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

Re: Bullets everywhere

[Ulrich Spoerlein]

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

Re: Bullets everywhere

[Kristaps Dzonsons]

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

Re: Bullets everywhere

[Ulrich Spörlein]

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