Re: [Groff] ASCII Minus Sign in man Pages.

[G. Branden Robinson]

At 2017-04-25T15:00:26+0200, Ingo Schwarze wrote:
> I don't worry about groff HTML output at all.  By the basic design
> of groff, it is unable to produce good HTML, so i basically just
> ignore groff HTML output completely.  I fully agree with you that
> i see no need to change it.  I'd even go one step further and say
> there is no benefit to maintaining it at all.

It sounds like there is a lot in groff you'd like to throw away.

an-ext.tmac, grohtml, ...

> > "hm" appears to be available in the namespace for short character
> > escapes.  Would "\(hm)" be a good way to offer people U+002D for
> > when they're absolutely sure they mean it?
> 
> I don't think that is a good idea.  It would be a step backwards
> in terms of simplicity and usability.  In manual pages, you almost
> always want U+002D, and both the simple and natural input "-" and
> the traditional input "\-" already do that for -Tascii and -Tutf8,
> the output modes that people use most for manual pages.

Yes.  How is this an argument against?  Our other conversation aside,
I'm not thinking only of the use case of the drooling newbie.  The man
and mdoc macros should do the right thing requiring the least thought
for the common case, and documenting U+002D-prefixed command-line
arguments is extremely common.

What's simple and usable about the status quo?  If I want to represent
ASCII 45 decimal in my document, what's the simple and usable way to
make sure I get the glyph I want, with today's *roff?

Does this simple and usable way port across output devices?  Across
macro packages?

> Telling people to use "\(hm" instead would make a simple thing more
> complicated and less natural for manual page authors.  I don't think
> that is acceptable.  It is OK to tell advanced authors who care
> about the finer details of typesetting: "If, in exceptional cases,
> you want this particular effect, you can use this escape sequence".
> But for the simple stuff everybody needs all the time, simplicity
> is paramount, and escape sequences should not enter the picture
> unless absolutely unavoidable (like with \e).

You confuse me.  Having \(hm is a bad idea--okay.

How, then, to enable the sophisticated writer to get a guaranteed U+002D
regardless of the output device?  Make them write a bunch of .if and .ie
macros and test the .T string register every time?

You asked:

> My question is: Which is a good way to do that consistently,
> for *all* output devices?

It sounds like we don't have one.  How about we make one?

> > In any event, grohtml seems to be mapping all of -, \-, and \(hy to
> > U+002D (see attachments), which doesn't seem ideal to me given the
> > capabilities and character repetoire of most HTML renderers.
> 
> Right.  Given that HTML supports Unicode entities, HTML output
> ought to produce the same characters as -Tutf8.  For example,
> mandoc does that.  But again, i consider working on groff HTML
> output a waste of time.  PostScript and PDF is what matters most.

Do you have something to tell people wishing to improve grohtml besides
"it's a bad idea and a waste of time"?

-- 
Regards,
Branden