Re: Beta schedule
- Original Message - From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-15 17:53:21 Subject: Re: Beta schedule 1. CJK-LyX file is the usual lyx file and thus is saved as .lyx (rather than .cjklyx) file. I know, but we need a different ending for technical reasons. We do the same for old LyX files (ending lyx14) But when I click Import - CJK LyX(euc-kr), I get only two types of files to choose, .cjklyx or *.*, which is clearly wrong, for there are no files with .cjklyx ending. 2. It leads to crash, with the following backtrace; Can you send an example file that leads to this crash? Any kind of cjk-lyx files. I attach one of them. 3. Japanese shift-jis also seems popular . More popular than euc_jp? I don't want to include all possible options, because that would create too many menu entries. We should rather explain in a Upgrade from CJK-LyX to 1.5 document how importing CJK-LyX files works and that it is easy to define custom converters and formats. Sounds reasonable. Regards, cghan test.lyx Description: application/lyx
Re: Beta schedule
- Original Message - From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-15 17:53:21 Subject: Re: Beta schedule I know, but we need a different ending for technical reasons. We do the same for old LyX files (ending lyx14) Now, I've got your point. That is, I have to change ending of the CJK-LyX file from .lyx to .cjklyx, and then import this .cjklyx file, right? Yup, it works with no crash!!! I hope some day you developers find better ways of importing files without changing ending. Anyhow, I thank you again for your work. Regards, cghan
Re: Beta schedule
- Original Message - From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-15 21:05:04 Subject: Re: Beta schedule You don't need to change the file ending at all. You can simply choose the file with the wrong ending and import it. Sorry, I don't get your point; What do you mean by simply choose the file with wrong ending ? All my CJK-LyX files have .lyx endings. cghan
Re: Beta schedule
- Original Message - From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-15 21:47:43 Subject: Re: Beta schedule Yes. And that ending is not cjklyx. You can import that file nevertheless if you select to show all files and then choose it. Then, lyx crashes as I reported moments ago. cghan
Re: Beta schedule
- Original Message - >> From: Georg Baum <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-15 17:53:21 >> Subject: Re: Beta schedule >> >> > 1. CJK-LyX file is the usual lyx file and thus is saved as ".lyx" >> > (rather than ".cjklyx") file. >> >> I know, but we need a different ending for technical reasons. We do the same >> for old LyX files (ending lyx14) But when I click "Import -> CJK LyX(euc-kr)", I get only two types of files to choose, ".cjklyx" or "*.*", which is clearly wrong, for there are no files with ".cjklyx" ending. >> > 2. It leads to crash, with the following >> > backtrace; >> >> Can you send an example file that leads to this crash? >> Any kind of cjk-lyx files. I attach one of them. >> > 3. Japanese "shift-jis" also seems popular . >> >> More popular than euc_jp? I don't want to include all possible options, >> because that would create too many menu entries. We should rather explain >> in a "Upgrade from CJK-LyX to 1.5" document how importing CJK-LyX files >> works and that it is easy to define custom converters and formats. >> Sounds reasonable. Regards, cghan test.lyx Description: application/lyx
Re: Beta schedule
- Original Message - >> From: Georg Baum <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-15 17:53:21 >> Subject: Re: Beta schedule >> >> I know, but we need a different ending for technical reasons. We do the same >> for old LyX files (ending lyx14) >> Now, I've got your point. That is, I have to change ending of the CJK-LyX file from .lyx to .cjklyx, and then import this .cjklyx file, right? Yup, it works with no crash!!! I hope some day you developers find better ways of importing files without changing "ending". Anyhow, I thank you again for your work. Regards, cghan
Re: Beta schedule
- Original Message - >> From: Georg Baum <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-15 21:05:04 >> Subject: Re: Beta schedule >> >> You don't need to change the file ending at all. You can simply choose the >> file with the "wrong" ending and import it. Sorry, I don't get your point; What do you mean by "simply choose the file with "wrong" ending" ? All my CJK-LyX files have ".lyx" endings. cghan
Re: Beta schedule
- Original Message - >> From: Georg Baum <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-15 21:47:43 >> Subject: Re: Beta schedule >> >> Yes. And that ending is not "cjklyx". You can import that file nevertheless >> if you select to show all files and then choose it. Then, lyx crashes as I reported moments ago. cghan
Re: Beta schedule
Hello,
- Original Message -
From: Georg Baum [EMAIL PROTECTED]
To: lyx-devel@lists.lyx.org
Date: 2007-02-14 01:42:31
Subject: Re: Beta schedule
lyx2lyx -c eux-kr cjk-lyx_file lyx-svn_file correctly translates CJK
characters in cjk-lyx_file.
OK, then I will put it in (with a better help text).
Thank you.
It is not essential, but it would be extremely convenient if with the use
of this lyx2lyx we could just open the cjk-lyx file from the lyx-svn.
How could that work? The problem is twofold:
a) We cannot detect if a file is from cjk-lyx (or can we detect that from
the first line as Jean-Marc suggested?
You are right in that cjk-lyx file is no different from the lyx file.
b) Even if a) would be solved, we don't know the encoding of the file.
Therefore we need a manual switch. Of course we could put that switch in
the GUI, butthen the question is: When to ask for the encoding? If we
would do this for all files, we would annoy users who don't use cjk-LyX.
Then how about using Import menu button, such as Import - CJK-LyX-1.4.x -
{Korean(euc-kr), Chinese(big5),...} ?. I hope I am not asking too
much!
By some unknown reasons (to me), nearly all the local TeX macro
packages(including cjk-latex) use utf8x instead of utf8 for input
encoding.
OK, I will add it.
Another thank you!!
Regards,
cghan
Re: Beta schedule
- Original Message -
From: Jos#65533;_Matos [EMAIL PROTECTED]
To: lyx-devel@lists.lyx.org
Date: 2007-02-14 18:39:15
Subject: Re: Beta schedule
Then how about using Import menu button, such as Import - CJK-LyX-1.4.x
- {Korean(euc-kr), Chinese(big5),...} ?. I hope I am not asking too
much!
I am curious, can't we use file to discover the file encoding?
What does file says about your files?
file cjk-lyx file results in cjk-lyx file: ISO-8859 text
Regards,
cghan
Re: Beta schedule
- Original Message - From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-15 04:49:28 Subject: Re: Beta schedule It would look like the attached patch. I chose one encoding for each of chinese, japanese and korean. Did I chose the most commonly used ones? Is this OK to go in? Thank you for your effort, but your patch has several problems; 1. CJK-LyX file is the usual lyx file and thus is saved as .lyx (rather than .cjklyx) file. 2. It leads to crash, with the following backtrace; Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209100608 (LWP 18622)] boost::scoped_ptrlyx::Buffer::Impl::operator- (this=0x100) at ../boost/boost/scoped_ptr.hpp:94 94 BOOST_ASSERT(ptr != 0); (gdb) bt #0 boost::scoped_ptrlyx::Buffer::Impl::operator- (this=0x100) at ../boost/boost/scoped_ptr.hpp:94 #1 0x081946e8 in lyx::Buffer::temppath (this=0x0) at buffer.C:315 #2 0x08274d90 in lyx::Converters::convert (this=0x943df78, buffer=0x0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], conversionflags=0) at converter.C:379 #3 0x0832291d in lyx::Importer::Import (lv=0x948337c, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at importer.C:60 #4 0x083bef1e in lyx::LyXFunc::doImport (this=0x943dec8, [EMAIL PROTECTED]) at lyxfunc.C:2039 #5 0x083c16f9 in lyx::LyXFunc::dispatch (this=0x943dec8, [EMAIL PROTECTED]) at lyxfunc.C:1087 #6 0x08380f48 in lyx::dispatch ([EMAIL PROTECTED]) at lyx_main.C:1461 #7 0x08768cce in lyx::LyXView::dispatch (this=0x948337c, [EMAIL PROTECTED]) at LyXView.C:427 #8 0x0893c078 in lyx::frontend::Action::action (this=0x9697048) at Action.C:94 #9 0x0893c10a in lyx::frontend::Action::qt_metacall (this=0x9697048, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfa0bdfc) at Action_moc.cpp:64 #10 0x001f9a11 in QMetaObject::activate () at /usr/lib/gcc/i386-Haansoft-linux/4.0.2/../../../../include/c++/4.0.2/debug/formatter.h:313 3. Japanese shift-jis also seems popular . Regards, cghan
Re: Beta schedule
Hello,
- Original Message -
>> From: Georg Baum <[EMAIL PROTECTED]>
>> To: lyx-devel@lists.lyx.org
>> Date: 2007-02-14 01:42:31
>> Subject: Re: Beta schedule
>>
>> > "lyx2lyx -c eux-kr cjk-lyx_file > lyx-svn_file" correctly translates CJK
>> characters in cjk-lyx_file.
>>
>> OK, then I will put it in (with a better help text).
Thank you.
>> > It is not essential, but it would be extremely convenient if with the use
>> of this lyx2lyx we could just "open" the cjk-lyx file from the lyx-svn.
>>
>> How could that work? The problem is twofold:
>>
>> a) We cannot detect if a file is from cjk-lyx (or can we detect that from
>> the first line as Jean-Marc suggested?
You are right in that cjk-lyx file is no different from the lyx file.
>> b) Even if a) would be solved, we don't know the encoding of the file.
>> Therefore we need a manual switch. Of course we could put that switch in
>> the GUI, butthen the question is: When to ask for the encoding? If we
>> would do this for all files, we would annoy users who don't use cjk-LyX.
Then how about using Import menu button, such as "Import -> CJK-LyX-1.4.x ->
{Korean(euc-kr), Chinese(big5),...}" ?. I hope I am not asking too
much!
>> > By some unknown reasons (to me), nearly all the local TeX macro
>> packages(including cjk-latex) use "utf8x" instead of "utf8" for input
>> encoding.
>>
>> OK, I will add it.
>>
Another thank you!!
Regards,
cghan
Re: Beta schedule
- Original Message -
>> From: Jos_Matos <[EMAIL PROTECTED]>
>> To: lyx-devel@lists.lyx.org
>> Date: 2007-02-14 18:39:15
>> Subject: Re: Beta schedule
>>
>> > Then how about using Import menu button, such as "Import -> CJK-LyX-1.4.x
>> > -> {Korean(euc-kr), Chinese(big5),...}" ?. I hope I am not asking too
>> > much!
>>
>> I am curious, can't we use file to discover the file encoding?
>>
>> What does file says about your files?
"file cjk-lyx file" results in "cjk-lyx file: ISO-8859 text"
Regards,
cghan
Re: Beta schedule
- Original Message - >> From: Georg Baum <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-15 04:49:28 >> Subject: Re: Beta schedule >> >> >> It would look like the attached patch. I chose one encoding for each of >> chinese, japanese and korean. Did I chose the most commonly used ones? Is >> this OK to go in? >> Thank you for your effort, but your patch has several problems; 1. CJK-LyX file is the usual lyx file and thus is saved as ".lyx" (rather than ".cjklyx") file. 2. It leads to crash, with the following backtrace; "Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1209100608 (LWP 18622)] boost::scoped_ptr::operator-> (this=0x100) at ../boost/boost/scoped_ptr.hpp:94 94 BOOST_ASSERT(ptr != 0); (gdb) bt #0 boost::scoped_ptr::operator-> (this=0x100) at ../boost/boost/scoped_ptr.hpp:94 #1 0x081946e8 in lyx::Buffer::temppath (this=0x0) at buffer.C:315 #2 0x08274d90 in lyx::Converters::convert (this=0x943df78, buffer=0x0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], conversionflags=0) at converter.C:379 #3 0x0832291d in lyx::Importer::Import (lv=0x948337c, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at importer.C:60 #4 0x083bef1e in lyx::LyXFunc::doImport (this=0x943dec8, [EMAIL PROTECTED]) at lyxfunc.C:2039 #5 0x083c16f9 in lyx::LyXFunc::dispatch (this=0x943dec8, [EMAIL PROTECTED]) at lyxfunc.C:1087 #6 0x08380f48 in lyx::dispatch ([EMAIL PROTECTED]) at lyx_main.C:1461 #7 0x08768cce in lyx::LyXView::dispatch (this=0x948337c, [EMAIL PROTECTED]) at LyXView.C:427 #8 0x0893c078 in lyx::frontend::Action::action (this=0x9697048) at Action.C:94 #9 0x0893c10a in lyx::frontend::Action::qt_metacall (this=0x9697048, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfa0bdfc) at Action_moc.cpp:64 #10 0x001f9a11 in QMetaObject::activate () at /usr/lib/gcc/i386-Haansoft-linux/4.0.2/../../../../include/c++/4.0.2/debug/formatter.h:313 " 3. Japanese "shift-jis" also seems popular . Regards, cghan
Re: Beta schedule
- Original Message - From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-13 19:30:25 Subject: Re: Beta schedule The only thing I can think of is the lyx2lyx patch for CJK from Georg. Does the latest version work? Sorry for my late reply. Yes, your latest patch works well. With your patch, lyx2lyx -c eux-kr cjk-lyx_file lyx-svn_file correctly translates CJK characters in cjk-lyx_file. It is not essential, but it would be extremely convenient if with the use of this lyx2lyx we could just open the cjk-lyx file from the lyx-svn. Also the support of utf8x in the lib/encodings and in the tex2lyx? Not in tex2lyx. tex2lyx will not support encodings other than the pseudo support for latin1 that we have at the moment, because Jose wants to rewrite it in python and I don't want to waste my (scarce) time. Before putting the utf8x encoding in lib/encodings could you please tell me why it is needed? My current understanding is that utf8x is old and superseeded by utf8. By some unknown reasons (to me), nearly all the local TeX macro packages(including cjk-latex) use utf8x instead of utf8 for input encoding. Regards, cghan
Re: Beta schedule
Hello, - Original Message - From: Abdelrazak Younes [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-13 18:36:55 Subject: Re: Beta schedule ChangGil Han wrote: - Original Message - From: Abdelrazak Younes [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-13 01:20:02 Subject: Re: Beta schedule Also the support of utf8x in the lib/encodings and in the tex2lyx? And the gettext translations... Could you please update this to the last 1.5 and send a patch Han? (or is your surname ChangGil?). I'll try to find the time to update the ko.po in the next few weeks. Yes, my name is ChangGil, but cghan is more convenient, isn't it? Regards, cghan
Re: Beta schedule
- Original Message - >> From: Georg Baum <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-13 19:30:25 >> Subject: Re: Beta schedule >> >> >>> The only thing I can think of is the lyx2lyx patch for CJK from Georg. >> >> Does the latest version work? Sorry for my late reply. Yes, your latest patch works well. With your patch, "lyx2lyx -c eux-kr cjk-lyx_file > lyx-svn_file" correctly translates CJK characters in cjk-lyx_file. It is not essential, but it would be extremely convenient if with the use of this lyx2lyx we could just "open" the cjk-lyx file from the lyx-svn. >> > Also the support of "utf8x" in the lib/encodings and in the tex2lyx? >> >> Not in tex2lyx. tex2lyx will not support encodings other than the pseudo >> support for latin1 that we have at the moment, because Jose wants to >> rewrite it in python and I don't want to waste my (scarce) time. >> >> Before putting the utf8x encoding in lib/encodings could you please tell me >> why it is needed? My current understanding is that utf8x is old and >> superseeded by utf8. By some unknown reasons (to me), nearly all the local TeX macro packages(including cjk-latex) use "utf8x" instead of "utf8" for input encoding. Regards, cghan
Re: Beta schedule
Hello, - Original Message - >> From: Abdelrazak Younes <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-13 18:36:55 >> Subject: Re: Beta schedule >> >> >> ChangGil Han wrote: >> > >> > - Original Message - >> >>> From: Abdelrazak Younes <[EMAIL PROTECTED]> >> >>> To: lyx-devel@lists.lyx.org >> >>> Date: 2007-02-13 01:20:02 >> >>> Subject: Re: Beta schedule >> > >> > Also the support of "utf8x" in the lib/encodings and in the tex2lyx? >> >> And the gettext translations... Could you please update this to the last >> 1.5 and send a patch Han? (or is your surname ChangGil?). I'll try to find the time to update the ko.po in the next few weeks. Yes, my name is ChangGil, but cghan is more convenient, isn't it? Regards, cghan
Re: Beta schedule
- Original Message - From: Abdelrazak Younes [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-13 01:20:02 Subject: Re: Beta schedule The only thing I can think of is the lyx2lyx patch for CJK from Georg. Also the support of utf8x in the lib/encodings and in the tex2lyx? cghan
Re: Beta schedule
- Original Message - >> From: Abdelrazak Younes <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-13 01:20:02 >> Subject: Re: Beta schedule >> >> The only thing I can think of is the lyx2lyx patch for CJK from Georg. >> Also the support of "utf8x" in the lib/encodings and in the tex2lyx? cghan
Re: A status report on the current lyx-1 .5.0svn support of CJK languages
Georg Baum wrote: I agree, but I was asking how it is done in cjk-lyx. My plan is 1) understand how cjk-lyx stores .lyx documents 2) understand how cjk-lyx exports cjk to latex 3) implement lyx2lyx support to read cjk-lyx files 4) implement support for proper latex export of cjk cjk-lyx stores both .lyx and .latex files in the encoding of the locale (since wcstombs and mbstowcs are used for conversion). All necessary latex packages have to be loaded manually, and all necessary latex commands for cjk have to be entered in ERT. Is this correct? Yes, you are right. So the task to be done is to make lyx2lyx translate .lyx file with CJK characters encoded in the locale set such as euc-kr ro euc-jp, into the .lyx file readable by the current lyx-svn, isn't it? Regards, cghan
Re: A status report on the current lyx-1 .5.0svn support of CJK languages
Abdelrazak Younes wrote: OK, then Georg is right about generating as many keypressEvent as there are characters in the inputMethodEvent. Please apply this patch and try again. Your patch works here both in linux and in windows box!!! Regards, cghan
Re: A status report on the current lyx-1 .5.0svn support of CJK languages
- Original Message - From: Abdelrazak Younes [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-11 01:32:00 Subject: Re: A status report on the current lyx-1.5.0svn support of CJK languages OK, thanks for testing. It's committed but I think there's still some work to do to support CJK correctly (see FIXMEs) and I count on you to help us there ;-) Abdel. With your fix, I can now input CJK characters flawlessly. If some flaws come up later(but unlikely), I'll report to you. Many thanks. cghan
Re: A status report on the current lyx-1 .5.0svn support of CJKlanguages
Hello, - Original Message - From: Georg Baum [EMAIL PROTECTED] To: lyx-devel@lists.lyx.org Date: 2007-02-10 23:03:49 Subject: Re: A status report on the current lyx-1.5.0svn support of CJKlanguages Yes. This patch attempts to do that. If you call lyx2lyx with the -c (or --cjk-lyx) argument, it will read and write files in format 248 or less with the locale encoding. That means that lyx2lyx should be able to translate from CJK-LyX to current format and vice versa. Can you please test? I can't because I don't have the right locales here. We need the command line switch since it is not possible to tell from the file itself that it was written by CJK-LyX. Georg With your patch, lyx2lyx now translate correctly euc-kr encoded file to the format for the current lyx-svn, but only in cjk environment--here in ko_KR.eucKR. Can you make this can also work in the locale set in UTF-8? Nowadays, our working environment is set here to ko_KR.UTF-8. For your reference, when I try to translate with lyx2lyx in UTF-8 environment, I get the following error messages; Traceback (most recent call last): File ./lyx2lyx, line 95, in ? sys.exit(main(sys.argv)) File ./lyx2lyx, line 86, in main file = LyX.File(end_format, input, output, error, debug, try_hard, cjk_lyx) File /home/lyx-devel/lib/lyx2lyx/LyX.py, line 544, in __init__ self.read() File /home/lyx-devel/lib/lyx2lyx/LyX.py, line 247, in read line = self.input.readline().decode(self.encoding) File /usr/lib/python2.4/encodings/utf_8.py, line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-2: invalid data. Regards, cghan
Re: A status report on the current lyx-1 .5.0svn support of CJK languages
Georg Baum wrote: > I agree, but I was asking how it is done in cjk-lyx. My plan is > > 1) understand how cjk-lyx stores .lyx documents > 2) understand how cjk-lyx exports cjk to latex > 3) implement lyx2lyx support to read cjk-lyx files > 4) implement support for proper latex export of cjk > > cjk-lyx stores both .lyx and .latex files in the encoding of the locale > (since wcstombs and mbstowcs are used for conversion). All necessary latex > packages have to be loaded manually, and all necessary latex commands for > cjk have to be entered in ERT. > > Is this correct? Yes, you are right. So the task to be done is to make lyx2lyx translate .lyx file with CJK characters encoded in the locale set such as euc-kr ro euc-jp, into the .lyx file readable by the current lyx-svn, isn't it? Regards, cghan
Re: A status report on the current lyx-1 .5.0svn support of CJK languages
Abdelrazak Younes wrote: > OK, then Georg is right about generating as many keypressEvent as there > are characters in the inputMethodEvent. Please apply this patch and try > again. Your patch works here both in linux and in windows box!!! Regards, cghan
Re: A status report on the current lyx-1 .5.0svn support of CJK languages
- Original Message - >> From: Abdelrazak Younes <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-11 01:32:00 >> Subject: Re: A status report on the current lyx-1.5.0svn support of CJK >> languages >> >> >> OK, thanks for testing. It's committed but I think there's still some >> work to do to support CJK correctly (see FIXMEs) and I count on you to >> help us there ;-) >> >> Abdel. >> With your fix, I can now input CJK characters flawlessly. If some flaws come up later(but unlikely), I'll report to you. Many thanks. cghan
Re: A status report on the current lyx-1 .5.0svn support of CJKlanguages
Hello, - Original Message - >> From: Georg Baum <[EMAIL PROTECTED]> >> To: lyx-devel@lists.lyx.org >> Date: 2007-02-10 23:03:49 >> Subject: Re: A status report on the current lyx-1.5.0svn support of >> CJKlanguages >> >> >> Yes. This patch attempts to do that. >> If you call lyx2lyx with the -c (or --cjk-lyx) argument, it will read and >> write files in format 248 or less with the locale encoding. That means >> that lyx2lyx should be able to translate from CJK-LyX to current format >> and vice versa. Can you please test? I can't because I don't have the >> right locales here. >> >> We need the command line switch since it is not possible to tell from the >> file itself that it was written by CJK-LyX. >> >> >> Georg >> >> With your patch, lyx2lyx now translate correctly euc-kr encoded file to the format for the current lyx-svn, but only in cjk environment--here in "ko_KR.eucKR". Can you make this can also work in the locale set in UTF-8? Nowadays, our working environment is set here to "ko_KR.UTF-8". For your reference, when I try to translate with lyx2lyx in UTF-8 environment, I get the following error messages; "Traceback (most recent call last): File "./lyx2lyx", line 95, in ? sys.exit(main(sys.argv)) File "./lyx2lyx", line 86, in main file = LyX.File(end_format, input, output, error, debug, try_hard, cjk_lyx) File "/home/lyx-devel/lib/lyx2lyx/LyX.py", line 544, in __init__ self.read() File "/home/lyx-devel/lib/lyx2lyx/LyX.py", line 247, in read line = self.input.readline().decode(self.encoding) File "/usr/lib/python2.4/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-2: invalid data. " Regards, cghan
CJK-LyX-1.1.5fix2
Hello, CJK-LyX-1.1.5fix2 has been uploaded to the usual place, ftp://stone.phys.pusan.ac.kr/pub/CJK-LyX Sorry that it comes out a month late. Further infos are found at http://cellular.phys.pusan.ac.kr/cjk.html Regards, cghan
CJK-LyX-1.1.5fix2
Hello, CJK-LyX-1.1.5fix2 has been uploaded to the usual place, ftp://stone.phys.pusan.ac.kr/pub/CJK-LyX Sorry that it comes out a month late. Further infos are found at http://cellular.phys.pusan.ac.kr/cjk.html Regards, cghan
Re: Asian languages support?
On Feb 14, 12:17pm, Amir Karger wrote: LyXers - is the LyX web site outdated with regard to Asian language support? Does it describe support correctly for 1.0 and 1.1? Does it have the patches and links including the recent one that superseded the old one? If not, could you post a quick summary to the list? Then I (or someone less lazy than me) can check in a fix to the website. -Amir -- End of excerpt from Amir Karger I have posted, twice in the last two weeks, patches for the multibyte version of lyx cvs-source, or more precisely, for the lyx-users of Chinese, Japanese and Korean languages. They have not appeared on the lyx-devel mail-archive and nobody has yet given any comments about them. Attached is my third trial, which I have uploaded, too, ( in case the attached file is broken), on ftp://stone.phys.pusan.ac.kr/pub/CJK-LyX. The filename is "lyx-devel-2.8-cjk.patch.gz". The patch is against the cvs-source of Feb.8th ( I have not updated the source yet). Please ignore previous patches if anybody has them. They contain some minor bugs compared to this one. You can also get the source-patch and the rpm binary(redhat6.1) of the recent stable release of lyx-1.1.4 on the same directory above. As to the Website, I think the Chinese ones are fairly outdated and although the Japanese site is outdated too, some of informations on the site seem to be still useful for the Japanese Lyx users (for eample, informations about local tex, fonts, etc). I have not finished yet, but I am trying to build the home page of "CJK-LyX"- a temporary name for the multibyte version of lyx until the patch becomes mature enough to be included in the main branch of the cvs source. The site will have informations regarding CJK-LyX and since I am a Korean and do not know much about Japanese and Chinese, much of the informations in the site will be for Korean users. regards, ChangGil Han. -- ChangGil Han Data
Re: Asian languages support?
On Feb 14, 12:17pm, Amir Karger wrote: > > LyXers - is the LyX web site outdated with regard to Asian language support? > Does it describe support correctly for 1.0 and 1.1? Does it have the patches > and links including the recent one that superseded the old one? If not, > could you post a quick summary to the list? Then I (or someone less lazy > than me) can check in a fix to the website. > > -Amir >-- End of excerpt from Amir Karger I have posted, twice in the last two weeks, patches for the multibyte version of lyx cvs-source, or more precisely, for the lyx-users of Chinese, Japanese and Korean languages. They have not appeared on the lyx-devel mail-archive and nobody has yet given any comments about them. Attached is my third trial, which I have uploaded, too, ( in case the attached file is broken), on ftp://stone.phys.pusan.ac.kr/pub/CJK-LyX. The filename is "lyx-devel-2.8-cjk.patch.gz". The patch is against the cvs-source of Feb.8th ( I have not updated the source yet). Please ignore previous patches if anybody has them. They contain some minor bugs compared to this one. You can also get the source-patch and the rpm binary(redhat6.1) of the recent stable release of lyx-1.1.4 on the same directory above. As to the Website, I think the Chinese ones are fairly outdated and although the Japanese site is outdated too, some of informations on the site seem to be still useful for the Japanese Lyx users (for eample, informations about local tex, fonts, etc). I have not finished yet, but I am trying to build the home page of "CJK-LyX"- a temporary name for the multibyte version of lyx until the patch becomes mature enough to be included in the main branch of the cvs source. The site will have informations regarding CJK-LyX and since I am a Korean and do not know much about Japanese and Chinese, much of the informations in the site will be for Korean users. regards, ChangGil Han. -- ChangGil Han Data
Re: multibyte support for lyx
Sure, you can.
Re: multibyte support for lyx
Sure, you can.
Re: multibyte support for lyx
You have to add the following line, "#undef HAVE_XOPENIM" somewhere in "acconfig.h". I forgot to include this in the patch, sorry.
Re: multibyte support for lyx
You have to add the following line, "#undef HAVE_XOPENIM" somewhere in "acconfig.h". I forgot to include this in the patch, sorry.
Re: Problem of compiling of lyx-1.0.0 at IRIX6.2
On Feb 26, 12:40am, Lars Gullik Bj$)Cxnnes wrote: Subject: Re: Problem of compiling of lyx-1.0.0 at IRIX6.2 It gives AFAICS a lot of errors that would have made sense if LyX were compiled with a C compiler not a C++ one. Are you sure g++ is used throughout? What about the -ansi switch? Lgb -- End of excerpt from Lars Gullik Bjxnnes It is quite strange that with the same compiler ( gcc-2.8), "configure" results in quite differently (especially in the c++ compiler flags): At lyx-1_0_x, Configuration: Source code location: . Compiler: g++-2.8 Compiler flags: -g -O2 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx Special flags: and at lyx-1.1, Configuration: Source code location: . C++ Compiler: g++-2.8 C++ Compiler flags: -O -ansi -Wall C Compiler: gcc C Compiler flags: -O2 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx Special flags: warnings included-string. Is this normal?
Re: Problem of compiling of lyx-1.0.0 at IRIX6.2
On Feb 26, 12:40am, Lars Gullik Bj$)Cxnnes wrote: > Subject: Re: Problem of compiling of lyx-1.0.0 at IRIX6.2 > > It gives AFAICS a lot of errors that would have made sense if LyX were > compiled with a C compiler not a C++ one. > > Are you sure g++ is used throughout? What about the -ansi switch? > > Lgb >-- End of excerpt from Lars Gullik Bjxnnes It is quite strange that with the same compiler ( gcc-2.8), "configure" results in quite differently (especially in the c++ compiler flags): At lyx-1_0_x, Configuration: Source code location: . Compiler: g++-2.8 Compiler flags: -g -O2 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx Special flags: and at lyx-1.1, Configuration: Source code location: . C++ Compiler: g++-2.8 C++ Compiler flags: -O -ansi -Wall C Compiler: gcc C Compiler flags: -O2 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx Special flags: warnings included-string. Is this normal?
Re: Problem of compiling of lyx-1.0.0 at IRIX6.2
It is strange that with the same compiler, I have been able to compile lyx-0.12 and even the most recent klyx-0.9.9. I think some code changes from lyx-0.12 to lyx-1.0 make the compilation errors. Fortunately, gcc-2.8 can cleanly compile the lyx-1.0 source (not even one line of warning !), but I have tons of compilation errors (attached below) from the compilation of the lyx-1.1 cvs-source with gcc-2.8. Any idea? ** ** make[2]: Entering directory `/disk3/cghan/lyx/src/support' g++-2.8 -DHAVE_CONFIG_H -I. -I. -I../../src/include -I./../include -O -ansi -Wall -c filetools.C filetools.C:298: warning: #warning Look at and fix this. filetools.C:320: warning: #warning Verify that this is correct. ../../src/include/filetools.h: In method `void FilePtr::do_open(const class LString , enum FilePtr::file_mode)': In file included from filetools.C:27: ../../src/include/filetools.h:98: warning: implicit declaration of function `int fileno(...)' ../../src/include/lstrings.h: In function `int compare_no_case(const class LString , const class LString , unsigned int)': In file included from filetools.C:32: ../../src/include/lstrings.h:37: declaration of C function `int compare_no_case(const class LString , const class LString , unsigned int)' conflicts with ../../src/include/lstrings.h:16: previous declaration `int compare_no_case(const class LString , const class LString )' here ../../src/include/lstrings.h: In function `int compare_no_case(const class LString , const class LString )': ../../src/include/lstrings.h:39: warning: implicit declaration of function `int strncasecmp(...)' ../../src/include/lstrings.h: In function `int compare(const char *, const char *, unsigned int)': ../../src/include/lstrings.h:50: declaration of C function `int compare(const char *, const char *, unsigned int)' conflicts with ../../src/include/lstrings.h:44: previous declaration `int compare(const char *, const char *)' here ../../src/include/lstrings.h: At top level: ../../src/include/lstrings.h:64: declaration of C function `class LString tostr(unsigned int)' conflicts with ../../src/include/lstrings.h:62: previous declaration `class LString tostr(int)' here ../../src/include/lstrings.h:66: declaration of C function `class LString tostr(long int)' conflicts with ../../src/include/lstrings.h:64: previous declaration `class LString tostr(unsigned int)' here ../../src/include/lstrings.h:68: declaration of C function `class LString tostr(void *)' conflicts with ../../src/include/lstrings.h:66: previous declaration `class LString tostr(long int)' here ../../src/include/lstrings.h:70: declaration of C function `class LString tostr(bool)' conflicts with ../../src/include/lstrings.h:68: previous declaration `class LString tostr(void *)' here ../../src/include/lstrings.h:72: declaration of C function `class LString tostr(float)' conflicts with ../../src/include/lstrings.h:70: previous declaration `class LString tostr(bool)' here ../../src/include/lstrings.h:74: declaration of C function `class LString tostr(double)' conflicts with ../../src/include/lstrings.h:72: previous declaration `class LString tostr(float)' here ../../src/include/lstrings.h:83: declaration of C function `bool suffixIs(const class LString , const char *)' conflicts with ../../src/include/lstrings.h:80: previous declaration `bool suffixIs(const class LString , char)' here ../../src/include/lstrings.h:86: declaration of C function `bool contains(const class LString , const char *)' conflicts with ../../src/include/lstrings.h:85: previous declaration `bool contains(const char *, const class LString )' here ../../src/include/lstrings.h:87: declaration of C function `bool contains(const class LString , const class LString )' conflicts with ../../src/include/lstrings.h:86: previous declaration `bool contains(const class LString , const char *)' here ../../src/include/lstrings.h:88: declaration of C function `bool contains(const char *, const char *)' conflicts with ../../src/include/lstrings.h:87: previous declaration `bool contains(const class LString , const class LString )' here ../../src/include/lstrings.h:122: declaration of C function `class LString subst(const class LString , const char *, const class LString )' conflicts with ../../src/include/lstrings.h:118: previous declaration `class LString subst(const class LString , char, char)' here ../../src/include/lstrings.h:135: declaration of C function `class LString frontStrip(const class LString , const char *)' conflicts with ../../src/include/lstrings.h:131: previous declaration `class LString frontStrip(const class LString , char = ' ')' here ../../src/include/lstrings.h:147: declaration of C function `class LString split(const class LString , char)' conflicts with ../../src/include/lstrings.h:144: previous declaration `class LString split(const class LString , class LString ,
Re: Problem of compiling of lyx-1.0.0 at IRIX6.2
It is strange that with the same compiler, I have been able to compile lyx-0.12 and even the most recent klyx-0.9.9. I think some code changes from lyx-0.12 to lyx-1.0 make the compilation errors. Fortunately, gcc-2.8 can cleanly compile the lyx-1.0 source (not even one line of warning !), but I have tons of compilation errors (attached below) from the compilation of the lyx-1.1 cvs-source with gcc-2.8. Any idea? ** ** make[2]: Entering directory `/disk3/cghan/lyx/src/support' g++-2.8 -DHAVE_CONFIG_H -I. -I. -I../../src/include -I./../include -O -ansi -Wall -c filetools.C filetools.C:298: warning: #warning Look at and fix this. filetools.C:320: warning: #warning Verify that this is correct. ../../src/include/filetools.h: In method `void FilePtr::do_open(const class LString &, enum FilePtr::file_mode)': In file included from filetools.C:27: ../../src/include/filetools.h:98: warning: implicit declaration of function `int fileno(...)' ../../src/include/lstrings.h: In function `int compare_no_case(const class LString &, const class LString &, unsigned int)': In file included from filetools.C:32: ../../src/include/lstrings.h:37: declaration of C function `int compare_no_case(const class LString &, const class LString &, unsigned int)' conflicts with ../../src/include/lstrings.h:16: previous declaration `int compare_no_case(const class LString &, const class LString &)' here ../../src/include/lstrings.h: In function `int compare_no_case(const class LString &, const class LString &)': ../../src/include/lstrings.h:39: warning: implicit declaration of function `int strncasecmp(...)' ../../src/include/lstrings.h: In function `int compare(const char *, const char *, unsigned int)': ../../src/include/lstrings.h:50: declaration of C function `int compare(const char *, const char *, unsigned int)' conflicts with ../../src/include/lstrings.h:44: previous declaration `int compare(const char *, const char *)' here ../../src/include/lstrings.h: At top level: ../../src/include/lstrings.h:64: declaration of C function `class LString tostr(unsigned int)' conflicts with ../../src/include/lstrings.h:62: previous declaration `class LString tostr(int)' here ../../src/include/lstrings.h:66: declaration of C function `class LString tostr(long int)' conflicts with ../../src/include/lstrings.h:64: previous declaration `class LString tostr(unsigned int)' here ../../src/include/lstrings.h:68: declaration of C function `class LString tostr(void *)' conflicts with ../../src/include/lstrings.h:66: previous declaration `class LString tostr(long int)' here ../../src/include/lstrings.h:70: declaration of C function `class LString tostr(bool)' conflicts with ../../src/include/lstrings.h:68: previous declaration `class LString tostr(void *)' here ../../src/include/lstrings.h:72: declaration of C function `class LString tostr(float)' conflicts with ../../src/include/lstrings.h:70: previous declaration `class LString tostr(bool)' here ../../src/include/lstrings.h:74: declaration of C function `class LString tostr(double)' conflicts with ../../src/include/lstrings.h:72: previous declaration `class LString tostr(float)' here ../../src/include/lstrings.h:83: declaration of C function `bool suffixIs(const class LString &, const char *)' conflicts with ../../src/include/lstrings.h:80: previous declaration `bool suffixIs(const class LString &, char)' here ../../src/include/lstrings.h:86: declaration of C function `bool contains(const class LString &, const char *)' conflicts with ../../src/include/lstrings.h:85: previous declaration `bool contains(const char *, const class LString &)' here ../../src/include/lstrings.h:87: declaration of C function `bool contains(const class LString &, const class LString &)' conflicts with ../../src/include/lstrings.h:86: previous declaration `bool contains(const class LString &, const char *)' here ../../src/include/lstrings.h:88: declaration of C function `bool contains(const char *, const char *)' conflicts with ../../src/include/lstrings.h:87: previous declaration `bool contains(const class LString &, const class LString &)' here ../../src/include/lstrings.h:122: declaration of C function `class LString subst(const class LString &, const char *, const class LString &)' conflicts with ../../src/include/lstrings.h:118: previous declaration `class LString subst(const class LString &, char, char)' here ../../src/include/lstrings.h:135: declaration of C function `class LString frontStrip(const class LString &, const char *)' conflicts with ../../src/include/lstrings.h:131: previous declaration `class LString frontStrip(const class LString &, char = ' ')' here ../../src/include/lstrings.h:147: declaration of C function `class LString split(const class LString &, char)' conflicts with ../../src/include/lstrings.h:144: previous declaration `class LString split(const class
Re: Problem of compiling of lyx-1.0.0 at IRIX6.2
On Feb 19, 3:43pm, Jean-Marc Lasgouttes wrote: Subject: Re: Problem of compiling of lyx-1.0.0 at IRIX6.2 "ChangGil" == ChangGil Han [EMAIL PROTECTED] writes: ChangGil Hello, The compilation of lyx-1.0.0 at my Indigo2 (IRIX6.2) ChangGil fails with the attached error messages (I have had no ChangGil problem with the previos versions). My compiler is ChangGil gcc-2.7.2.3. I know there are binary distributions, but I ChangGil want to compile myself. Can anyone help me? Thanks in ChangGil advance. These error messages are really strange. Are you sure that your g++ compiler is also version 2.7.2.3 (g++ -v)? Newer versions of LyX compile with g++ and not gcc by default. JMarc -- End of excerpt from Jean-Marc Yes, It is version 2.7.2.3: "g++ -v" gives "Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.3/specs gcc version 2.7.2.3" Any hints? Thanks.
Re: Problem of compiling of lyx-1.0.0 at IRIX6.2
On Feb 19, 3:43pm, Jean-Marc Lasgouttes wrote: > Subject: Re: Problem of compiling of lyx-1.0.0 at IRIX6.2 > >>>>> "ChangGil" == ChangGil Han <[EMAIL PROTECTED]> writes: > > ChangGil> Hello, The compilation of lyx-1.0.0 at my Indigo2 (IRIX6.2) > ChangGil> fails with the attached error messages (I have had no > ChangGil> problem with the previos versions). My compiler is > ChangGil> gcc-2.7.2.3. I know there are binary distributions, but I > ChangGil> want to compile myself. Can anyone help me? Thanks in > ChangGil> advance. > > These error messages are really strange. Are you sure that your g++ > compiler is also version 2.7.2.3 (g++ -v)? Newer versions of LyX > compile with g++ and not gcc by default. > > JMarc >-- End of excerpt from Jean-Marc Yes, It is version 2.7.2.3: "g++ -v" gives "Reading specs from /usr/local/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.3/specs gcc version 2.7.2.3" Any hints? Thanks.
