discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: "Ulrich Spörlein" <uqs@spoerlein.net>
To: discuss@mdocml.bsd.lv
Subject: Re: Bullets everywhere
Date: Tue, 25 Jan 2011 15:35:19 +0100	[thread overview]
Message-ID: <20110125143519.GJ65811@acme.spoerlein.net> (raw)
In-Reply-To: <4D3D95A4.3070300@bsd.lv>

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

      reply	other threads:[~2011-01-25 14:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-10 22:11 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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110125143519.GJ65811@acme.spoerlein.net \
    --to=uqs@spoerlein.net \
    --cc=discuss@mdocml.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).