From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, T_TVD_MIME_EPI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 30610 invoked from network); 16 Oct 2023 17:16:14 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2023 17:16:14 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 14ca1ae6 for ; Mon, 16 Oct 2023 17:16:13 +0000 (UTC) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 2ed7a9e0 for ; Mon, 16 Oct 2023 17:16:13 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1E0FE61025 for ; Mon, 16 Oct 2023 17:16:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47428C433C7 for ; Mon, 16 Oct 2023 17:16:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697476571; bh=Y7MX7e3FylheiJuoZEpL/lXV4P9dQ4jsbGe/szb+qeU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=sKJyohpoqO/GkH2NihBwDJhFi8j/Zf8ws8PJECGfYxANg3FoTIP/kPEgmPummtCa7 xPZlOlBCzDujiUXEv1mO3gTB+ovj5PZ8f8sa+wmLHXK5T7BG0AzMsvRmkebp2uuLnl 0x0r0u/gtqSEPIjbA+epMvlxJ1KefyK92pnt4N5nRn40Pf/omehSLbhsm5FaVU8b/J qOu2sD4oQe1fhIBIMUxnbd8QgSvXOHZCPvAave4Kd66rOcKzKftw8g3pZhqet+d+qU SdpNGhUpCg/aFSt8mxc9kodnFRwfkFXWh3ILFPcjQArfgv5mCOASzWFsphKNW8TzbP NoJ4rz+mHpqIg== Date: Mon, 16 Oct 2023 19:16:08 +0200 From: Alejandro Colomar To: tech@mandoc.bsd.lv Subject: Re: mandoc -man -Thtml: unwanted line break after bullet (.IP) Message-ID: References: X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ejt6uQF0sgNE4mOs" Content-Disposition: inline In-Reply-To: --Ejt6uQF0sgNE4mOs Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Oct 2023 19:16:08 +0200 From: Alejandro Colomar To: tech@mandoc.bsd.lv Subject: Re: mandoc -man -Thtml: unwanted line break after bullet (.IP) On Mon, Oct 16, 2023 at 07:10:22PM +0200, Alejandro Colomar wrote: > Hi Ingo, >=20 > On Mon, Oct 16, 2023 at 04:52:14PM +0200, Ingo Schwarze wrote: > > Hi Alejandro, > >=20 > > Alejandro Colomar wrote on Mon, Oct 16, 2023 at 03:17:07PM +0200: > >=20 > > > 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. > > >=20 > > > Is that behavior intended, or accidental? > >=20 > > So far, i'm unable to reproduce your problem. > >=20 > > With the test file appended below and the command >=20 > I could reproduce it with the test file you sent. >=20 > $ mandoc -Thtml test.1 > test.html >=20 > I can reproduce with both: >=20 > $ lynx test.html (I've seen your messages about lynx(1) now; never mind this line.) > $ firefox test.html >=20 > >=20 > > mandoc -Thtml -Ostyle=3Dmandoc.css test.1 > test.html >=20 > Where's this mandoc.css? Is it a file you have locally? >=20 > >=20 > > 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: > >=20 > >

initial text

> >
> >
•
> >
final text
> >
>=20 > Agree, I get this same HTML code. I don't see an html
element. >=20 > >=20 > > For testing, i have also put up the file here: > >=20 > > https://man.bsd.lv/Test/test.1 >=20 > Yes, that looks good to me. >=20 > >=20 > > 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. > >=20 > > 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. > >=20 > > Can you be more specific which input file, which mandoc command, > > and which CSS file you are using? >=20 > 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. >=20 > The Debian package doesn't provide any CSS file, which seems like a > packaging bug: >=20 > $ apt-file show mandoc | grep css > $ apt-file find mandoc.css > $ >=20 > 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: >=20 > ```html > > > > > > > TEST(1) > > ``` >=20 > mandoc(1): > HTML Output > ... >=20 > The file /usr/share/misc/mandoc.css documents style=E2=80=90= sheet > classes available for customising output. If a style=E2=80=90shee= t is > not specified with -O style, -T html defaults to simple output > (via an embedded style=E2=80=90sheet) readable in any graphica= l or > text=E2=80=90based web browser. >=20 >=20 > Is this a mandoc(1) bug? Or a packaging bug? >=20 > >=20 > > 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. > >=20 > > 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. > >=20 > > > You can check it in the same ftm(7) page that I reported a bug > > > recently. > >=20 > > After copying > >=20 > > https://manpages.debian.org/bullseye/manpages/ftm.7.en.html > >=20 > > to my server at > >=20 > > https://man.bsd.lv/Test/ftm.7#Feature_test_macros_understood_by_glibc > >=20 > > 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. > >=20 > > Anyway, on both servers, i do not see line breaks after the bullets. > > For example, look at the lines: > >=20 > > The macros that you most likely need to use ... > > Defining _XOPEN_SOURCE with a value of 700 or greater ... >=20 > 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. >=20 > Check here: > >=20 > I uploaded your test page in my server: > > (your browser will complain about the SSL cert; read here: > ). >=20 > This is what I'm using: > $ dpkg -l | grep mandoc > ii mandoc 1.14.6-1+b1 amd64 BSD manpage compiler toolset >=20 >=20 > Cheers, > Alex >=20 > >=20 > > Yours, > > Ingo > >=20 > >=20 > > .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 > >=20 >=20 > --=20 > --=20 --Ejt6uQF0sgNE4mOs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmUtb9gACgkQnowa+77/ 2zL03A/+P9VkTq9HKx26ox01Q7NpNKh/qOCRn3sJXXmWNGegIxX/OuXyuJkZaQwy 3ZnidniJ323EuW7tAkKS4BIr9oN/5Cc7yPDtPJoRf286+iQii05tYU5Bpaa3F5p8 fC4BdY6vQK+Zy4JCICrJ2rK9TRRd9ZNc01kVnhWt2wQwUPpln3svmUC/l0qC3cwU YXSOWazyRzDYHK8wdl/f/z1pL5sY05GARmncnaj/c5CtFgNX4NZ9VNiEuT/bfmBZ SlSA7Ve8twTsN3/M1hwF5cgPb3bHjpTtxhKVPL0/hYBQt3sYPQCWuSH+ZGmSWV8O dJXlyUaCW4dDJaGqoDCeaqEM3Tw7ovAEpVjDShVvVFjU5jiAC0gPKc6Iv4VifDL+ 1/OsC0/3X5AF9FT2Io7sSShUG9SlkuScT8f6skKqObSw5fDBBJI6KArp41j/gIv6 vq++m9a+HrBz3bKaxeD1Xpe9vcirsUdccP7lQJWc/3AkBVpLR0HqX7G68M4u2vjt rQPCd2jz+sQlH2bGQtC4lCs5/+Z0EPv7Hiu3sU+9l3SY9Z7/GPR53+2KLqh9SwOx asNmZNBJHe0t81XZC+GV8482JJCVxIfFzul6fNccIkfx8Mh4jNogiCHqq77d4t7G 8zBRZxB0qUM7rQ4sc13WBK0U3uvY00E2UN+AEmm1YBvlF7iLRLU= =s/sn -----END PGP SIGNATURE----- --Ejt6uQF0sgNE4mOs-- -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv