discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Mark Harris <mark.hsj@gmail.com>
Cc: discuss@mandoc.bsd.lv
Subject: Re: .br vertical spacing in html output
Date: Sun, 2 Dec 2018 18:21:34 +0100	[thread overview]
Message-ID: <20181202172134.GD11586@athene.usta.de> (raw)
In-Reply-To: <fd14efed-283d-3921-1ae9-f0725481725b@gmail.com>

Hi Mark,

Mark Harris wrote on Sat, Dec 01, 2018 at 01:31:05PM -0800:

> With -Thtml, with or without -Ostyle=mandoc.css, a roff .br (line break)
> directive is producing a large vertical space between lines.

It is not the .br causing the vertical space, but the leading
whitespace on your Greek lines.

> This is
> unexpected and does not occur with -Tascii/utf8.  Here is an example:

That example is terrible style.  Some hints inline.

> --- foo.1 ---
> .TH foo 1
> .SH OPTIONS

Never use the non-standard section .SH OPTIONS,
use the standard section .SH DESCRIPTION instead.

> .IP -a
> Enable a
> .IP -b
> Enable b
> .IP -c
> The following lines are expected to be single-spaced:
> 

Never, ever insert a blank line into any manual page file.

If you want a paragraph break, use ".PP" in man(7) or ".Pp" in mdoc(7).

If you want visual structuring of the source code without changing
the content and formatting, use an empty macro line, i.e. a line
containing nothing but a single dot (though such structuring is
usually not done in BSD manuals because it merely makes the source
code longer with no formatting benefit).

>   Alpha

What is the point of the leading whitespace here?

In manual pages, that is an obscure way to request a physical line
break that i would strongly discourage because the behaviour is not
very reliable (as you have just seen) and even more so because it is
extremely confusing for human readers.

If you want a paragraph where no automatic line-breaking is done
but the existing line breaks are preserved, use an ".nf" ... ".fi"
block in man(7) or a ".Bd -unfilled" (or ".Bd -literal" if that's
what you want) ... ".Ed" block in mdoc(7).

If you want a single physical line break in the middle of otherwise
normally filled text, you can use the ".br" request.  It occasionally
makes sense in man(7) code, but i'd not recommend it in mdoc(7), it
is almost never needed and breaks the semantic paradigm.

Using *both* ".br" and leading whitespace together certainly makes
no sense whatsoever.

If you want indentation, use ".IP" or ".RS" in man(7) or ".Bd -offset"
in mdoc(7).

> .br
>   Beta
> .br
>   Gamma
> .br
>   Delta
> 
> The lines are single-spaced as expected with -Tascii, but with -Thtml
> there is a large amount of space between the lines.
> .IP -d
> Enable d
> ------
> 
> The missing vertical space between .IP paragraphs can be ameliorated by
> removing the dl styling from the stylesheet,

Don't do that, it will totally break formatting of tagged lists in
most other manual pages.  The styling of tagged lists is by far the
hardest part of the stylesheet.  It is not perfect yet, but what there
is now is the best compromise we could come up with so far.
There are many things one can freely tweak in mandoc.css, but <dl>
is the last thing you should touch.

I'm not aware of any way to get vertical spacing between tagged list
items right now that doesn't break something else that is worse.
I have talked to many people about the problem for years and at least
three promised to solve the issue, but none managed to.

In a nutshell, the problem to solve is that the tag needs to be
left of the body when the tag is short, or above the body when the
tag is long (again, without breaking anything else).

> but I don't see an easy way to address the extra .br spacing with the
> stylesheet.  Is this something that can be addressed in mandoc?

I agree that the vertical spacing of .br + leading whitespace is
incorrect.  It is related to the question of flow content vs.
phrasing content in HTML.  Some improvements were reached in the
past to avoid HTML element nesting errors in mandoc output, but
some parts are still a mess, and what you report can hardly be fixed
without sorting that out.  So i have just started an audit of mandoc
with respect to the emission of flow content and phrasing content
and whether both are correctly nested; i wanted to do that for some
time anyway.  In that context, your issue will get fixed as a side
effect.  I'll tell you when it's done.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

  reply	other threads:[~2018-12-02 17:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-01 21:31 Mark Harris
2018-12-02 17:21 ` Ingo Schwarze [this message]
2018-12-03 16:30 ` Ingo Schwarze
2018-12-04  3:38 ` Ingo Schwarze

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=20181202172134.GD11586@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mandoc.bsd.lv \
    --cc=mark.hsj@gmail.com \
    /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).