discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Kristaps Dzonsons <kristaps@bsd.lv>
To: discuss@mdocml.bsd.lv
Cc: Stefan Sperling <stsp@openbsd.org>, Hiroki Sato <hrs@allbsd.org>
Subject: Full mandoc locale support committed.
Date: Wed, 18 May 2011 01:07:28 +0200	[thread overview]
Message-ID: <4DD2FFB0.2070303@bsd.lv> (raw)

[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]

Hi,

With this last commit, initial [full] locale support has been fitted 
into mandoc!  Attached is eye-candy: a manual full of random Unicode 
input (\[uNNNN]) first with -Tascii, then with -Tlocale.

 From the manual:

    Locale Output
      Locale-depending output encoding is triggered with -Tlocale.
      This option is not available on all systems: systems without
      locale support, or those whose internal representation is not
      natively UCS-4, will fall back to -Tascii.  See ASCII Output
      for font style specification and available command-line
      arguments.

The check-ins:

   (1) http://mdocml.bsd.lv/archives/source/0920.html
   (2) http://mdocml.bsd.lv/archives/source/0919.html

This support is /very/ fast, and any overhead occurs if and only if 
-Tlocale is selected AND supported.  If this doesn't hold, then mandoc 
runs at -Tascii "native" speed.

The bad news: it comes at a price.  -Tlocale only works if Unicode 
code-point values (defined in the UCS-4 (-2?) standards) can be 
transformed directly into wide-character values usable by the system.  I 
check this with an optional C99 feature, __STDC_ISO_10646__.  See

  http://www.cl.cam.ac.uk/~mgk25/ucs/iso2022-wc.html

for details.  Unfortunately, this seems only to be exported on glibc. 
I'm told the conditions hold on OpenBSD and FreeBSD.  NetBSD?

If your system abides by these rules and doesn't export this symbol, 
please let me know and we can special-case the macro test for this 
feature.  There is a way to convert from Unicode to a system's 
wide-character support without this feature, but it isn't pretty.  I'll 
probably have to implement this anyway for portability.  For now, if a 
system doesn't do __STDC_ISO_10646__, -Tlocale is a synonym for -Tascii.

Note that if this method is unilaterally hated, it's easy to switch to 
another method.  This was simply the fastest, simplest, and most 
transparent to implement.  All of the logic either way is in one file, 
and easy to manipulate:

  http://mdocml.bsd.lv/cgi-bin/cvsweb/term_ascii.c?cvsroot=mdocml

Thoughts?

Kristaps

[-- Attachment #2: screen.png --]
[-- Type: image/png, Size: 34932 bytes --]

             reply	other threads:[~2011-05-17 23:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 23:07 Kristaps Dzonsons [this message]
2011-05-18  6:21 ` Yuri Pankov
2011-05-18  9:53   ` Kristaps Dzonsons
2011-05-19 20:28 ` Ulrich Spörlein
2011-05-19 22:49   ` Kristaps Dzonsons
2011-05-20  7:26     ` Ulrich Spörlein
2011-05-20  7:59       ` Yuri Pankov
2011-05-20 15:52   ` 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=4DD2FFB0.2070303@bsd.lv \
    --to=kristaps@bsd.lv \
    --cc=discuss@mdocml.bsd.lv \
    --cc=hrs@allbsd.org \
    --cc=stsp@openbsd.org \
    /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).