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.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27502 invoked from network); 10 Jan 2022 18:50:15 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 10 Jan 2022 18:50:15 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 87155833 for ; Mon, 10 Jan 2022 13:50:12 -0500 (EST) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id c66b5bc7 for ; Mon, 10 Jan 2022 13:50:11 -0500 (EST) Received: from hekate.asta.kit.edu ([2a00:1398:5:f401::77]) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1n6zk9-00ADSb-Ov; Mon, 10 Jan 2022 19:50:10 +0100 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1n6zk8-001vE0-Dd; Mon, 10 Jan 2022 19:50:08 +0100 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.92) (envelope-from ) id 1n6zk8-00055F-Kx; Mon, 10 Jan 2022 19:50:08 +0100 Date: Mon, 10 Jan 2022 19:50:08 +0100 From: Ingo Schwarze To: Humm Cc: discuss@mandoc.bsd.lv Subject: Re: \h in PostScript and PDF output Message-ID: References: X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hello Lennart, Humm wrote on Mon, Jan 10, 2022 at 04:45:39PM +0000: > Quoth Ingo Schwarze: >> I believe that the patch appended below fixes the bug; it survived >> my testing without finding regressions, and i intend to commit it to >> openbsd.org and bsd.lv shortly. Does it work for you, too? > It does. Thank you for testing! Committed, see below. [...] >> I'll have to further inspect, fix, and test those nineteen places >> one by one. Uh oh... > Good luck have fun! Heh, thanks, but i could imagine less tedious work. :-| In particular since i'm not aware of any reasonable way to do regression testing of PostScript or PDF output... [...] > Yeah, the PDF and PostScript output doesn’t look as beautiful > as I have come to expect from computerized typesetting. Exactly. Mandoc is not a typesetting system but a manual page formatter focussing on terminal and HTML output. When i want real typesetting of manual pages to PostScript or PDF, even i use groff. [...] > I agree. .TP introduces vertical space between paragraphs. For some > reason, the author cares about that/doesn’t want it. That's what the (reasonably portable) .PD macro is designed for. It's mildly discouraged because it is a purely presentational macro, but nothing much is wrong with using it - after all, the whole man(7) language mostly provides presentational rather than semantic markup. $ man -T ascii -O width=72 -s 7 man PD Specify the vertical space to be inserted before each new paragraph. The syntax is as follows: .PD [height] The height argument is a roff(7) scaling width. It defaults to 1v. If the unit is omitted, v is assumed. This macro affects the spacing before any subsequent instances of HP, IP, LP, P, PP, SH, SS, SY, and TP. Or alternatively, if you don't care that much about portability, are content with groff and mandoc as supported formatters, and want better readability of the man(7) source code, you could use: TQ Like TP, except that no vertical spacing is inserted before the paragraph. This is a non-standard GNU extension and very rarely used even in GNU manual pages. Resorting to low-level roff(7) is just nuts and even more fragile than using a GNU extension like .TQ. Yours, Ingo Log Message: ----------- When rendering the \h (horizontal motion) low-level roff(7) escape sequence in -T ps and -T pdf output mode, use an appropriate horizontal distance by correctly using the term_len() utility function. Output from the -T ascii, -T utf8, and -T html modes was already correct and remains unchanged. Lennart Jablonka found and reported this unit conversion bug (misinterpreting AFM units as if they were en units) when rendering scdoc-generated manuals (which is a low quality generator, but that's no excuse for mandoc misformatting \h) on Alpine Linux. Lennart also tested this patch. Modified Files: -------------- mandoc: term.c Revision Data ------------- Index: term.c =================================================================== RCS file: /home/cvs/mandoc/mandoc/term.c,v retrieving revision 1.284 retrieving revision 1.285 diff -Lterm.c -Lterm.c -u -p -r1.284 -r1.285 --- term.c +++ term.c @@ -1,6 +1,6 @@ /* $Id$ */ /* - * Copyright (c) 2010-2021 Ingo Schwarze + * Copyright (c) 2010-2022 Ingo Schwarze * Copyright (c) 2008, 2009, 2010, 2011 Kristaps Dzonsons * * Permission to use, copy, modify, and distribute this software for any @@ -636,12 +636,14 @@ term_word(struct termp *p, const char *w if (a2roffsu(seq, &su, SCALE_EM) == NULL) continue; uc += term_hen(p, &su); - if (uc > 0) - while (uc-- > 0) + if (uc > 0) { + while (uc > 0) { bufferc(p, ASCII_NBRSP); - else if (p->col > (size_t)(-uc)) + uc -= term_len(p, 1); + } + } else if (p->col > (size_t)(-uc)) { p->col += uc; - else { + } else { uc += p->col; p->col = 0; if (p->tcol->offset > (size_t)(-uc)) { -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv