discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Ingo Schwarze <schwarze@usta.de>
Cc: discuss@mandoc.bsd.lv
Subject: Re: mandoc & perl documentation
Date: Mon, 26 Nov 2018 09:48:20 +0100	[thread overview]
Message-ID: <20181126084820.qcnoxobkontrodqv@pali> (raw)
In-Reply-To: <20181125182008.GB45828@athene.usta.de>

On Sunday 25 November 2018 19:20:08 Ingo Schwarze wrote:
> Hi Pali,
> 
> Pali Rohar wrote on Sun, Nov 25, 2018 at 02:34:26PM +0100:
> > On Saturday 24 November 2018 20:31:52 Ingo Schwarze wrote:
> >> Pali Rohar wrote on Fri, Oct 26, 2018 at 10:15:19AM +0200:
> 
> >>> And you can do any combination of them (e.g. typewriter font
> >>> which is both bold and italic together).
> 
> >> So, let's check the combinations:
> >> 
> >>  * I<B<...>>      to   \fI\f(BI...\fI\fR
> >>  * I<C<...>>      to   \fI\f(CI"..."\fI\fR
> >>  * B<I<...>>      to   \fB\f(BI...\fB\fR
> >>  * B<C<...>>      to   \fB\f(CB"..."\fB\fR
> >>  * C<I<...>>      to   \f(CW"\f(CI...\f(CW"\fR
> >>  * C<B<...>>      to   \f(CW"\f(CB...\f(CW"\fR
> >>  * C<I<...>>      to   \f(CW"\f(CI...\f(CW"\fR
> >>  * I<B<C<...>>>   to   \fI\f(BI\f(CB"..."\f(BI\fI\fR
> >>  * I<B<C<...>>>   to   \fI\f(CI"\f(CB...\f(CI"\fI\fR
> >>  * B<I<C<...>>>   to   \fB\f(BI\f(CB"..."\f(BI\fB\fR
> >>  * B<C<I<...>>>   to   \fB\f(CB"\f(CB...\f(CB"\fB\fR
> >>  * C<I<B<...>>>   to   \f(CW"\f(CI\f(CB...\f(CI\f(CW"\fR
> >>  * C<B<I<...>>>   to   \f(CW"\f(CB\f(CB...\f(CB\f(CW"\fR
>  
> > Question is if last 6 lines are correctly translated.
> 
> That is a question about pod2man(1), not a question about mandoc(1).
> Regarding mandoc(1), the question only is whether it correctly
> handles whatever pod2man(1) produces.
> 
> > Should not it be typewriter font which has both italic and bold
> > style? Because currently it is just bold typewriter and not italic.
> 
> In principle, yes, and i don't doubt that in the typesetting business,
> you can find fixed-width font families looking typewriter-like and
> providing a font with style bold+italic.
> 
> > Has troff, groff
> 
> That hardly matters.  If groff (or any other full roff implementation)
> does not provide a font with certain properties users desire, they
> can usually install additional fonts themselves.
> 
> > or mandoc some sequence of italic bold typewriter font?
> 
> For terminal, PostScript, and PDF output, mandoc does not provide
> any typewriter font whatsoever.  For terminal output, no other
> formatter can portably do so, either.
> 
> Regarding HTML output, there is actually a (rather tricky) way to
> request a typewriter-bold-italic font, and it does work in mandoc:
> 
>    $ cat tmp.man
>   .TH TEST 1
>   .SH NAME
>   test \(en test
>   .SH DESCRIPTION
>   initial text
>   .EX
>   .B
>   .I typewriter-bold-italic
>   .EE
>   final text
> 
>    $ mandoc -T html -O style=mandoc.css tmp.man
>   [...]
>   initial text
>   <pre>
>   <b><i>typewriter-bold-italic</i></b>
>   </pre>
>   final text
> 
> Now, <pre> requests monospace by default, so browsers typically
> render this text in a monospace bold-italic font.
> 
> Note that even though the above example file is correct and unambiguous,
> groff -T html totally mishandles it: it renders
> 
>   initial text
>   <i><br>
>   typewriter-bold-italic</i> <br>
>   final text
> 
> So both the typewriter and the bold a totally lost - the reason
> being that groff -T html cannot do structural analysis, and on the
> presentational level, .EX simply does ".ft CW", which the \fB from .B
> overrides, and which the \fI from .I overrides yet again.
> 
> 
> It is not obvious to me how the above could be made useful for Perl
> documentation.  The pod2man(1) program certainly cannot translate C<...>
> to .EX - not only because that is a man-ext GNU extension, but even
> more so because it is a block macro rather than an inline macro
> which would totally break both horizontal and vertical spacing.
> And i don't see any other macro in the man(7) language to request
> a typewriter font.  Even resorting to the low-level roff(7) .ft request
> wouldn't help because it would get overridden by the subsequent .B
> macro rather than stacking up with it.
> 
> So making all this useful for Perl would probably require using
> \f[CBI], but i have doubts about the portability.  Mandoc could
> easily be taught to cope (it doesn't right now, but would simply
> ignore \f[CBI]), but what about other formatters?

It looks like there is no standard way to support it. So I guess current
behavior of pod2man is the best what can be done.

> 
> >> Right now, it seems to me that pod2man(1) formats
> >> bulleted and numbered lists as
> >> 
> >>   .IP "\(bu" 6
> >>   First item.
> >>   .IP "\(bu" 6
> >>   Second item.
> >> 
> >> which is definitely fine,
> 
> > I'm not sure if it is fine.
> 
> Well, the rendering by pod2man(1) shown above certainly *is* fine,
> i don't see in which other way it could reasonably format such a list.

You are right, it is really OK.

> What you are calling into question below is whether mandoc(1) -T html
> handles the above man(7) code well.
> 
> > Here is simple test.pod file:
> > 
> > $ cat test.pod
> > =pod
> > 
> > =over
> > 
> > =item *
> > 
> > Description of item1
> > 
> > =item *
> > 
> > Description of item2
> > 
> > =back
> > 
> > =cut
> > 
> > Converting it directly to HTML via pod2html results in:
> > 
> > $ pod2html test.pod
> > ...
> > <ul>
> > <li><p>Description of item1</p>
> > </li>
> > <li><p>Description of item2</p>
> > </li>
> > </ul>
> > ...
> > 
> > But converting it into man and then via mandoc converting it into HTML
> > results in:
> > 
> > $ pod2man test.pod | ./mandoc -Thtml
> > ...
> > <div class="manual-text">
> > <div>&#x00A0;</div>
> > <dl class="Bl-tag">
> >   <dt>&#x2022;</dt>
> >   <dd>Description of item1</dd>
> > </dl>
> > <dl class="Bl-tag">
> >   <dt>&#x2022;</dt>
> >   <dd>Description of item2</dd>
> > </dl>
> > </div>
> > ...
> 
> You have a point here.  The mandoc -man -T html formatter could be
> improved in two respects:
> 
>  * If the argument to .IP is a single bullet-like character,
>    it could be rendered as <ul> rather than <dl>.
> 
>    Heh, checking the TODO file, i just noticed this was already
>    reported in https://github.com/Debian/debiman/issues/67 .
> 
>  * Subsequent .IP macros could be rendered into a common list
>    rather than opening a new list for each item.
> 
>    I just add a new TODO entry for this idea, see the commit below.

Ok, so resolving these two points on TODO list should fix above reported
problem.

> 
> > Bullet (&#2022) generated by mandoc is on previous line as description
> > text. So something is not there fine. I see it in chrome and also in
> > elinks:
> > 
> > $ pod2man test.pod | ./mandoc -Thtml | elinks -dump
> > ...
> >    •
> >            Description of item1
> > 
> >    •
> >            Description of item2
> > ...
> > 
> > And when I print mandoc output on terminal, then description and bullet
> > are on the same line:
> > 
> > $ pod2man test.pod | ./mandoc
> > ...
> >        •   Description of item1
> > 
> >        •   Description of item2
> > ...
> > 
> > So this looks like a problem in mandoc's HTML output.
> 
> No, *that* is not the problem.  The unusual line breaking is merely
> caused by your omission of "-O style=/path/to/mandoc.css".
> Without using a style sheet, expecting beauty in HTML rendering is
> not reasonable.
> 
> Unfortunately, i cannot make "-O style" the default because no
> sane default can be designed for "/path/to/".
> 
> Yours,
>   Ingo
> 
> 
> Log Message:
> -----------
> HTML formatting of .IP
> 
> Modified Files:
> --------------
>     mandoc:
>         TODO
> 
> Revision Data
> -------------
> Index: TODO
> ===================================================================
> RCS file: /home/cvs/mandoc/mandoc/TODO,v
> retrieving revision 1.275
> retrieving revision 1.276
> diff -LTODO -LTODO -u -p -r1.275 -r1.276
> --- TODO
> +++ TODO
> @@ -399,8 +399,14 @@ are mere guesses, and some may be wrong.
>    in the CSS for .Bl-tag first.
>    Reminded by Pali Rohar 25 Oct 2018 10:10:35 +0200.
>  
> +- format multiple subsequent .IP as a single list
> +  rather than opening a new list for each item
> +  Pali Rohar 25 Nov 2018 14:34:26 +0100
> +  loc *  exist **  algo *  size *  imp ***
> +
>  - format ".IP *" etc. as <ul> rather than <dl>
>    https://github.com/Debian/debiman/issues/67
> +  reminded by Pali Rohar 25 Nov 2018 14:34:26 +0100
>    loc ** exist ** algo ** size * imp ***
>  
>  - .Bf at the beginning of a paragraph inserts a bogus 1ex horizontal

-- 
Pali Rohár
pali.rohar@gmail.com
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

  reply	other threads:[~2018-11-26  8:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13 15:12 Pali Rohár
2018-09-13 15:32 ` Anthony J. Bentley
2018-09-13 15:36   ` Pali Rohár
2018-10-11  7:52 ` Pali Rohár
2018-10-11  8:54   ` Jan Stary
2018-10-23 17:45   ` Ingo Schwarze
2018-10-24  8:03     ` Pali Rohár
2018-10-25  1:51       ` Ingo Schwarze
2018-10-25  8:10         ` Pali Rohár
2018-10-25 21:30           ` Ingo Schwarze
2018-10-26  8:15             ` Pali Rohár
2018-11-24 19:31               ` Ingo Schwarze
2018-11-25 13:34                 ` Pali Rohár
2018-11-25 18:20                   ` Ingo Schwarze
2018-11-26  8:48                     ` Pali Rohár [this message]
2019-02-28 16:45                   ` Ingo Schwarze
2019-03-02 17:09                   ` Ingo Schwarze
2019-01-17  8:02           ` Ingo Schwarze
2018-11-04 20:00         ` Pali Rohár

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=20181126084820.qcnoxobkontrodqv@pali \
    --to=pali.rohar@gmail.com \
    --cc=discuss@mandoc.bsd.lv \
    --cc=schwarze@usta.de \
    /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).