discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: discuss@mdocml.bsd.lv
Subject: Re: Raw UTF-8?
Date: Wed, 7 Jul 2010 20:58:15 +0200	[thread overview]
Message-ID: <20100707185815.GA19725@iris.usta.de> (raw)
In-Reply-To: <4c33f0f0.0c87970a.3458.fffff43f@mx.google.com>

Hi Anthony,

> When using special characters in manpages,

I consider that a terrible idea.  In a nutshell, such manuals are
useless on terminals.  If some piece of information is important, you
should really encode it such that all readers can see it.  If it is
unimportant, just leave it out instead of obfuscating it, which will
make some people wonder whether they are missing anything.

We should probably add a warning to discourage people from using
characters needing more than ASCII on output, saying something
like "this manual is not portable and will not display correctly
in some environments".

From my point of view, non-ASCII-output escape sequences are only
supported for backward compatibility with legacy manuals, and displaying
something semi-sensible in their place is done on a best-effort basis,
knowing that it is ultimately unreliable.  Using such escape sequences
in new mdoc(7) source code, you would only show that you don't care
about the usability of your manuals.

For the occasional proper name of an author, use transliteration
to ASCII.  I consider using non-ASCII-output escape sequences in
there a discourtesy with respect to the author, because then some
people will not be able to read the name.

> I use plain UTF-8 instead of the escapes documented in mandoc_char(7),
> for a couple reasons.  I'm just wondering, is this practice
> discouraged in any way?

Yes.  Eight-Bit characters in roff, man and mdoc source code are syntax
errors, just like they are in C and in any sane programming language.
The current implementation passes them through, but it could as well
throw them away, or abort the parser, subject to change without notice.

> Is there a chance of this _not_ working in future versions of mandoc?

If it works, that is by mere chance, but not portable in any way,
neither between output devices, nor between platforms, nor between
different versions of mandoc.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv

  parent reply	other threads:[~2010-07-07 18:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-07  3:13 Anthony J. Bentley
2010-07-07  9:33 ` Kristaps Dzonsons
2010-07-07 14:39   ` Anthony J. Bentley
2010-07-07 20:13     ` Ingo Schwarze
2010-07-07 18:58 ` Ingo Schwarze [this message]
2010-07-07 19:18   ` Joerg Sonnenberger
2010-07-07 21:12     ` Ingo Schwarze
2010-07-07 21:17       ` Joerg Sonnenberger
2010-07-09 21:05         ` Ulrich Spörlein
2010-07-10 18:11           ` J.C. Roberts
2010-07-11 22:17             ` Ingo Schwarze
2010-07-11 22:38           ` Kristaps Dzonsons
2010-07-13 19:23             ` Ulrich Spörlein
2010-07-13 23:25               ` Kristaps Dzonsons

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=20100707185815.GA19725@iris.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mdocml.bsd.lv \
    /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).