--- On Sat, 3/12/11, Werner LEMBERG <[email protected]> wrote:
> > Here it is (test.tex) - I looked back at my paragraph
> and realised
> > there might be a misunderstanding - I was curious why
> The
> > \usepackage{CJK} choked on the french diacritcs, even
> though it is
> > outside of any \begin{CJK}\end{CJK} block. Perhaps the
> sample should
> > make it clear (it compiles with CJKutf8 but choked on
> CJK).
>
> Say
>
> \usepackage[encapsulated]{CJK}
>
> This is documented behaviour, see CJK.txt.
Argh, I thought I was familiar with CJK enough :-).
> > What exactly is it supposed to do? emacs 23
> seems to do thai (at
> > least displaying it) alright on its own, although I
> don't know thai
> > at all.
>
> cjk-enc.el's main job is to insert zero-width space breaks
> at Thai
> word boundaries. It's essentially the same as the
> `cttex' word
> separator program converted to elisp.
>
> > Ironically I got cjk/examples/thai.tex to work against
> thailatex
> > (and got AFAIK most bundled thailatex samples
> working), by edit just
> > babel line.
>
> Yes, it's very similar. But for thailatex you must
> run the
> preprocessor manually, or you get overlong lines.
>
> > Here are the results - for some very strange and
> unknown reasons,
> > thailatex does this (it is in the attached log):
> >
> > LaTeX Font Warning: Font shape
> `LTH/cmr/m/n' undefined
> > (Font)
> using `LTH/norasi/m/n' instead on input
> line 22.
> >
> > But uses norasi anyway,
>
> This is normal: The Babel language file `thai.ldf'
> activates LTH
> encoding by default but doesn't switch to the `norasi'
> family, and
> there is no such command in `thai.tex' which does that
> either.
>
> > whereas CJK does this:
> >
> > Missing character: There is no
> <undisplayablechar> in font cmr12!
>
> Again, this is correct behaviour: Running the CJK package
> directly on
> a Thai file doesn't work. It must be preprocessed
> with cjk-enc.el
> which inserts proper font switching commands, including the
> encoding.
>
> LaTeX's font fallback mechanism finds a different font
> family for a
> given encoding, but it can't guess the text's encoding.
Would/should mandating \usepackage[encoding]{inputenc} do? XeTeX actually
complains about such use (its defaults/suports only utf8 and therefore
complains about any other declarations which suggests otherwise).
Actually my recent renewed interests is with Sweave (a report generating system
of R, statistical computing environment), which mandates
\usepackage[something]{inputenc} . I think it is a bad idea (the whole file
must be of one encoding?) and it doesn't work with XeTeX, and describing
encoding of the content somewhat late within its content. In a way the emacs
way is worse - a comment block at the end :-).
> > I had tried plain latex instead of pdflatex as well,
> and the
> > intemediate dvi file references CMR rather than norasi
> - and I don't
> > know why CJK thai somehow keep trying CMR despite not
> having any cmr
> > references anywhere in the input files.
>
> Apparently, you've missed the comment in the beginning of
> thai.tex:
>
> % This file should be processed with cjk-enc.el to
> get
> %
> % . proper word breaks
> % . font switching between Thai and
> non-Thai
> % . intercharacter glue
>
> :-)
Argh, I thought "should" is optional - what you are saying is that it 'must' be
processed with cjk-enc.el . Are you saying that it must be processed by
cjk-enc.el or it does not work? So It is more equivalent to what
bg5latex/bg5pdflatex does?
That puts a rather big limitation to CJK thai: ties it to emacs. Some might
prefer other editors; and also penalize windows (MikTeX) users who most
probably don't use emacs...
It sounds like most of my problems are due to not reading the documentation
carefully enough (or alternatively, important issues aren't emphasized enough
in the documentation...).
Hin-Tak
_______________________________________________
Cjk maillist - [email protected]
https://lists.ffii.org/mailman/listinfo/cjk
