groff
[Top][All Lists]
Advanced

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

Re: [Groff] Re: groff: radical re-implementation


From: Ted Harding
Subject: Re: [Groff] Re: groff: radical re-implementation
Date: Sat, 21 Oct 2000 15:39:24 +0100 (BST)

On 21-Oct-00 Tomohiro KUBOTA wrote:
> Hi,
> 
> At Fri, 20 Oct 2000 20:32:17 +0100 (BST),
> (Ted Harding) <address@hidden> wrote:
> 
>> B: Troff should be able to cope with multi-lingual documents, where
>> several different languages occur in the same document. I do NOT
>> believe that the right way to do this is to extend troff's capacity
>> to recognise thousands of different input encodings covering all the
>> languages which it might be called upon to typeset (e.g. by Unicode or
>> the like).
> 
> This is a confusion of language and encoding.  I think UTF-8 support
> can and should be achieved via locale technology.  By using locale
> technology, a software can be written in encoding-independent way.
> The software can support any encodings including UTF-8.  Why
> do we have to hard-code UTF-8, though we can use locale technology
> to support any encodings including UTF-8 ?

To bring the argument I am trying to present face-to-face with the
point you seem to be trying to make:

Someone writing a document about Middle Eastern and related literatures
may wish to use the Arabic, Persian, Hebrew, Turkish (all of which have
different scripts), and also various Central Asian languages (such as
Turkmen) which are often written in Cyrillic or in a variant of Cyrillic.

Can you explain how this could be handled "via locale technology"
in a single document?

Even in its present state, groff can handle such material in a
straightforward way (though with extra work from the user in order to
make the right-to-left languages work correctly -- the basic method would
be to get it formatted correctly with these languages input and printed as
left-to-right, and then edit the input file, using the formatted output
for reference, to reverse the input sequences on a line-by-line basis).

[One of the dangers which I fear if groff were re-structured on a
"locale" basis, or similar mechanism. is that its flexibility, indeed in
principle its universality, would be compromised and limited by the
constraints of that mechanism. It is perhaps not recognised widely
eough that groff, in its present state, is capable of being greatly
extended -- by means of user-defined macros, preprocessors, and
post-processors -- without fundamental change to troff.]

With best wishes,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 284 7749
Date: 21-Oct-00                                       Time: 15:39:24
------------------------------ XFMail ------------------------------

reply via email to

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