groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Groff] Re: What's missing for Unicode support of groff?


From: Michail Vidiassov
Subject: [Groff] Re: What's missing for Unicode support of groff?
Date: Fri, 9 Dec 2005 18:41:27 +0300 (MSK)

Dear Werner,

In short - I proposed
a simple hack to accept UTF8 input encoding,
 triggered by -mutf8 on the commanf line,
a quick and dirty solution.

gpreconv is just a digest of this thread (and "man pages encoding" one),
translated from English to C. It suggest how to do it properly.

Let us live with a hack, while waiting for Groff 2.0
(as TeX community is waiting for Latex 3, Omega, Lambda,
Shia are waiting for their hidden imamms, Christians... oh, stop,
this list is not a proper place for atheistic propaganda ;)

Details follow:

On Thu, 8 Dec 2005, Werner LEMBERG wrote:


PS. Have you started to work on real Unicode input?

No.  [...]

But, as a workaround, why not to integrate into groff code from
uni2groff and activate it on an option -mutf8 (like -mlatin1,
-mlatin2, etc)?

This is a good idea!  We can use Tomohiro Kubota's gpreconv.c
(attached) which should be changed so that for the moment it doesn't
emit real UTF8 but \[uXXXX].  I've never run this code, but it looks
fine as a first start.

Integrating gpreconv in the way you talk about is a step towards 2.0 (review the messages of Bruno Haible in this thread), while code from uni2groff.c hidden behind -mutf8 is just a small step towards 1.19.3 ;)

The gpreconv approach is quite opposite to what I proposed.
gpreconv is written along the lines of the discussion in this tread
of the PROPER internationalization of groff.
Nobody has come up with a reason good enough for you to start
coding and all us get ready for lots of testing.

My idea is quite the opposite.
Let us make minimal changes.
We now have latin? and koi? (cyrillic) support via
files full of trin's.
I propose a HACK - in case of -m UTF8 call internal
conversion function, not instructions from some external UTF8.tmac file.
In this way we will follow the current groff interface for dealing with encodings, without breaking anything (for example CJK support patches
and workarounds).
BTW, uni2groff.c does not depend on iconv.

My guess is that nobody REALLY wants more.

        Sincerely, Michail





reply via email to

[Prev in Thread] Current Thread [Next in Thread]