Georg Baum wrote:
Marc Flerackers wrote:
Abdelrazak Younes wrote:
Marc Flerackers wrote:
Another issue is that (as far as I know) you need to enclose cjk text
with \begin{CJK}{UTF8}{ipam} and \end{CJK} each time when writing
Japanese in an English document. More practically would be a setting
for a cjk font, and a cjk mode or even auto-recognition of cjk
characters.
This is what I plan to do.
Auto-recognition would be easy (and I think we should do the same for
RTL languages but that is another story).
We discussed that already (for RTL), and the conclusion was that we should
_not_ try to automatically recognize it.
Well, this is different here as we are talking about LateX export. For
RTL (in our implementation) we need to know the language for proper
character ordering when typing. In the CJK case, I reckon this is not
needed at all (correct me if I am wrong).
What I did so far was to define 4 new languages: Korean, Japanese, Chinese
traditional and Chinese simplified. Users would need to mark the text as
one of these in order to get the CJK environment.
Why? AFAIU screen appearance won't be affected by the current language.
Why not do that at LateX export?
The difficult thing is to get the encoding switches right, since we cannot
always use utf8 for the whole document. This is the part of the patch that
is not yet working.
I guess we just have to enclose any word (even single character?) with
the cited \begin{CJK}{UTF8}{ipam} and \end{CJK} when doing
Yes, but "ipam" replaced with the currently selected cjk font :). The
ipam font comes from IPA
(http://www-alg.ist.hokudai.ac.jp/~jan/japfonts.html).
What I plan is to ignore the font completely, and write something like
\begin{CJK}{UTF8}{} and \end{CJK}. The font can still be set globally, and
IMO it is enough work to get the language and encoding stuff working. The
fonts can be supported later (e.g. 1.6).
I agree. Finding and implement a UI for that would be difficult in the
1.5 time frame.
Abdel.
