From: Humm <hummsmith42@gmail.com>
To: Ingo Schwarze <schwarze@usta.de>
Cc: discuss@mandoc.bsd.lv
Subject: Re: \h in PostScript and PDF output
Date: Mon, 10 Jan 2022 16:45:39 +0000 [thread overview]
Message-ID: <YdxisxXNTBOQLMoB@beryllium.local> (raw)
In-Reply-To: <YdviRErxwF9Bn5n7@asta-kit.de>
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.
>Do you want to be credited in the commit message and in the next release
>notes for reporting the bug? If so, please send me a complete real name.
>If you do not send a complete real name, i shall credit you as
> Humm <hummsmith42 at gmail dot com>
>in the commit commit message but probably not mention you at all
>in the release notes. The release notes do not contain mail addresses,
>and "Humm" alone isn't really helpful to identify anybody.
Sure, Lennart Jablonka it is then.
>While researching this table, i found nineteen (19!) additional
>candidate places where i strongly suspect that a call to term_len()
>is either missing or this function is called incorrectly, resulting in
>more or less wrong positioning of PostScript and PDF output (ASCII,
>UTF-8, and HTML output are not wrong in these cases). I'll have
>to further inspect, fix, and test those nineteen places one by one.
>Uh oh...
Good luck have fun!
>I freely admit that while mandoc PostScript and PDF output is usable
>for many simple purposes, its quality is significantly below the
>quality of ASCII, UTF-8, and HTML output, in several respects -
>some of these respects are conceptional, and bugs are also more
>numerous for PostScript and PDF.
Yeah, the PDF and PostScript output doesn’t look as beautiful as I have
come to expect from computerized typesetting.
>Right, that's incredibly stupid. I hate it when people who do not
>understand the man(7) language but go ahead and write man(7) code
>generators anyway. In this particular case, the man(7) language
>provides the .TP macro for just that purpose, so mucking around
>with .RS and rather fragile low-level roff(7) code is quite absurd.
I agree. .TP introduces vertical space between paragraphs. For some
reason, the author cares about that/doesn’t want it.
--
Humm
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
next prev parent reply other threads:[~2022-01-10 16:45 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 [this message]
2022-01-10 18:50 ` Ingo Schwarze
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=YdxisxXNTBOQLMoB@beryllium.local \
--to=hummsmith42@gmail.com \
--cc=discuss@mandoc.bsd.lv \
--cc=schwarze@usta.de \
/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).