Re: multibyte support for lyx
On Sat, Dec 15, 2007 at 04:44:54PM +0900, [EMAIL PROTECTED] wrote: > > I would like to report that Korean as well as Japanese support for the > lyx-1.1.3 is now possible. The binary package in the rpm format and the > source package in the compressed atr format are available at > ftp://stone.phys.pusan.ac.kr/pub/lyx-kr. Thank you for making the patch. I'm japanese LyX user and waiting for japanese patch for 1.1.3. I got your patch, but couldn't make it. I got the following message, make[1]: Entering directory /home/kohtaro/tmp/lyx-1.1.3/src' cd .. && autoheader /usr/bin/autoheader: Symbol HAVE_XOPENIM' is not covered by /usr/lib/autoconf/a cconfig.h ./acconfig.h make[1]: *** [stamp-h.in] Error 1 make[1]: Leaving directory /home/kohtaro/tmp/lyx-1.1.3/src' make: *** [all-recursive] Error 1 Could you teach me how to make the program. I'm using redhat 5.3 on PC and redhat 6.0 on alpha. Both machine could not make. -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kohtaro Hitomi Kyoto Institute of Technology Phone:+81-75-724-7262, Fax:+81-75-724-7250
Re: multibyte support for lyx
> "Kohtaro" == Kohtaro Hitomi <[EMAIL PROTECTED]> writes: Kohtaro> On Sat, Dec 15, 2007 at 04:44:54PM +0900, Kohtaro> [EMAIL PROTECTED] wrote: >> I would like to report that Korean as well as Japanese support for >> the lyx-1.1.3 is now possible. The binary package in the rpm format >> and the source package in the compressed atr format are available >> at ftp://stone.phys.pusan.ac.kr/pub/lyx-kr. Kohtaro> Thank you for making the patch. I'm japanese LyX user and Kohtaro> waiting for japanese patch for 1.1.3. Kohtaro> I got your patch, but couldn't make it. I got the following Kohtaro> message, Hello, Check your versions of autoconf and automake. These should be 2.13 for autoconf and 1.4 for automake (use --version to get the version). JMarc
Unnecessary compiler warnings with lyx-1.1.4pre1
I'm compiling lyx-1.1.4pre1 using egcs-1.1.2 on Alpha with DU3.2. (OK, so I'm lazy and haven't upgraded to a more recent version of Tru64 Unix) Omitting the CXXFLAG -Wno-return-type leads to huge numbers of warning messages: /usr/include/X11/Xlib.h:2481: warning: return-type of `XDrawImageString' defaults to `int' Best wishes, Angus -- DR ANGUS LEEMING <[EMAIL PROTECTED]> Department of Biological and Medical Systems Imperial College LONDON SW7 2BX Tel. 0171 594 5186 Fax. 0171 584 6897
Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
Hello, today I tried to compile Lyx 1.1.3 with Sun's CC (C++ Workshop compiler version 5.0) on Solaris 2.7. This compiler is said to comply to the ANSI C++ standard. Unfortunately, I haven't been successful because of several problems in the code. Could anybody please take a look at the messages below? I only list the most important errors. There exists a large number of warnings indicating, e.g. anachronisms in the C++ code. If somebody is interested in a full listing of the compiler output please do not hesitate to contact me. Kind regards, Michael PS: Once I will be able to compile Lyx with Sun's Workshop compiler, I will try to debug Lyx with the famous Purify run-time checker. One of my students that has to write a long document with Lyx (I forced him to do so :-) complains about a lot of crashes that seem to be related to the usage of figures (especially subfigures) within a Lyx document. Purify may help to detect the cause for these crashes (frankly speaking I am not familiar with the Lyx nor do I have the time to fix bigger problems on my own; I can only report problems) +++ CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 -g -c math_panel.C -o math_panel.o "../../images/sqrt.xpm", line 2: Error: Multiple declaration for sqrt. "math_panel.C", line 275: Error: Cannot return extern "C" double(*)(double) from a function that should return char**. "math_panel.C", line 301: Error: Formal argument 2 of type char** in call to fl_set_pixmap_data(flobjs_*, char**) is being passed extern "C" double(*)(double). "figinset.C", line 257: Error: The function "kill" must have a prototype. "figinset.C", line 1727: Error: Unknown preprocessor directive." "insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is not accessible from file level. "filetools.C", line 325: Error: Formal argument 1 of type char* in call to putenv(char*) is being passed const char*. "lstrings.C", line 178: Error: Could not find a match for std::count<>(const char*, const char*, const char). "ImportNoweb.C", line 57: Error: Unknown preprocessor directive. "LyXAction.C", line 614: Error: Unknown preprocessor directive. "bmtable.C", line 46: Error: The function "calloc" must have a prototype. "bmtable.C", line 212: Error: The function "free" must have a prototype. "support/lstrings.h", line 16: Error: Templates can only declare classes or functions. "support/lstrings.h", line 19: Error: size_t is not defined. "support/lstrings.h", line 20: Error: "," expected instead of "const". "support/lstrings.h", line 21: Error: A declaration was expected instead of "while". "support/lstrings.h", line 21: Error: ")" expected instead of "!=". "support/lstrings.h", line 21: Error: Multiple declaration for count. "support/lstrings.h", line 22: Error: A declaration was expected instead of "return". "support/lstrings.h", line 23: Error: A declaration was expected instead of "}". "layout.C", line 946: Error: Cannot use std::pair to initialize std::pair. "lyx_cb.C", line 1116: Error: Unknown preprocessor directive. "../src/lyx_main.C", line 139: Error: The function "signal" must have a prototype. "lyxfunc.C", line 391: Error: Unknown preprocessor directive. -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> Hello, today I tried to compile Lyx 1.1.3 with Sun's CC (C++ Michael> Workshop compiler version 5.0) on Solaris 2.7. This compiler Michael> is said to comply to the ANSI C++ standard. Yes, we'd like to get LyX to compile there, but I do not have access to it. Michael>Unfortunately, I Michael> haven't been successful because of several problems in the Michael> code. Could anybody please take a look at the messages below? Michael> I only list the most important errors. There exists a large Michael> number of warnings indicating, e.g. anachronisms in the C++ Michael> code. If somebody is interested in a full listing of the Michael> compiler output please do not hesitate to contact me. First thing, could you get lyx 1.1.4pre1 and work from that? This would be much easier for us. Then send to the list the complete error log that you get. Michael> PS: Once I will be able to compile Lyx with Sun's Workshop Michael> compiler, I will try to debug Lyx with the famous Purify Michael> run-time checker. I run purify on lyx from time to time, but since I do not know what to try, I do not find many things these days... Note that the figure code will be rewritten as soon as we can. I added a few comments below. JMarc Michael> CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ Michael> -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 Michael> -g -c math_panel.C -o math_panel.o "../../images/sqrt.xpm", Michael> line 2: Error: Multiple declaration for sqrt. "math_panel.C", Michael> line 275: Error: Cannot return extern "C" double(*)(double) Michael> from a function that should return char**. "math_panel.C", Michael> line 301: Error: Formal argument 2 of type char** in call to Michael> fl_set_pixmap_data(flobjs_*, char**) is being passed extern Michael> "C" double(*)(double). This one is fixed in 1.1.4pre1. Michael> "figinset.C", line 257: Error: The function "kill" must have Michael> a prototype. It seems that CC declares C functions in the std:: namespace. There are two solutions there: either you can convince CC that should declare kill in normal namespace, or you will have to add directives like using std::kill; in each file where this error occurs. I did that for all the STL stuff we need because DEC cxx declares STL stuff in std::. Michael> "figinset.C", line 1727: Error: Unknown Michael> preprocessor directive." This is the #warning directive. From what Lars said, CC should just ignore it. Since it does not (and assuming you cannot change this behaviour) you can configure with --without-warnings. Michael> "insetlatexaccent.C", line 645: Error: Michael> InsetLatexAccent::ACCENT_TYPES is not accessible from file Michael> level. I don't know about this one. Michael> "filetools.C", line 325: Error: Formal argument 1 of type Michael> char* in call to putenv(char*) is being passed const char*. I know about this one, but since Solaris 7 is the only OS to declare putenv with a char* argument (even sol 2.6 does not), I have to devise a test especially. Michael> "lstrings.C", line 178: Error: Could not find a match for Michael> std::count<>(const char*, const char*, const char). Don't know about that. Michael> "bmtable.C", line 46: Error: The function "calloc" must have Michael> a prototype. "bmtable.C", line 212: Error: The function Michael> "free" must have a prototype. Like for kill() Michael> "support/lstrings.h", line 16: Error: Templates can only Michael> declare classes or functions. "support/lstrings.h", line 19: Don't know. Michael> Error: size_t is not defined. Like for kill() Michael> "layout.C", line 946: Error: Cannot use std::pair Michael> to initialize std::pair. Don't know.
year end statistics
In case you are interested: Devel: = -rw-rw-r-- 1 lyx lyx 3296 Oct 31 1998 devel.old.subs wc -l devel.old.subs 134 devel.old.subs ezmlm-list ~/DEVEL/|wc -l 120 ezmlm-list ~/DEVEL/digest/|wc -l 20 Users: = -rw-r--r-- 1 lyx lyx 8415 Mar 17 1999 users.old.subs wc -l users.old.subs 354 users.old.subs ezmlm-list ~/USERS/|wc -l 414 ezmlm-list ~/USERS/digest/|wc -l 27 Announce: -rw-rw-r-- 1 lyx lyx 8370 Nov 16 1998 announce.old.subs wc -l announce.old.subs 362 announce.old.subs ezmlm-list ~/ANNOUNCE/|wc -l 500 Mate
Re: year end statistics
> "Mate" == Mate Wierdl <[EMAIL PROTECTED]> writes: Mate> In case you are interested: Devel: = -rw-rw-r-- 1 lyx lyx Mate> 3296 Oct 31 1998 devel.old.subs Mate> wc -l devel.old.subs 134 devel.old.subs Mate> ezmlm-list ~/DEVEL/|wc -l 120 Interesting indeed. If we are 120 developpers, it should only take a few days to finish this damn stuff. Or maybe the 14 who left this year were the ones who could actually help? Mate> wc -l users.old.subs 354 users.old.subs Mate> ezmlm-list ~/USERS/|wc -l 414 That's a lot of people. Maybe I should consider saying fewer stupid things, then... And also the web page says: ``At least 264455 hits on this page.''. However, I'm not sure the counter began at 0... JMarc
Re: Anybody tried to get the lyx-devel branch running on NT ?
I have automake-1.4 from gtp.gnu.org and autoconf-1.13 from the same site. Got them yesterday. Maybe they arent working properly under Cygwin but I'd be very surprised. Roland On 16-Dec-99 Allan Rae wrote: > >>From your log of autogen.sh output it appears you need to upgrade to > automake-1.4 > > Allan. (ARRae) Roland Krause Visiting Research Associate - Center for Computational Mechanics Washington University, Saint Louis Roland Krause <[EMAIL PROTECTED]>
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
Jean-Marc Lasgouttes wrote: > Michael> Hello, today I tried to compile Lyx 1.1.3 with Sun's CC (C++ > Michael> Workshop compiler version 5.0) on Solaris 2.7. This compiler > Michael> is said to comply to the ANSI C++ standard. > > Yes, we'd like to get LyX to compile there, but I do not have access to > it. Thank you very much for your quick response. I was afraid that you consider my comments useless. If you like to I can recompile lyx from time to time for you with Sun's CC. That's no big effort for me. > First thing, could you get lyx 1.1.4pre1 and work from that? This > would be much easier for us. Then send to the list the complete error > log that you get. OK, I downloaded this developer release. But certainly you won't like the new compiler output. There seem to be many identical error messages, mostly related to a missing ostream class (seems to be a namespace problem (?)). Nevertheless, I attached the complete output to this mail. I turned on all warnings and errors and requested full ANSI standard conformance tests when running the compiler. > I run purify on lyx from time to time, but since I do not know what to > try, I do not find many things these days... Note that the figure code > will be rewritten as soon as we can. Nice to see that Purify is actually used to ensure software quality. I wouldn't like to trust any piece of software that does not use a run-time checker. Happy bug fixing, Michael PS: Please contact me if I can do anything for you. -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de == compile_errors.gz
Re: Unnecessary compiler warnings with lyx-1.1.4pre1
Angus Leeming <[EMAIL PROTECTED]> writes: | I'm compiling lyx-1.1.4pre1 using egcs-1.1.2 on Alpha with DU3.2. (OK, so I'm | lazy and haven't upgraded to a more recent version of Tru64 Unix) | | Omitting the CXXFLAG -Wno-return-type leads to huge numbers of | warning messages: | /usr/include/X11/Xlib.h:2481: warning: return-type of | `XDrawImageString' defaults to `int' Does a "-fpermissive" work just as well? what is the version string of your compiler? Lgb
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 -g -c formula.C -o formula.o "../../src/debug.h", line 65: Error: ostream is not defined. "../../src/debug.h", line 68: Error: ostream is not defined. Try to add using std::ostream; right after #include in src/support/DebugStream.h If that does not work I think your compiler is wrong. Most of the other errors comes because of this. Hard to the real problems in all the noise. Lgb
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> CC -DHAVE_CONFIG_H -I. -I. -I../../src -I../../images -I./../ Lars> -I/opt/local/include -I/usr/openwin/include +p +w2 -compat=5 -g Lars> -c formula.C -o formula.o "../../src/debug.h", line 65: Error: Lars> ostream is not defined. "../../src/debug.h", line 68: Error: Lars> ostream is not defined. Lars> Try to add Lars> using std::ostream; Lars> right after #include in src/support/DebugStream.h Lars> If that does not work I think your compiler is wrong. Lars> Most of the other errors comes because of this. I already answered him to add a #include "support/LOstream.h" at the beginning of debug.h. I think he is using STL string, and ostreams are defined in lyxstring.h, so I did not see that I missed the header in my last debug patch. JMarc
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
Michael Schmitt <[EMAIL PROTECTED]> writes: | "figinset.C", line 257: Error: The function "kill" must have a | prototype. In my docs "kill" is not an ANSI C function and should not really be in namespace std, but it seems that CC has put it there. Add a using std::kill; and file a bug report to SUN. | "figinset.C", line 1727: Error: Unknown preprocessor directive." I was pretty sure that unknown preprocessor directives should be ignored, but since I cannot find a reference I might be wrong... We should make sure to wrap all the #warning dircetives then. | "insetlatexaccent.C", line 645: Error: InsetLatexAccent::ACCENT_TYPES is | not accessible from file level. This is one error I don't really understand. | "filetools.C", line 325: Error: Formal argument 1 of type char* in call | to putenv(char*) is being passed const char*. file a bug report to SUN. | "lstrings.C", line 178: Error: Could not find a match for | std::count<>(const char*, const char*, const char). Missing prototype in CC's libraries. Easy to work around. | "bmtable.C", line 46: Error: The function "calloc" must have a | prototype. | "bmtable.C", line 212: Error: The function "free" must have a | prototype. bmtable should really be put in a _C_ library and compiled with a _C_ compilator. | | "support/lstrings.h", line 16: Error: Templates can only declare classes | or functions. | "support/lstrings.h", line 19: Error: size_t is not defined. using std::size_t; should probably fix that. | "layout.C", line 946: Error: Cannot use std::pair to | initialize std::pair. missing prototype in CC's lib. file a buf report. (we can fix this with a static_cast) | "../src/lyx_main.C", line 139: Error: The function "signal" must have a | prototype. using std::signal; Lgb
Re: year end statistics
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | And also the web page says: ``At least 264455 hits on this page.''. | | However, I'm not sure the counter began at 0... It did, but it some time ago... the number is actually on the low side... Lgb
Re: Cannot compile Lyx 1.1.3 with SUN C++ on Solaris
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I already answered him to add a #include "support/LOstream.h" at the | beginning of debug.h. I think he is using STL string, and ostreams | are defined in lyxstring.h, so I did not see that I missed the header | in my last debug patch. I think iostream is required to includ ostream so I think LOstream.h is a bit wrong. I had some problems with L[IO]stream.h when trying out the gcu libstd++ libarary. Lgb
[triller@forwiss.uni-passau.de] Feedback from www.lyx.org
--- Start of forwarded message --- Date: Thu, 16 Dec 1999 15:31:31 +0100 Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Feedback from www.lyx.org FROM: [EMAIL PROTECTED] Triller Peter ([EMAIL PROTECTED]) entered the following feedback message on the LyX home page: Hello, I found a minor flaw in lyx.. I just installed lyx 1.1.3 (and 1.1.2 for that matter) with the following configure command on a Solaris 2.6 Sparc station ./configure --exec-prefix=/public/packages/text/lyx-1.1.3 --prefix=/common/packages/text/lyx-1.1.3 But lyx doesn\'t come up The reason for this is , it searches for it\'s scripts in the wrong places... after doing a make install, we link the executables to /public/bin when I startup lyx, it looks for ist\'s files in \"/public/share/lyx\" and \"/public/packages/text/lyx-1.1.3/share/lyx\" but the files were installed in \"/common/packages/text/lyx-1.1.3/share/lyx\" I made a softlink so now it works, but I think this is a minor bug Thnx and bye Peter Triller --- End of forwarded message ---
Re: year end statistics
Or maybe the 14 who left this year were the ones who could actually help? Well, they may not have left---see the stats for the devel digest list. Mate
listfiles
And another two responses from Lars missed... Concerning 'lastfile.[Ch]'. I see no obvious reason to have an arbitrary upper limit on the number of lastfiles. If anybody wants to have 50 files - let him have it. The menu is not in sync with the implementation of LastFiles anyway... If you drop this restriction, setNumberOfFiles is no more needed, the last two lines of newFile could go, half of the while-condition in readFile could go etc. I'd even say, lyxrc's \num_lastfile could go. Sometimes it's nice to be able to configure things. But how many users ever will use this feature? Bloat? Well. This is certainly some sort of religious question. If the provided functionality is not *dearly* needed, my religion says it is bloat. Having bits of code just because "it is nice and could perhaps be useful later" is a thing that is difficult to accept for me. Andre' PS: We are talking about 2132 bytes in the unstripped and 512 bytes in the stripped binary. This is about 1/4000 of the total. Yes, most people think this is peanuts. -- André Pönitz . [EMAIL PROTECTED]
Re: multibyte support for lyx
On Thu, Dec 16, 1999 at 09:48:32AM +0100, Jean-Marc Lasgouttes wrote: > > Check your versions of autoconf and automake. These should be 2.13 for > autoconf and 1.4 for automake (use --version to get the version). > > JMarc Thank you Jean-Marc. I updated autoconf and automake, but I can't compile and got the same message. -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kohtaro Hitomi Kyoto Institute of Technology Phone:+81-75-724-7262, Fax:+81-75-724-7250
Improper scope of centering command in 1.0.4, 1.1.2 & 1.1.3
Exporting a LyX document containing a table in the LaTeX format
and importing the LaTeX file centers the text below the table.
The reason for this bug seems to be the improper understanding of the
scope of the centering command (that's how LyX centers a table) during
LaTeX file import: if the exported file is processed and displayed in the
usual way (latex and xdvi) everything is fine. Attached is the LaTeX file
that was exported from LyX and it shows the bug described above.
1.0.4, 1.1.2 and 1.1.3 versions show the same behavior, I run it on Linux
(kernel 2.0.36).
If anyone needs to contact me, please send me the email directly; I'm not
on this mailing list.
Thanks
Vladan Lucic
%% This LaTeX-file was created by Thu Dec 16 13:17:11 1999
%% LyX 1.0 (C) 1995-1999 by Matthias Ettrich and the LyX Team
%% Do not edit this file unless you know what you are doing.
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\makeatletter
%% LyX specific LaTeX commands.
\providecommand{\LyX}{L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
\makeatother
\begin{document}
Let's start
\vspace{0.3cm}
{\centering \begin{tabular}{|c|c|}
\hline
aha &
hoho\\
\hline
\hline
auyee&
eue\\
\hline
\end{tabular}\par}
\vspace{0.3cm}
should not be centered
\end{document}
Re: Hebrew support for LyX
Shigeru Miyata wrote: > "Seak, Teng-Fong" <[EMAIL PROTECTED]> wrote: > > > Chinese (as well as Japanese and Korean) can also be written from right to > > left, even though this isn't very common nowadays. Actually, in tradition, > > Chinese is written from top to the bottom, then from right to left. But I > > don't think Latex is able to support this :-) > > Theoretically speaking it is of course possible. However, dimensions > [deleted] > TTB_RTL (for Chinese, Japanese, etc.) and TTB_LTR (for Mongolian) > primitives. Actually, there's another possible solution (or even simpler): rotate all characters to the left by 90° :-) but only if it's supported by LaTeX. If this is supported, we just need to type in LTR then TTB and after rotation, the text will be TTB then RTL. But I'm not sure if LaTeX supports already double-byte encoding, so I'm not going to ask this question in the newsgroup for the moment. Seak
Re: FILE -> ostream
> Asger> Now, if only I had time... > > OK. I grant you one week. Is that enough? %-] Hey! That's an insult, and it's not even Friday yet! You know I only need five and half minutes %-] But then, even that is hard to find these days. So many other things come first. For instance, I'll going to drik a few beers tomorrow. Cheers, Asger
Re: Internationalization and cvs
Andre' Poenitz wrote: > Concerning the multi-byte encoding: We should have a discussion > whether > it is sensible to use Unicode internally. The world is changing and > last > years' arguments won't fit anymore. May I know what this "last year's argument" is? I joined this list for less than one month. > We could get rid of almost all of the encoding stuff at the price of > double sized buffers plus quite a bit of work. But in the end thing > would be much simpler It might have other advantages. Eg, lastest versions of Windows use Unicode internally and LyX is ported to windows, using Unicode inside LyX perhaps could help i18n/l10n (if this is possible with Cygnus) work also for windows port more "natively"? That is, windows doesn't have to translate a menu string from a particular encoding to Unicode before displaying it.
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
On Thu, Dec 16, 1999 at 05:58:00PM -0800, ChangGil Han wrote: > You have to add the following line, > "#undef HAVE_XOPENIM" > somewhere in "acconfig.h". I forgot to > include this in the patch, sorry. Thank you ChangGil, I can compile. I'll send you a report later. Anyway can I place a link to your ftp site from my web pege (http://www.hiei.kit.ac.jp/~hitomi/lyx)? -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/ Kohtaro Hitomi Kyoto Institute of Technology Phone:+81-75-724-7262, Fax:+81-75-724-7250
[Fwd: multibyte support for lyx]
On Fri, 17 Dec 1999, Seak, Teng-Fong wrote: > [EMAIL PROTECTED] wrote: > > > I would like to report that Korean as well as Japanese support for the > > lyx-1.1.3 is now possible. The binary package in the rpm format and the > > source package in the compressed atr format are available at > > ftp://stone.phys.pusan.ac.kr/pub/lyx-kr. > > [deleted] > > If any developers interested, I would like to summit the patch file > > against the recent cvs source. > > > > Regards, > > ChangGil Han. > > That's a good news. However, sorry that I sound skeptical, but Shigeru > in another post said that Xform cannot draw 16 bit character strings. > You've fiddled Xform? > > Seak > > > I do not know much about the codes. But Chideok Hwang at [EMAIL PROTECTED], who is the author of a Korean input method, "Ami", told me that xform library has the problem and his function, "XNextEvent" added to the original "lyxim.C" of Kawakami, can handle the problem. I don't know whether that is the problem you are referring to. You may examine the codes at the last part of lyxim.C. Regards, ChangGil Han
