Georg Baum wrote:
"한창길" wrote:
Georg Baum wrote:
"한창길" wrote:
2. Many TeX macro style files for the CJK languages such as "cjk-latex",
use as input encoding option, "utf8x" instead of "utf8". So adding one
line in "lib/encodings"
" Encoding utf8x utf8x UTF-8
End"
and setting "Document -> Settings -> Language -> Encoding: utf8x", I
can
view the lyx file which contains multibyte characters (see
attached multi2.png).
How did you create this file? And how do you choose "cjk-latex"?
I just add "\usepackage{dhucs}" in the lyx preamble, where "dhucs.sty" is
local TeX macro package, and use "dvipdfmx" to view the file.
OK, this is clear to me.
To use
cjk-latex package, I add "\usepackage{CJK}" in the preamble and set the
environment as "\begin{CJK}{UTF8}{komj}
cjk-characters here
\end{CJK}".
Does that mean that cjk-lyx does not add a command to switch to a
cjk-environment itself, but you have to do it in ERT? Sorry for all these
dumb questions, but since I cannot read any of the C, J, K languages myself
I don't have any experience with this.
If not, what other possibilities exist?
There are some. For example, big5 for Chinese, and euc-jp for Japanese.
Is that the complete list, or are there others? We need to know all possible
encodings for lyx2lyx.
2) Does cjk-lyx set the encoding name with the \inputencoding comamdn
in .lyx files?
No, \inputencoding is set to "auto".
Then how does LyX know the encoding of the file?
I know, I could read all that in the cjk-patch, but it is big and contains
much technical stuff that is not of interest here, so it would be nice if
you could tell it.
Actually, most of the CJK patch is gettext translation and unicode
conversion. I guess we could have taken this patch as-is as starting
point for unicode :-). Maybe that's what Lars did, dunno.
Anyway, what is of interest to us here is the former change to
QContentPane (now GuiWorkArea) and LyXFunc.
In QContentPane, we have (I strimmed what is not important to us):
void QContentPane::keyPressEvent(QKeyEvent * e)
{
+ if (e->key()==0)
+ wa_->workAreaCJK_IMprocess(fromqstr(e->text()));
+ else
+ keyeventQueue_.push(boost::shared_ptr<QKeyEvent>(new
QKeyEvent(*e)));
}
'workAreaCJK_IMprocess()' is a boost signal indirectly connected to this
function:
+ void LyXFunc::CJK_IMprocess( std::string wstring)
+ {
+ LyXText * text = view()->getLyXText();
+ LCursor & cur = view()->cursor();
+ text->insertStringAsParagraphs(cur, wstring);
view()->update(Update::FitCursor|Update::Force|Update::SinglePar);
+ view()->update();
+
+ }
+#endif
Nowadays, we have this in keyPressEvent:
void GuiWorkArea::keyPressEvent(QKeyEvent * e)
{
boost::shared_ptr<QLyXKeySym> sym(new QLyXKeySym);
sym->set(e);
processKeySym(sym, q_key_state(e->modifiers()));
}
So the CJK patch was short cutting the QLyXKeySym machinery altogether
except if e->key() was different from 0. Correct me if I am wrong Cghan,
Abdel.
