groff
[Top][All Lists]
Advanced

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

Re: [Groff] man problem: Latin1 characters in nion-Latin1 locale


From: Tomohiro KUBOTA
Subject: Re: [Groff] man problem: Latin1 characters in nion-Latin1 locale
Date: Tue, 21 Nov 2000 21:49:08 +0900
User-agent: Wanderlust/1.1.1 (Purple Rain) EMY/1.13.8 (Tastes differ) FLIM/1.13.2 (Kasanui) APEL/10.2 Emacs/20.7 (i386-debian-linux-gnu) MULE/4.1 (AOI)

Hi,

At Tue, 21 Nov 2000 11:31:31 +0000,
Stewart C. Russell <address@hidden> wrote:

> > I cannot understand your point.
> 
> yes, it was less than eloquent.
> 
> One of the most important things about markup formatters is that, given
> the same input to the same version of the software, they should (/must?)
> generate the same output in all installations, regardless of locale or
> operating system. 

I see.  I think the point is the meaning of the word 'same' in 
the phrases of 'same input' and 'same output'.  IMO, the sameness
should be on _characters_ (for input file and tty output), rather
than on _byte values_.  Since the current locale defines the meaning
(i.e., which character) of the byte values in text files, the same
byte value may mean different character in different locale.  I think
the 'sameness' of  character is important than the sameness of byte
value.

Thus, locale-sensible encoding conversion _changes_ the _byte value_ 
in order to assure the sameness of _character_.

# Please forget about glyph now;  I limit the topic in input source
# and tty output -- they are expressed in _character_ codes, not in
# _glyph_ codes.  Or, in tty output, glyphs have to be expressed in
# character codes.


For non-Latin-1 people, this is rather a living problem for users,
than an discussion on idealism.  Japanese Linux/Unix users have to
buy books on how to display, input, and print Japanese texts without
breaking them.  We have to know which software can use Japanese.
Though we have taken such a situation for granted since Linux is a
difficult system, I want to stop such a crazy situation.


> Otherwise, we have to send formatted output rather
> than source text.

I cannot understand this.


> TeX, for example, has an elaborate test suite, and unless software
> passes this, it can't be called TeX.

I don't know much on TeX.  Anyway, we use Japanese version of TeX.
It change the input encoding (EUC-JP and Shift-JIS, both of them
are popular encodings in Japan) in compile time.  Thus, if we think
about input byte stream and output dvi file, it is obvious that
EUC-JP version and Shift-JIS version give different output from
the same text with same _byte values_.  (Of course these two
versions give the same output from the same texts with same 
_characters_.)

Japanese version of TeX is very popular in Japan.

# Though I know there are projects such as Omega, I don't have time
# to try it.

---
Tomohiro KUBOTA <address@hidden>
http://surfchem0.riken.go.jp/~kubota/

reply via email to

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