From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-042.btinternet.com (mailomta17-re.btinternet.com [213.120.69.110]) by sourceware.org (Postfix) with ESMTPS id CC5913858D33 for ; Wed, 22 Feb 2023 20:10:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CC5913858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.54.5]) by re-prd-fep-042.btinternet.com with ESMTP id <20230222201027.ICDB30996.re-prd-fep-042.btinternet.com@re-prd-rgout-002.btmx-prd.synchronoss.net>; Wed, 22 Feb 2023 20:10:27 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8DE84F88A6F7 X-Originating-IP: [81.153.98.246] X-OWM-Source-IP: 81.153.98.246 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvhedrudejledgudefudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemuceutffkvffkuffjvffgnffgvefqofdpqfgfvfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffgggfhffuvfhfjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepheeuffelvdelheevjeektdeufeeigfevhefgfefhtdelfefflefgvefhhfeikeffnecuffhomhgrihhnpehgnhhurdhorhhgnecukfhppeekuddrudehfedrleekrddvgeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdeingdpihhnvghtpeekuddrudehfedrleekrddvgeeipdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdpnhgspghrtghpthhtohepvddprhgtphhtthhopeeurhhirghnrdfknhhglhhishesufhhrgifrdgtrgdprhgtphhtthhopehnvgiflhhisgesshhouhhrtggvfigrrhgvrdhorhhg X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.246) by re-prd-rgout-002.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8DE84F88A6F7; Wed, 22 Feb 2023 20:10:27 +0000 Message-ID: Date: Wed, 22 Feb 2023 20:10:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 From: Jon Turney Subject: Re: [PATCH v3 0/2] newlib/libc/time/strftime: fix multi-page table format issues To: "newlib@sourceware.org" , Brian Inglis References: <20230217204902.3735-1-Brian.Inglis@Shaw.ca> <20230221041801.51970-1-Brian.Inglis@Shaw.ca> Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1191.1 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 21/02/2023 09:15, Corinna Vinschen wrote: > Jon, > > I'd like your GTG on the patchset before merging it. Sorry, I don't think this patchset is good as is. > On Feb 20 21:17, Brian Inglis wrote: >> Discussion about why newlib man generation by docbook2man is >> incompatible with how man is incompatible with groff/tbl/grohtml: >> >> https://lists.gnu.org/archive/html/bug-groff/2023-02/msg00118.html >> >> There does not appear to be good way to deal in docbook2man processing >> with generation of tables > "page" size, or that may not adversely affect >> other [newlib] doc man page tables, as the problem occurs solely on the >> strftime.3 man page! So, this seems to be saying that "strftime manpage misrenders under some circumstances", but I even after re-reading several times, I have no clear sense what that circumstance is exactly: generating html output? with current version of groff? a future one? (Your answer should be a single sentence) >> The imminent groff/tbl release fixes a number of tbl issues, so may >> affect man pages with tables differently. >> >> The following groff/grohtml release plans to change grohtml, from >> generating tables as PNG graphics, which don't work reliably on some >> "devices"/file formats, and are not searchable, to generating tables in >> searchable text form on all "devices"/file formats, and fix other >> related issues, so may also affect man pages with tables differently. >> >> So for the current release, localize the changes to the man page chew >> input embedded in the strftime.c source comments, and the generated >> strftime.3 man page table formatting. >> Be prepared to tweak formatting if doc generation needs it, and >> eventually eliminate custom processing. >> >> newlib/libc/time/strftime.c: split chew table of conversion format >> specifiers as man/tbl/groff can not handle large tables on all output >> devices/file formats I'm not sure "make it look worse in the typical case (someone looking at it in a terminal with 'man strftime') to make it look better in the atypical case (?)" is a good trade-off. >> newlib/libc/Makefile.inc: sed fix strftime.3 tbl/groff format issues: >> remove multiple "^l l$" tbl line formats at tops of tables; >> change remaining "^l l\.$" tbl line formats at tops of tables so second >> column is lx and extends to margin; >> remove "^.PP$" breaks before each format description as it misaligns >> text below format specifier; >> remove blank line between adjacent tables >> >> Brian Inglis (2): >> newlib/libc/time/strftime.c: split chew table of conversion format >> specifiers >> newlib/libc/Makefile.inc: sed fix strftime.3 tbl/groff format issues >> >> newlib/libc/time/strftime.c | 3 ++- >> newlib/libc/Makefile.inc | 1 + >> 2 files changed, 3 insertions(+), 1 deletion(-) >>