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 30358 invoked from network); 16 Oct 2023 17:10:38 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2023 17:10:38 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 4182957d for ; Mon, 16 Oct 2023 17:10:35 +0000 (UTC) Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id fa037c62 for ; Mon, 16 Oct 2023 17:10:35 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 076F8CE1805 for ; Mon, 16 Oct 2023 17:10:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C31DDC433C8 for ; Mon, 16 Oct 2023 17:10:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697476231; bh=MA70Xt0CP7VXEpB7HLV8EQ7KSG4CSqmkBRQ9TDkHNOs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=If9C3YmJfCs3LqOKryRg1qveEyewz94y8FifSSOXFSanbgoyWgWpQ/Z1mclqqZIEn 4Wn8gChiTwPzoLDPhqAX6fFM+BIvx+ZdAp0hY5tK+BYq+k5IXLaqVekZU5/iJIY7yj Pvwv5FG7hVSiDocOrf2St7TzRDOX5eVDhtQYX3NoNEicz+ggjnmLcgoMIwUEIrPrgM QFPrhrmcu1MndVrZyddFzgLT9ew7RzXJ5vkRxJLjGS5yfoDq/E2ZcsPKSn8lZmYh3u 1fsdUB/HPIf0b3mAeNRhGtt5z8JMKjx6XpzMSP2UR6B/qVDo29yBAbKvxwWiqQBd+L NI3TrBfjiIz4Q== Date: Mon, 16 Oct 2023 19:10:22 +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="s7n0CUmELbc1wgnc" Content-Disposition: inline In-Reply-To: --s7n0CUmELbc1wgnc Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Oct 2023 19:10:22 +0200 From: Alejandro Colomar To: tech@mandoc.bsd.lv Subject: Re: mandoc -man -Thtml: unwanted line break after bullet (.IP) Hi Ingo, 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 I could reproduce it with the test file you sent. $ mandoc -Thtml test.1 > test.html I can reproduce with both: $ lynx test.html $ firefox test.html >=20 > mandoc -Thtml -Ostyle=3Dmandoc.css test.1 > test.html Where's this mandoc.css? Is it a file you have locally? >=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
>
Agree, I get this same HTML code. I don't see an html
element. >=20 > For testing, i have also put up the file here: >=20 > https://man.bsd.lv/Test/test.1 Yes, that looks good to me. >=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? 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=E2=80=90sh= eet classes available for customising output. If a style=E2=80=90sheet = is not specified with -O style, -T html defaults to simple output (via an embedded style=E2=80=90sheet) readable in any graphical = or text=E2=80=90based web browser. Is this a mandoc(1) bug? Or a packaging bug? >=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 ... 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 >=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 --s7n0CUmELbc1wgnc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmUtbn4ACgkQnowa+77/ 2zKDEg/9E6+sLoKz+MAg2YWxeyS6sKIbTdKAiyLIMfR8u2SwHA6wWyXVu9JtUnK+ 7/kCFTNuxr0lVXxs4Mt+JWZJ5AU8owRhipEhm6X2ICsRYVr1/GKVMqgCFJK2JRu3 lQHLq7SjjIJndtfuq6PSEHEQ0hx/k0usj3UYg/dmS5hjJXsq/Pu6q9mnpSjN/Ec2 RJJ0S1KJUNoz1y236230TpRgIKOagkdvhAByANzbgv68N+dwL2n9nb6ZTsu6V9t0 8jrRwsi+pfbWUe+SzQYTL+Nt21hZ2+YqhTmDZNGnHVFSx9ZYJ8fClaao7h15kz4X 5bl+Yfw+ldC76j7wOz6BSASqfCU8BrlJ4yWk//TQzKAHb+vQQZiOdmhzFFqyV3rR THx67fbJWrvjn9rVcquoWkdd2c65MiIMwugGNcV1vec4zEh3RTReNuuilzEpEEdT VuzN0gVUdjo5TvHtj6wQPtBFiVfdIV4Z4HFiBV2vYzeJRsf4ilaTAOCA3JWsN7v/ rKCavCgu98Wagqg3TBVsqRyBSHk8FZUzC7p/Urtow4KegS5YjbFFjs2baR1IjXXC 1ClpLV4oMepzpl/PGTFVgI/xlewMF5kPRvmv5z7L9rB6u9Fk03JQRtvvR24am1d3 FygHgXS0cpRDe37ae82Ag0PSL4MllS6kKG8KHipKBrRxzqMBNik= =Yqta -----END PGP SIGNATURE----- --s7n0CUmELbc1wgnc-- -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv