discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Humm <hummsmith42@gmail.com>
Cc: discuss@mandoc.bsd.lv
Subject: Re: \h in PostScript and PDF output
Date: Mon, 10 Jan 2022 19:50:08 +0100	[thread overview]
Message-ID: <Ydx/4Dd5KNfjlWL5@asta-kit.de> (raw)
In-Reply-To: <YdxisxXNTBOQLMoB@beryllium.local>

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 <hummsmith42 at gmail dot com> 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 <schwarze@openbsd.org>
+ * Copyright (c) 2010-2022 Ingo Schwarze <schwarze@openbsd.org>
  * Copyright (c) 2008, 2009, 2010, 2011 Kristaps Dzonsons <kristaps@bsd.lv>
  *
  * 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


      reply	other threads:[~2022-01-10 18:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-09 13:59 Humm
2022-01-10  7:37 ` Ingo Schwarze
2022-01-10 16:45   ` Humm
2022-01-10 18:50     ` Ingo Schwarze [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ydx/4Dd5KNfjlWL5@asta-kit.de \
    --to=schwarze@usta.de \
    --cc=discuss@mandoc.bsd.lv \
    --cc=hummsmith42@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).