Hi Benno, I have some partial good news.
At 2025-02-17T11:52:27+0100, Benno Schulenberg wrote:
> Op 16-02-2025 om 15:13 schreef G. Branden Robinson:
> > > Is there a way to mark such long options in the man page so that
> > > browsers are prevented from breaking the marked text in any way?
> >
> > Yes. It sounds like what you're looking for is the hyphenation
> > control escape sequence, `\%`.
>
> I should have mentioned that I tried that, and that it doesn't work:
> it changes nothing in the produced HTML code. I had hoped that it
> would produce either a <nobr> or a <span class="nobreak">, with
> span.nobreak defined as {white-space: nowrap}.
I noticed that at https://nano-editor.org/dist/v7/nano.1.html you
generated the man page with groff 1.22.4. That release is over 6 years
old. groff 1.23.0 was released in July 2023.
(If you're running Debian stable, that would explain it.)
I'm pleased to report that HTML rendering is overall a bit better
looking (in my opinion) with groff 1.23.0, and better still with groff
Git. This is not due to any specific improvements in HTML styling, but
rather in tweaked defaults for man(7) typesetting in general that
happily produce more pleasant results in HTML as a side effect.
I'm attaching HTML renderings with groff 1.23.0 and the bleeding edge.
Regarding the hyphenation problem, the lump in the carpet moves after
groff 1.22.4. Because HTML output now produces − entities rather
than hyphens from *roff minus special characters (`\-`), HTML appears to
apply different automatic breaking rules. So even with much fiddling of
the size of my browser window, I can no longer reproduce
yadda yadda yadda --
restricted
...instead I can get...
yadda yadda yadda -
-restricted
...which I'm not sure is an improvement.
(If someone wants to argue about whether − is the correct HTML
entity to produce from `\-` in a man page, please start a different
thread for it. My own opinion might not be what you'd predict.)
[I wrote:]
> > I think an HTML-only solution is undesirable because hyphenation can
> > occur with any groff output device, and the problem you're trying to
> > solve is general.
I now think I was wrong here. With other output formats we have control
over breaking decisions. With (X)HTML specifically, we don't. Not
without taking steps to seize it, which as I understand it can't happen
without throwing CSS at the problem. Which we probably should do, to
avoid setting 200 letters per line and similar.
In the shorter run, wiring up an HTML "<nobr>" element may be the thing
to do. I'll have to check my copy of HTML 5 to see if that's not
deprecated or if I need to use a span and CSS as you suggest.
But wiring up to what? Well, let's give the new `pline` request some
exercise.
$ printf '\\%%\\-\\-restricted\n.pline\n' | groff -a
<beginning of page>
{type: line_start_node, diversion level: 0},
{type: hyphen_inhibitor_node, diversion level: 0},
{type: glyph_node, character: "\-", diversion level: 0},
{type: glyph_node, character: "\-", diversion level: 0},
{type: glyph_node, character: "r", diversion level: 0},
{type: glyph_node, character: "e", diversion level: 0},
{type: glyph_node, character: "s", diversion level: 0},
{type: glyph_node, character: "t", diversion level: 0},
{type: glyph_node, character: "r", diversion level: 0},
{type: glyph_node, character: "i", diversion level: 0},
{type: glyph_node, character: "c", diversion level: 0},
{type: glyph_node, character: "t", diversion level: 0},
{type: glyph_node, character: "e", diversion level: 0},
{type: glyph_node, character: "d", diversion level: 0}
<-><->restricted
The hyphen inhibitor node, of course! I think I know where to poke my
fingers to attack this problem, but we'll _also_ need to inject a
closing element at the point hyphenation becomes uninhibited again, and
I'm much less certain where in grohtml that can be done.
> For nano, only the man page itself and the HTML version are relevant.
> (The PDF is produced from the Texinfo file.) The wrapping with `man`
> is good, so I was looking to adjust only the HTML output.
It still might be useful to you to render nano's man page on a more
traditional typesetting device if you are again unsure of the
correctness of its HTML generation. That can help to narrow down where
the problem arises.
I think I have enough information to file a Savannah ticket, though I
can't promise I'll get to this specific problem before the groff 1.24.0
release, which is weeks overdue. Would you like to be CCed by Savannah
on the ticket traffic?
Regards,
Branden
signature.asc
Description: PGP signature
