Document that -T markdown produces ASCII output, and the implied

limitations.  Of course, we could write UTF-8 output instead,
but even the CommonMark specification doesn't require parsers
to support that, so portability would be doubtful.

While here, provide a link to the CommonMark specification.

1 files changed, 12 insertions, 2 deletions

diff --git a/mandoc.1 b/mandoc.1
index 275540ee..8d87007d 100644
--- a/mandoc.1
+++ b/mandoc.1
@@ -1,4 +1,4 @@
-.\"	$Id: mandoc.1,v 1.177 2017/03/06 17:26:04 schwarze Exp $
+.\"	$Id: mandoc.1,v 1.178 2017/03/08 19:40:59 schwarze Exp $
 .\"
 .\" Copyright (c) 2009, 2010, 2011 Kristaps Dzonsons <kristaps@bsd.lv>
 .\" Copyright (c) 2012, 2014-2017 Ingo Schwarze <schwarze@openbsd.org>
@@ -15,7 +15,7 @@
 .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 .\"
-.Dd $Mdocdate: March 6 2017 $
+.Dd $Mdocdate: March 8 2017 $
 .Dt MANDOC 1
 .Os
 .Sh NAME
@@ -465,6 +465,16 @@ input to the
 format conforming to
 .Lk http://daringfireball.net/projects/markdown/syntax.text\
  "John Gruber's 2004 specification" .
+The output also almost conforms to the
+.Lk http://commonmark.org/ CommonMark
+specification.
+.Pp
+The character set used for the markdown output is ASCII.
+Non-ASCII characters are encoded as HTML entities.
+Since that is not possible in literal font contexts, because these
+are rendered as code spans and code blocks in the markdown output,
+non-ASCII characters are transliterated to ASCII approximations in
+these contexts.
 .Pp
 Markdown is a very weak markup language, so all semantic markup is
 lost, and even part of the presentational markup may be lost.