bugGNU troff - Bugs: bug #50917, Make \- consistently render as...


bug #50917: Make \- consistently render as U+002D across all macro sets and devices

Submitted by:  Ingo Schwarze <schwarze>
Submitted on:  Tue 02 May 2017 05:04:49 PM UTC  
Category:  None Severity:  3 - Normal
Item Group:  New feature Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Tue 24 Jul 2018 10:37:22 PM UTC, comment #6: 

> If you want to file a bug report saying "-man -Thtml and -mdoc -Thtml render \- as minus but should render it as hyphen-minus just like -Tutf8", maybe another developer deems it worthy of investigation.

Such a bug report would meet resistence by other people, with arguments like "In the default Firefox fonts, a hyphen-minus looks more like a hyphen than like a minus sign. I therefore want \- to render as a minus sign."

My main argument is copy&pastability. Their main argument is the rendering (for man pages where copy&paste is not relevant). Impossible to reconcile, except by introducing \(hm.

Bruno Haible <haible>
Tue 24 Jul 2018 09:46:55 PM UTC, comment #5: 

Hello Bruno - wrt comment #4:

I do not accept \(pl and \(mi.  Using them in manual pages is strongly discouraged, and no manual page author is expected to have heard about them.  They are intended for specialized mathematical typesetting, and in that context, they are not ugly: many mathematical symbols require roff escape sequences.  But in manual pages, asking people to learn about arcane and ugly stuff like \(pl, \(mi, and the hypothetical \(hm would be unacceptable.
It is already bad enough that manual page authors have to consider the differences among "-" (hyphen), "\-" (hyphen-minus and minus), and "\(en" (dash) - but at least here the concept is well-known from classical typography.  Adding yet another escape sequence \(hm that does not even exist in classical typography is not going to fly.  Besides, i'm not volunteering to edit the many thousand existing manual pages to introduce it (which requires manual work), and i assume you aren't either.

Regarding -Thtml, it may well be a bug that \- renders as minus rather than as hyphen-minus.  It doesn't seem unlikely to me that it can be changed, using a similar approach as in the terminal formatters for -man and -mdoc.  All i'm saying is that i don't deem -Thtml worthy of wasting time on, not even to investigate a minor potential bug, and that this ticket is unrelated to HTML in any case.

If you want to file a bug report saying "-man -Thtml and -mdoc -Thtml render \- as minus but should render it as hyphen-minus just like -Tutf8", maybe another developer deems it worthy of investigation.  Though frankly, i consider -Thtml unmaintained for almost a decade.  The last bugfix commit in src/devices/devhtml was by wl@ on Feb 25 19:34:08 2010.

Ingo Schwarze <schwarze>
Project Member
Tue 24 Jul 2018 08:38:09 PM UTC, comment #4: 

> Unfortunately, there is no better option, and none can be designed.

You did list the solution:
\(hm : U+002D : hyphen-minus
This would provide what I ask for.

If you accept \(pl and \(mi, what is wrong with \(hm ?
Why do you call one "ugly", when the other two are not "ugly"?

> groff -Thtml is notoriously weak

All the other problems of "groff -Thtml" are not interesting here. If you introduce \(hm, surely it is possible to map it to U+002D in "groff -Thtml".

Bruno Haible <haible>
Tue 24 Jul 2018 05:47:48 PM UTC, comment #3: 

Hello Bruno - wrt comment #2:

note that this issue is marked as "invalid - closed", so there is nothing to do in groff.

That said, using help2man(1) is very bad practice.  It always results in manual pages of extremely low content quality.  If you feel that you must auto-generate manual pages, then please use the perlpod(1) input format.  The transformation tool, pod2man(1), generates the best quality autogenerated man(7) code i'm aware of.  Of course, it provides no semantic markup and it is not quite as pretty as properly hand-written man(7) or mdoc(7) code, but it is tolerable.

That said, representing hyphen-minus as \- is best practice.  Unfortunately, there is no better option, and none can be designed.

groff -Thtml is notoriously weak, so it's no big surprise that it has many problems.  That's unrelated to the (unfortunately fatally flawed) idea discussed in this bug tracker entry.

Above all, every language is designed for writing it manually, and the question of how to represent hyphen-minus is common to the man(7) and mdoc(7) languages.  In particular, practically all BSD documentation is hand-written in mdoc(7), and much of non-BSD documentation is hand-written in man(7).  So even though quite some man(7) code is autogenerated (which it is, you are right about that, just consider all the Perl documentation), it is still important to keep writing manual pages simple and non-ugly for human authors, so introducing \(hm is not an option, unfortunately.

Ingo Schwarze <schwarze>
Project Member
Tue 24 Jul 2018 04:35:49 PM UTC, comment #2: 

> defining  \(hm : U+002D : hyphen-minus # NO!  would be so ugly that it couldn't reasonably be recommended for manual pages.

In many GNU packages, nowadays, the man pages are generated from the programs, by use of 'help2man'. If there was a sequence that is guaranteed to produce ASCII U+002D, 'help2man' could use it; it doesn't matter for generated manual pages whether the syntax is ugly or not.

In the current state, 'help2man' produces '\-' in its output. Which produces copy&pastable U+002D in 'groff -Tutf8 -mandoc' output. But it produces '&minus;' (U+2212) in 'groff -Thtml -mandoc' output, which I have to revert through postprocessing: sed -e 's/\&minus;/-/g'

Bruno Haible <haible>
Fri 12 May 2017 10:07:50 PM UTC, comment #1: 

Sorry for the confusion, but this patch is wrong for two reasons:

1. The idea to "consistently render as U+002D across all output devices" is ill-defined.  There is no such thing as a U+002D (or ASCII HYPHEN-MINUS) output glyph on some devices, namely on -Tps and -Tpdf.  The PostScript TR font has glyphs for "hyphen", "minus", and "endash", but nor for "hyphen-minus".

2. Unicode is not a superset of everything, in the following sense: if two glyphs represent the same Unicode character, that doesn't imply that they are the same glyph.  So it may well make sense to have two input characters that map to the same Unicode character, but to different output glyphs.  In particular, Doug McIlroy pointed out the following long-established definition:

input : Unicode : output

  +   : U+002B  : plus (normal font, e.g. for running text)
 \(pl : U+002B  : plus (special font, e.g. for mathematics)
 \-   : U+2212  : minus (normal font, e.g. for running text)
 \(mi : U+2212  : minus (special font, e.g. for mathematics)

So redefining

 \-   : U+002D  : hyphen-minus   # NO!

is sadly not an option because it would break lots of existing non-manual-page documents.

So the problem cannot be solved, at least not without defining a completely new input character.  But defining

 \(hm : U+002D  : hyphen-minus   # NO!

would be so ugly that it couldn't reasonably be recommended for manual pages.  So the problem has no complete solution, and the current workaround of using \- in manual pages and rendering it as U+002D for manual page UTF-8 output only already is the best possible compromise.

So please close this bug report as invalid.

Ingo Schwarze <schwarze>
Project Member
Tue 02 May 2017 05:04:49 PM UTC, original submission:  

The attached patch has the following parts:

  • src/libs/libgroff/glyphuni.cpp

  This is the main mapping change.

  • src/libs/libgroff/uniglyph.cpp

  The reverse direction for consistency.

  • tmac/an-old.tmac tmac/doc.tmac-u PROBLEMS

  Remove redefinitions that are now obsolete
  because they are now done for all macro sets.

  • man/groff_char.7.man font/devutf8/NOTES

  Adjust documentation for \- and U+002D.

No changes are needed for devascii, devlatin1, devhtml.
As far as i understand, devps and devpdf are fine, too.
A brief look at some of the vendor-specific devices
gives me the impression that those probably don't need
changes, either.  If somebody who is more experienced
with the ps, pdf, and vendor-specific drivers could
cross-check, that would be welcome.  Otherwise, any
omissions in those other drivers can be fixed later
if and when any are found.

The motivation for this change is that right now, as observed by Ralph Corderoy, there is no way to request a U+002D HYPHEN-MINUS output glyph that works across all macro sets and devices, even though that is often needed when documentation programming language syntax or quoting code samples.  For more details, see the ongoing dicussion on <groff@gnu.org>.

Ingo Schwarze <schwarze>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #40562:  bs-minus.patch added by schwarze (4KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by carstenkunze (Updated the item)
  • -email is unavailable- added by schwarze (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-05-12 carstenkunze StatusNone => Invalid
        Open/ClosedOpen => Closed
    2017-05-02 schwarze Attached File- => Added bs-minus.patch, #40562

    Back to the top

    Powered by Savane 3.5