comment #7:

> I think resolving this one amounts to understanding why the
> unintended hyphenation occurs.

First comes defining what "the unintended hyphenation" is.  The current Bugs wording (which I'll dub the Space Bug) and the text Gaius proposed in comment #1 (henceforth the Header Bug) may not be describing the same bug.  I'm less than certain about this because I'm still not sure I understand what the former is trying to say, though I took a stab at an interpretation in comment #4.  But there may be more than one hyphenation-based problem.

> I have a hypothesis in comment #3,

This hypothesis appears to relate to the Header Bug.  The Space Bug (as interpreted in comment #4) seems to hinge on the "Why doesn't that work?" query in comment #5.

comment #5:

> comment #4:
> > the user might want lines in the HTML source broken in
> > reasonable places for easier handling in a text editor.
>
> But that's not the source form of the document, so why
> would they bother?

Who can understand the inscrutable actions of users?

But point taken; a more realistic reason might be for easier viewing in "less".  Sometimes it's a little easier to work with lines of manageable length, and if the HTML renderer doesn't care, why not let groff generate the easier-for-humans thing?

> >  To an HTML renderer, a space and a newline are equivalent,
>
> Except when <pre> is used.

Also a good point.

> > I see no downside to this for the vertical dimension.
>
> I see none for the horizontal dimension either,

It's admittedly a nicety, but one that can certainly be punted down the line until the software stops referring to itself as beta code.  There are much bigger grohtml fish to fry.  (And some of its most glaring limitations seem to not even have Savannah tickets.)

But all this seems far afield of the original bug report and perhaps ought to have its own ticket.

comment #2:

> the user ought to be strongly encouraged to disable automatic
> hyphenation in documents targeting HTML.

Self follow-up: it turns out the user needn't be encouraged or discouraged from any such thing, as tmac/html.tmac already disables hyphenation and disallows the user to turn it back on: http://git.savannah.gnu.org/cgit/groff.git/tree/tmac/html.tmac?id=a246806d81351996ac2fa4a8f0826915e576bc0f#n25


comment #3:

> grohtml does try to set the line length really long.

In light of the above, this seems unnecessary, and potentially even counterproductive: the user might want lines in the HTML source broken in reasonable places for easier handling in a text editor.  To an HTML renderer, a space and a newline are equivalent, so where line breaks occur in the HTML that groff outputs won't affect the rendered page at all.

...with one exception, and that is if groff breaks a word at a hard hyphen, which it is usually free to do regardless of the hyphenation setting.  It strikes me now that this may be what the incomprehensible(-to-me) sentence that launched this bug was trying to get at.

On the third hand, even that ought to be disabled by the .cflags line in html.tmac (see the link above).  So I'm no more enlightened than when I started this reply.

> We could define a new papersize that is effectively infinite
> in both dimensions...

I see no downside to this for the vertical dimension.

comment #1:

> Maybe an improved statement would be:
>
> grohtml does not accurately support hyphenation and sometimes it
> is necessary to set the page width to a large value to avoid
> generating an hyphenation in the title (using ms macro set).

That's perfectly comprehensible, but "does not accurately support" is still vague about what grohtml does or does not do with word breaking.

In general--and in contrast to every other output device groff supports--the page layout for HTML will be done by software well outside groff's control, so the user ought to be strongly encouraged to disable automatic hyphenation in documents targeting HTML.

The grohtml man page (as of a Sep 19, 2020 commit) has this item under Bugs, quoted here in its entirety:

"grohtml does not truly support hyphenation, but you can fool it into hyphenating long input lines, which can appear in HTML output with a hyphenated word followed by a space but no line break."

I find this sentence perplexing.  I asked about it on the mailing list a month ago (http://lists.gnu.org/r/groff/2023-07/msg00002.html), but no one responded, meaning no one else understood it either, or its meaning was so obvious no one wanted to waste their time on a reply.

The sentence makes a little more sense to me if I presume that a couple of the words are typos, and mentally edit it to: "...hyphenating long input WORDS, which can appear in HTML output AS a hyphenated word followed by a space..."

But even this does not clear up a couple of my questions:

• What bug is being documented here?  (1) The act of fooling grohtml (i.e., you might inadvertently fool grohtml into doing this buggy thing), or (2) the lack of hyphenation, for which fooling grohtml is the workaround?  (My suspicion is (1), since HTML documents should never contain hyphenated words, but this isn't clear to me from this sentence, the only one in the man page that mentions hyphenation.)
• How does one so fool grohtml?

As a possible source of illumination, I looked up the commit that added this sentence (051d5d5b), hoping its log entry might shed some light, but it did not.  In fact, nothing in the log even acknowledges any content changes, only style ones, yet the commit itself alters the content of both items in grohtml(1)'s Bugs section.  This is unusual enough for the typically comprehensive Branden log entry (and this one covers several less significant changes) that I wonder if those Bugs changes weren't intended to be in this commit at all, but snuck in with all the style changes.