On Mon, Oct 16, 2023 at 07:10:22PM +0200, Alejandro Colomar wrote:
> Hi Ingo,
>
> On Mon, Oct 16, 2023 at 04:52:14PM +0200, Ingo Schwarze wrote:
> > Hi Alejandro,
> >
> > Alejandro Colomar wrote on Mon, Oct 16, 2023 at 03:17:07PM +0200:
> >
> > > mandoc -man -Thtml produces a line break after a .IP \[bu] 3
> > > groff(1) doesn't, which is consistent with how both mandoc(1) and
> > > groff(1) format that code in a terminal.
> > >
> > > Is that behavior intended, or accidental?
> >
> > So far, i'm unable to reproduce your problem.
> >
> > With the test file appended below and the command
>
> I could reproduce it with the test file you sent.
>
> $ mandoc -Thtml test.1 > test.html
>
> I can reproduce with both:
>
> $ lynx test.html
(I've seen your messages about lynx(1) now; never mind this line.)
> $ firefox test.html
>
> >
> > mandoc -Thtml -Ostyle=mandoc.css test.1 > test.html
>
> Where's this mandoc.css? Is it a file you have locally?
>
> >
> > i get the expected semantically correct output containing
> > dl, dt, and dd elements, but not the br element that you claim
> > to be present in the output you get. Specifically:
> >
> >
initial text
> >
> >
•
> >
final text
> >
>
> Agree, I get this same HTML code. I don't see an html element.
>
> >
> > For testing, i have also put up the file here:
> >
> > https://man.bsd.lv/Test/test.1
>
> Yes, that looks good to me.
>
> >
> > The output looks correct to me. There certainly isn't any line break
> > after the bullet; as expected, the "final text" follows on the same
> > line.
> >
> > Needless to say, when you worry about white space issues in web
> > design, correctly using CSS is essential, because obviously, the
> > HTML code only specifies the semantic structure of the text but
> > does *not* specifiy physical formatting details like white space
> > or line breaks.
> >
> > Can you be more specific which input file, which mandoc command,
> > and which CSS file you are using?
>
> I'm not using any. mandoc(1) seems to be requesting mandoc.css, which
> doesn't exist in my system, so that's probably the problem.
>
> The Debian package doesn't provide any CSS file, which seems like a
> packaging bug:
>
> $ apt-file show mandoc | grep css
> $ apt-file find mandoc.css
> $
>
> But the mandoc(1) manual page says that if no CSS file is specified, it
> should embed a style sheet in the HTML, which seems to contradict the
> resulting HTML:
>
> ```html
>
>
>
>
>
>
> TEST(1)
>
> ```
>
> mandoc(1):
> HTML Output
> ...
>
> The file /usr/share/misc/mandoc.css documents style‐sheet
> classes available for customising output. If a style‐sheet is
> not specified with -O style, -T html defaults to simple output
> (via an embedded style‐sheet) readable in any graphical or
> text‐based web browser.
>
>
> Is this a mandoc(1) bug? Or a packaging bug?
>
> >
> > If you worry about the relatively wide indentation of the "final text",
> > that's because mandoc.css hardcodes "margin-left: 5.5em;"
> > for the .Bl-tag class. Theoretically, mandoc(1) could honour
> > the .IP width argument by adding an explicit, physical-formatting
> > "style" attribute to the individial HTML dl element. But adding
> > style attributes to individual HTML elements is considered
> > deprecated and very bad style in modern HTML, so mandoc doesn't
> > do that.
> >
> > This really isn't specific to mandoc but applies to all web design
> > in general. If you use any HTML autogeneration tool (not just
> > mandoc) and embed any *physical* formatting instructions into
> > your document source code (in this case, the width argument "3"),
> > such crowbar-style coding will usually result in poor formatting
> > or be ignored outright by the HTML generation tool.
> >
> > > You can check it in the same ftm(7) page that I reported a bug
> > > recently.
> >
> > After copying
> >
> > https://manpages.debian.org/bullseye/manpages/ftm.7.en.html
> >
> > to my server at
> >
> > https://man.bsd.lv/Test/ftm.7#Feature_test_macros_understood_by_glibc
> >
> > i can't see the problem neither there nor on manpages.debian.org.
> > Note that manpages.debian.org *does* use the mandoc rendering engine,
> > so having a bug in mandoc that does not show up on manpages.debian.org
> > would be slightly surprising, unless the bug was recently introduced
> > in mandoc.
> >
> > Anyway, on both servers, i do not see line breaks after the bullets.
> > For example, look at the lines:
> >
> > The macros that you most likely need to use ...
> > Defining _XOPEN_SOURCE with a value of 700 or greater ...
>
> Hmm, in the bookworm page there's the bug, but not on buster. They
> probably format the pages with with the corresponding system. As a
> welcome side effect, this also helps trace the regression.
>
> Check here:
>
>
> I uploaded your test page in my server:
>
> (your browser will complain about the SSL cert; read here:
> ).
>
> This is what I'm using:
> $ dpkg -l | grep mandoc
> ii mandoc 1.14.6-1+b1 amd64 BSD manpage compiler toolset
>
>
> Cheers,
> Alex
>
> >
> > Yours,
> > Ingo
> >
> >
> > .TH TEST 1
> > .SH NAME
> > test \- test
> > .SH DESCRIPTION
> > initial text
> > .IP \[bu] 3
> > final text
> > --
> > To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
> >
>
> --
>
--