> > This is not true. Encoding does *not* imply the character set.
> > You are talking about charset/encoding tags.
>
> Hmm, I cannot understand your idea...
>
> I intend to mean
> - character set: CCS (Coded Character Set) in RFC 2130
> - encoding: CES (Character Encoding Scheme) in RFC 2130
(B> > The same exists for Japanese and Chinese, especially for vertical
(B> > writing.
(B>
(B> I think *ideograms* have fixed width everywhere.
(B
(BWell, maybe. But sometimes there is kerning. Please consult Ken
(BLunde's `CJKV Information Processing' for details. Example:
(B
(B $
Hi,
At Fri, 20 Oct 2000 14:45:51 +0200 (CEST),
Werner LEMBERG <[EMAIL PROTECTED]> wrote:
> First of all: We both mean the same, and we agree how to handle the
> problem in groff. I'm only arguing about technical terms.
>
> Another try.
>
> Consider a PostScript font with its encoding vector.
Werner LEMBERG writes:
> The `-a' option is almost useless today IMHO. It will show a tty
> approximation of the typeset output:
>
> groff -a -man -Tdvi troff.man | less
>
> It is *not* the right way to quickly select an ASCII device. To
> override the used macros for the output character set
On 17-Oct-00 Werner LEMBERG wrote:
> Well, I insist that GNU troff doesn't support multi-byte encodings at
> all :-) troff itself should work on a glyph basis only. It has to
> work with *glyph names*, be it CJK entities or whatever. Currently,
> the conversion from input encoding to glyph entiti
5 matches
Mail list logo
