from:"Koji Yokota"

Difference of two MacOS binaries for 2.3.7?

2023-01-11 Thread Koji Yokota

Dear list,

Congratulations on the release of LyX 2.3.7!

Could someone teach me the difference of two MacOS binaries for 2.3.7?
There are two binaries,
(A) LyX-2.3.7+qt5-x86_64-arm64-cocoa.dmg and
(B) LyX-2.3.7+qt5-x86_64-cocoa.dmg for older OS.

Question is:

- Does it mean binary (A) doesn't work on older OS's? Or can it be run on
any OS versions?
- If not, which version of OS is exactly the threshold of these two?

I'm currently checking the validity of Homebrew formula and it would be
helpful if you give me the information.

Thank you for your help.

Koji Yokota
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Final round: Request to update docs for LyX 2.2.0

2016-01-29 Thread Koji Yokota

Hi Uwe,

I attach the screenshot to this mail. It seems there is no corresponding
strings included in .nsh files.

Best regards,

Koji

On 2016年01月28日 08:26, Uwe Stöhr wrote:
> Am 27.01.2016 um 09:29 schrieb Koji Yokota:
>
>> I browsed the Windows installer for 2.2 alpha a little bit and found the
>> pane titled "Choose Users" is not translated yet.
>
> Hi Koji,
>
> I cannot find this. Could you please send me a screenshot?
>
> You find the translations for the installer in this Git folder:
> ~/development/Win32/packaging/installer/lang
>
> (
> http://www.lyx.org/trac/browser/lyxgit/development/Win32/packaging/installer/lang
> )
>
> There is one untranslated message. it would be nice if you could
> translate it. Please note that you must use the encoding "Shift_JIS"
> to edit the file japanese.nsh.
> (The required encodings are listed in the file Encodings.txt.)
>
> many thanks and best regards
> Uwe

Re: platex as the default latex command?

2010-08-12 Thread Koji Yokota

 I've committed the patch to trunk now. Awaiting Koji's report before I
 backport the fix.

Sorry for late reply. I tested with several Japanese documents using
the newest svn, and all worked fine.

Koji

Re: platex as the default latex command?

2010-08-12 Thread Koji Yokota

> I've committed the patch to trunk now. Awaiting Koji's report before I
> backport the fix.

Sorry for late reply. I tested with several Japanese documents using
the newest svn, and all worked fine.

Koji

Re: Lyx 2.0alpha5 and texlive 2010

2010-07-26 Thread Koji Yokota

Miguel,

 When I use texlive 2010 with lyx 2.0alpha5, can not preview the document
 koma-script style in ps format, only in pdf(Xetex). By my work is a problem,
 because I need ps format. I have removed ptex and platex in the texlive
 2010, and all work fine. In the texlive 2009 installation, no problem.

I suspect you used Japanese as the document language. ptex and platex
newly introduced in texlive 2010 are not e-TeX compliant and therefore
cannot handle the koma-script style. e-TeX compliant versions are
planned to be introduced texlive 2011. Until then, koma-script cannot
be used with ptex and platex.

Koji

Re: Lyx 2.0alpha5 and texlive 2010

2010-07-26 Thread Koji Yokota

Miguel,

> When I use texlive 2010 with lyx 2.0alpha5, can not preview the document
> koma-script style in ps format, only in pdf(Xetex). By my work is a problem,
> because I need ps format. I have removed ptex and platex in the texlive
> 2010, and all work fine. In the texlive 2009 installation, no problem.

I suspect you used Japanese as the document language. ptex and platex
newly introduced in texlive 2010 are not e-TeX compliant and therefore
cannot handle the koma-script style. e-TeX compliant versions are
planned to be introduced texlive 2011. Until then, koma-script cannot
be used with ptex and platex.

Koji

[Bug 5216] Character omission bug on FreeBSD

2008-11-01 Thread Koji Yokota

Dear list,

I'm trying to resolve Bug 5216
(http://bugzilla.lyx.org/show_bug.cgi?id=5216) in which double-byte char
 between two insets is omit (which may not be resolved before 1.6.0).

The phenomenon seems to occur strangely only on FreeBSD. I confirmed
this on a few machines, but there seems no other FreeBSD users around,
therefore the bug is marked as unconfirmed.

I'm trying to debug it but facing a phenomenon which I don't really
understand. Unfortunately as I'm completely new to C++ (know only about
C), can anybody please give me an advice?

It seems that when LyX outputs a TeX file in a temporary directory to
view a DVI file and it encounters an inset in doing so, it emits all
characters prior to the inset by line 760 of Paragraph.cpp:

odocstream::pos_type const len = os.tellp();

(I confirmed the TeX output file is changed by this line by step
execution in gdb). However, my understanding of tellp() is that it
simply returns the character position in output. Can anybody give me an
advice why this outputs strings and from which variable it is reading
characters to output?

The wrong behavior seems to occur because the pointer position is
mistakenly shifted by one (strangely only on FreeBSD). The above line
doesn't output the double byte character immediately before when it is
between two insets.

Thank you in advance,

Koji

[Bug 5216] Character omission bug on FreeBSD

2008-11-01 Thread Koji Yokota

Dear list,

I'm trying to resolve Bug 5216
(http://bugzilla.lyx.org/show_bug.cgi?id=5216) in which double-byte char
 between two insets is omit (which may not be resolved before 1.6.0).

The phenomenon seems to occur strangely only on FreeBSD. I confirmed
this on a few machines, but there seems no other FreeBSD users around,
therefore the bug is marked as unconfirmed.

I'm trying to debug it but facing a phenomenon which I don't really
understand. Unfortunately as I'm completely new to C++ (know only about
C), can anybody please give me an advice?

It seems that when LyX outputs a TeX file in a temporary directory to
view a DVI file and it encounters an inset in doing so, it emits all
characters prior to the inset by line 760 of Paragraph.cpp:

odocstream::pos_type const len = os.tellp();

(I confirmed the TeX output file is changed by this line by step
execution in gdb). However, my understanding of tellp() is that it
simply returns the character position in output. Can anybody give me an
advice why this outputs strings and from which variable it is reading
characters to output?

The wrong behavior seems to occur because the pointer position is
mistakenly shifted by one (strangely only on FreeBSD). The above line
doesn't output the double byte character immediately before when it is
between two insets.

Thank you in advance,

Koji

Re: 1.6svn: Strange 8s delay when resizing the window, and other odd delays

2008-09-09 Thread Koji Yokota


Dear developers,

I also have found that slowness is strengthened to an unusable level as
I continue to edit a big file.

I'm not sure whether undo memory is related to this, but when I opened
the Users' Guide to translate it, it uses roughly 80M bytes at the
beginning and it grows to 150M bytes after slowness reaches to
unbearable level.

Anyway, after 30 minutes of editing work, I need to restart LyX.

Koji

Helge Hafting wrote:

1.6svn has recently regressed with some strange 100%cpu delays.

I can start up LyX, File-new then takes 6s. File-new again is quick.

Resizing the main window then needs 8s with 100% cpu work, which is 
strange for an _empty_ file.


Even more odd: I can load the userguide and resizing is instant. Switch
back to the empty document, and resizing is slow again. Certainly not 
slow linebreaking, it can be slow even with only a single line that

doesn't need a break.

The slowness is not consistent - sometimes it just disappear. Sometimes,
these delays also appear when editing - click on a table, and get a 
similiar delay, for example.


The problem is present in today's 1.6svn.

Helge Hafting

Re: 1.6svn: Strange 8s delay when resizing the window, and other odd delays

2008-09-09 Thread Koji Yokota


Koji Yokota wrote:

I also have found that slowness is strengthened to an unusable level as
I continue to edit a big file.


p.s. This slowness is the one in how characters are input on screen. 
When it reaches to an extreme, I have to wait almost one second after 
*one* character is input from the keyboard.


Before that I was using an input method to input characters, so it may 
be related to interaction between lyx and input method. But after 
slowness accumulates, it is still slow to input Latin characters anyway.


Koji

Re: 1.6svn: Strange 8s delay when resizing the window, and other odd delays

2008-09-09 Thread Koji Yokota


Dear developers,

I also have found that slowness is strengthened to an unusable level as
I continue to edit a big file.

I'm not sure whether undo memory is related to this, but when I opened
the Users' Guide to translate it, it uses roughly 80M bytes at the
beginning and it grows to 150M bytes after slowness reaches to
unbearable level.

Anyway, after 30 minutes of editing work, I need to restart LyX.

Koji

Helge Hafting wrote:

1.6svn has recently regressed with some strange 100%cpu delays.

I can start up LyX, File->new then takes 6s. File->new again is quick.

Resizing the main window then needs 8s with 100% cpu work, which is 
strange for an _empty_ file.


Even more odd: I can load the userguide and resizing is instant. Switch
back to the empty document, and resizing is slow again. Certainly not 
slow linebreaking, it can be slow even with only a single line that

doesn't need a break.

The slowness is not consistent - sometimes it just disappear. Sometimes,
these delays also appear when editing - click on a table, and get a 
similiar delay, for example.


The problem is present in today's 1.6svn.

Helge Hafting

Re: 1.6svn: Strange 8s delay when resizing the window, and other odd delays

2008-09-09 Thread Koji Yokota


Koji Yokota wrote:

I also have found that slowness is strengthened to an unusable level as
I continue to edit a big file.


p.s. This slowness is the one in how characters are input on screen. 
When it reaches to an extreme, I have to wait almost one second after 
*one* character is input from the keyboard.


Before that I was using an input method to input characters, so it may 
be related to interaction between lyx and input method. But after 
slowness accumulates, it is still slow to input Latin characters anyway.


Koji

Re: Cannot compile today's SVN

2008-06-24 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

These messages are very strange. You may want to remove the directory
autom4te.cahe/. 


Even though I delete autom4te.cache, the last line of autogen.sh,

make -f po/Rules-lyx srcdir=po top_srcdir=.

tries to do

cat  |  msguniq -o .po  rm -f

I attach the whole message of autogen.sh as an attached file.


This is very strange, because it is not supposed to activate this
particular rule... What OS are you using? What version of 'make'?


I'm using FreeBSD and it occurs for both 6.3-RELEASE and 7.0-RELEASE.
So, 'make' calls BSD make (Sorry, I couldn't get its version).

Your suggestion hinted me to rewrote the last line of autogen.sh to
gmake ... instead of make ... to call GNU make, then it finished
configuration correctly, even though I still get the same messages:

config/libtool.m4:3661: _LT_AC_LANG_F77_CONFIG is expanded from...

config/libtool.m4:3660: AC_LIBTOOL_LANG_F77_CONFIG is expanded from...
configure.ac:155: warning: 

AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache-id,
must contain _cv_ to be cached

config/libtool.m4:3761: _LT_AC_LANG_GCJ_CONFIG is expanded from...
config/libtool.m4:3760: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from...


but if I use gmake in the build stage too, it compiled successfully anyway.

Using BSD make in the build stage gets stuck in the build of the po 
directory, because of the same reason as the autogen.sh case:



===  Building for lyx-svn-1.6svn
make  all-recursive
Making all in config
Making all in development
Making all in intl
Making all in po
make lyx-svn.pot-update
sed -e '/^#/d' remove-potcdate.sin  t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o qt4_l10n.pot -t qt4 
../src/frontends/qt4/ui/*.ui
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o layouts_l10n.pot -t 
layouts ../lib/layouts/*.layout ../lib/layouts/*.inc ../lib/layouts/*.module
python ./lyx_pot.py -b .. -o languages_l10n.pot -t languages ../lib/languages
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o ui_l10n.pot -t ui 
../lib/ui/*.ui ../lib/ui/*.inc
python ./lyx_pot.py -b .. -o external_l10n.pot -t external 
../lib/external_templates
python ./lyx_pot.py -b .. -o formats_l10n.pot -t formats ../lib/configure.py
cat  |  msguniq -o lyx-svn.po  rm -f


If I use gmake in all stages, compile finishes in success, but I'm not 
sure warnings that autogen.sh emit are really harmless or not.


Koji



JMarc




Using automake (GNU automake) 1.9.6
Using autoconf (GNU Autoconf) 2.61
Building macros...
/usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of 
AM_PATH_LINC
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition of 
AM_PATH_LIBFAME
/usr/local/share/aclocal/gtk.m4:7: warning: underquoted definition of 
AM_PATH_GTK
/usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of 
AM_PATH_GLIB
/usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of 
AM_PATH_AUDIOFILE
/usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of 
AM_PATH_AALIB
configure.ac:55: warning: AC_COMPILE_IFELSE was called before 
AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:385: AC_USE_SYSTEM_EXTENSIONS is expanded from...
../../lib/autoconf/specific.m4:451: AC_AIX is expanded from...
configure.ac:55: the top level
configure.ac:55: warning: AC_RUN_IFELSE was called before 
AC_USE_SYSTEM_EXTENSIONS
configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): 
suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1973: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:1993: AC_CACHE_CHECK is expanded from...
config/libtool.m4:609: AC_LIBTOOL_LINKER_OPTION is expanded from...
config/libtool.m4:2486: _LT_AC_LANG_C_CONFIG is expanded from...
config/libtool.m4:2485: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
config/libtool.m4:95: AC_LIBTOOL_SETUP is expanded from...
config/libtool.m4:75: _AC_PROG_LIBTOOL is expanded from...
config/libtool.m4:40: AC_PROG_LIBTOOL is expanded from...
config/lyxinclude.m4:650: LYX_PROG_LIBTOOL is expanded from...
configure.ac:155: the top level
configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): 
suspicious cache-id, must contain _cv_ to be cached
config/libtool.m4:566: AC_LIBTOOL_COMPILER_OPTION is expanded from...
config/libtool.m4:4540: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from...
configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): 
suspicious cache-id, must contain _cv_ to be cached
config/libtool.m4:2631: _LT_AC_LANG_CXX_CONFIG is expanded from...
config/libtool.m4:2630: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from...
config/libtool.m4:1647: _LT_AC_TAGCONFIG is expanded from...
configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_F77,

Re: Cannot compile today's SVN

2008-06-24 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

It happens that I should have added target name here... I wonder why
it worked with GNU make.

Try again.
  

Now, autogen.sh works fine. Thank you!

However, in following build step, compilation fails if *BSD user tries 
to build with BSD make. This problem can be worked around by using gmake 
in the build step, so I don't know whether it should be fixed or only be 
indicated in documentation. The error messages with BSD make in the 
build step is as follows:



===  Building for lyx-svn-1.6svn
make  all-recursive
Making all in config
Making all in development
Making all in intl
Making all in po
make lyx-svn.pot-update
sed -e '/^#/d' remove-potcdate.sin  t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o qt4_l10n.pot 
-t qt4 ../src/frontends/qt4/ui/*.ui
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o 
layouts_l10n.pot -t layouts ../lib/layouts/*.layout 
../lib/layouts/*.inc ../lib/layouts/*.module
python ./lyx_pot.py -b .. -o languages_l10n.pot -t languages 
../lib/languages
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o ui_l10n.pot 
-t ui ../lib/ui/*.ui ../lib/ui/*.inc
python ./lyx_pot.py -b .. -o external_l10n.pot -t external 
../lib/external_templates
python ./lyx_pot.py -b .. -o formats_l10n.pot -t formats 
../lib/configure.py
cat  |  msguniq -o lyx-svn.po  rm -f 


Koji

Re: Cannot compile today's SVN

2008-06-24 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

These messages are very strange. You may want to remove the directory
autom4te.cahe/. 


Even though I delete autom4te.cache, the last line of autogen.sh,

"make -f po/Rules-lyx srcdir=po top_srcdir=."

tries to do

"cat  |  msguniq -o .po && rm -f"

I attach the whole message of autogen.sh as an attached file.


This is very strange, because it is not supposed to activate this
particular rule... What OS are you using? What version of 'make'?


I'm using FreeBSD and it occurs for both 6.3-RELEASE and 7.0-RELEASE.
So, 'make' calls BSD make (Sorry, I couldn't get its version).

Your suggestion hinted me to rewrote the last line of autogen.sh to
"gmake ..." instead of "make ..." to call GNU make, then it finished
configuration correctly, even though I still get the same messages:

config/libtool.m4:3661: _LT_AC_LANG_F77_CONFIG is expanded from...

config/libtool.m4:3660: AC_LIBTOOL_LANG_F77_CONFIG is expanded from...
configure.ac:155: warning: 

AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): suspicious cache-id,
must contain _cv_ to be cached

config/libtool.m4:3761: _LT_AC_LANG_GCJ_CONFIG is expanded from...
config/libtool.m4:3760: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from...


but if I use gmake in the build stage too, it compiled successfully anyway.

Using BSD make in the build stage gets stuck in the build of the po 
directory, because of the same reason as the autogen.sh case:



===>  Building for lyx-svn-1.6svn
make  all-recursive
Making all in config
Making all in development
Making all in intl
Making all in po
make lyx-svn.pot-update
sed -e '/^#/d' remove-potcdate.sin > t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o qt4_l10n.pot -t qt4 
../src/frontends/qt4/ui/*.ui
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o layouts_l10n.pot -t 
layouts ../lib/layouts/*.layout ../lib/layouts/*.inc ../lib/layouts/*.module
python ./lyx_pot.py -b .. -o languages_l10n.pot -t languages ../lib/languages
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o ui_l10n.pot -t ui 
../lib/ui/*.ui ../lib/ui/*.inc
python ./lyx_pot.py -b .. -o external_l10n.pot -t external 
../lib/external_templates
python ./lyx_pot.py -b .. -o formats_l10n.pot -t formats ../lib/configure.py
cat  |  msguniq -o lyx-svn.po && rm -f


If I use gmake in all stages, compile finishes in success, but I'm not 
sure warnings that autogen.sh emit are really harmless or not.


Koji



JMarc




Using automake (GNU automake) 1.9.6
Using autoconf (GNU Autoconf) 2.61
Building macros...
/usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of 
AM_PATH_LINC
  run info '(automake)Extending aclocal'
  or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition of 
AM_PATH_LIBFAME
/usr/local/share/aclocal/gtk.m4:7: warning: underquoted definition of 
AM_PATH_GTK
/usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of 
AM_PATH_GLIB
/usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of 
AM_PATH_AUDIOFILE
/usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of 
AM_PATH_AALIB
configure.ac:55: warning: AC_COMPILE_IFELSE was called before 
AC_USE_SYSTEM_EXTENSIONS
../../lib/autoconf/specific.m4:385: AC_USE_SYSTEM_EXTENSIONS is expanded from...
../../lib/autoconf/specific.m4:451: AC_AIX is expanded from...
configure.ac:55: the top level
configure.ac:55: warning: AC_RUN_IFELSE was called before 
AC_USE_SYSTEM_EXTENSIONS
configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): 
suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1973: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:1993: AC_CACHE_CHECK is expanded from...
config/libtool.m4:609: AC_LIBTOOL_LINKER_OPTION is expanded from...
config/libtool.m4:2486: _LT_AC_LANG_C_CONFIG is expanded from...
config/libtool.m4:2485: AC_LIBTOOL_LANG_C_CONFIG is expanded from...
config/libtool.m4:95: AC_LIBTOOL_SETUP is expanded from...
config/libtool.m4:75: _AC_PROG_LIBTOOL is expanded from...
config/libtool.m4:40: AC_PROG_LIBTOOL is expanded from...
config/lyxinclude.m4:650: LYX_PROG_LIBTOOL is expanded from...
configure.ac:155: the top level
configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): 
suspicious cache-id, must contain _cv_ to be cached
config/libtool.m4:566: AC_LIBTOOL_COMPILER_OPTION is expanded from...
config/libtool.m4:4540: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from...
configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_CXX, ...): 
suspicious cache-id, must contain _cv_ to be cached
config/libtool.m4:2631: _LT_AC_LANG_CXX_CONFIG is expanded from...
config/libtool.m4:2630: AC_LIBTOOL_LANG_CXX_CONFIG is expanded from...
config/libtool.m4:1647: _LT_AC_TAGCONFIG is expanded from...
configure.ac:155: warning:

Re: Cannot compile today's SVN

2008-06-24 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

It happens that I should have added target name here... I wonder why
it worked with GNU make.

Try again.
  

Now, autogen.sh works fine. Thank you!

However, in following build step, compilation fails if *BSD user tries 
to build with BSD make. This problem can be worked around by using gmake 
in the build step, so I don't know whether it should be fixed or only be 
indicated in documentation. The error messages with BSD make in the 
build step is as follows:



===>  Building for lyx-svn-1.6svn
make  all-recursive
Making all in config
Making all in development
Making all in intl
Making all in po
make lyx-svn.pot-update
sed -e '/^#/d' remove-potcdate.sin > t-remove-potcdate.sed
mv t-remove-potcdate.sed remove-potcdate.sed
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o qt4_l10n.pot 
-t qt4 ../src/frontends/qt4/ui/*.ui
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o 
layouts_l10n.pot -t layouts ../lib/layouts/*.layout 
../lib/layouts/*.inc ../lib/layouts/*.module
python ./lyx_pot.py -b .. -o languages_l10n.pot -t languages 
../lib/languages
LC_ALL=C ; export LC_ALL ;  python ./lyx_pot.py -b .. -o ui_l10n.pot 
-t ui ../lib/ui/*.ui ../lib/ui/*.inc
python ./lyx_pot.py -b .. -o external_l10n.pot -t external 
../lib/external_templates
python ./lyx_pot.py -b .. -o formats_l10n.pot -t formats 
../lib/configure.py
cat  |  msguniq -o lyx-svn.po && rm -f 


Koji

Cannot compile today's SVN

2008-06-23 Thread Koji Yokota

Hi,

The newest 1.6svn has become to fail on my system to run autogen.sh at
the stage it builds po/POTFILES.in. It simply becomes silent after the
message:

 config/libtool.m4:3661: _LT_AC_LANG_F77_CONFIG is expanded from...
 config/libtool.m4:3660: AC_LIBTOOL_LANG_F77_CONFIG is expanded from...
 configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): 
 suspicious cache-id, must contain _cv_ to be cached
 config/libtool.m4:3761: _LT_AC_LANG_GCJ_CONFIG is expanded from...
 config/libtool.m4:3760: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from...
 Building configure...
 Building po/POTFILES.in...

It gets stuck at the line in autogen.sh:
 make -s -f po/Rules-lyx srcdir=po top_srcdir=.

If I remove the -s option above, the script says:
 cat  |  msguniq -o .po  rm -f

So, it seems po/Rules-lyx doesn't pick up variable $(DOMAIN) in the lines:

 l10n_pots: qt4_l10n.pot layouts_l10n.pot languages_l10n.pot ui_l10n.pot 
 external_l10n.pot formats_l10n.pot
 cat $^ | \
 msguniq -o $(DOMAIN).po  rm -f  $^

Do you have any idea to fix this?

Thanks,

Koji

Cannot compile today's SVN

2008-06-23 Thread Koji Yokota

Hi,

The newest 1.6svn has become to fail on my system to run autogen.sh at
the stage it builds po/POTFILES.in. It simply becomes silent after the
message:

> config/libtool.m4:3661: _LT_AC_LANG_F77_CONFIG is expanded from...
> config/libtool.m4:3660: AC_LIBTOOL_LANG_F77_CONFIG is expanded from...
> configure.ac:155: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works_GCJ, ...): 
> suspicious cache-id, must contain _cv_ to be cached
> config/libtool.m4:3761: _LT_AC_LANG_GCJ_CONFIG is expanded from...
> config/libtool.m4:3760: AC_LIBTOOL_LANG_GCJ_CONFIG is expanded from...
> Building configure...
> Building po/POTFILES.in...

It gets stuck at the line in autogen.sh:
> make -s -f po/Rules-lyx srcdir=po top_srcdir=.

If I remove the "-s" option above, the script says:
> cat  |  msguniq -o .po && rm -f

So, it seems po/Rules-lyx doesn't pick up variable $(DOMAIN) in the lines:

> l10n_pots: qt4_l10n.pot layouts_l10n.pot languages_l10n.pot ui_l10n.pot 
> external_l10n.pot formats_l10n.pot
> cat $^ | \
> msguniq -o $(DOMAIN).po && rm -f  $^

Do you have any idea to fix this?

Thanks,

Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-06-02 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

Therefore the only solution is chroot. We only
have to work out how it could be used.


chroot normally needs to be done as a root, so I'm stuck :

Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-06-02 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

Therefore the only solution is chroot. We only
have to work out how it could be used.


chroot normally needs to be done as a root, so I'm stuck :<

Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-19 Thread Koji Yokota


Alfredo Braunstein wrote:
 It's more complicated than that, e.g.

 gnuplot plot rm -rf /

I could never imagine gnuplot accepts even such expression :o

 Maybe some solution involving a chroot?

Jean-Marc Lasgouttes wrote:
 The only good solution would be an execution mode of gnuplot that
 disables calls to system. Last time I checked, it did not exist.

For completeness, it seems there is no other workaround. It is really 
sad that we have to give up this feature, as there will be many people 
who are using gnuplot together with lyx or latex. I saw some programs 
like Excel pops up an alert when user tries to open a spreadsheet 
containing macros. Is it too risky to do the same thing? Say,


- Whenever gnuplot.py is called it pops up an alert, saying
  it is exposing the system to some risk (and explain it well)
  and urge user to check the gnuplot code
- gnuplot temporary file is made in a newly created directory
  and gnuplot is executed after chroot'ing there
- gnuplot.py stops executing if user is using it with root
  privileges

I haven't checked the feasibility of the code, but once this is done, at 
least files on the disk will not be modified. But of course, depending 
on the privileges the user has, if malicious code is *carelessly* 
executed, it may be able to do some weired things like shutting down the 
computer or else.


I'm not sure if this level of risk is acceptable or not...

Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-19 Thread Koji Yokota

Alfredo Braunstein wrote:
> It's more complicated than that, e.g.
>
> gnuplot> plot " Maybe some solution involving a chroot?

Jean-Marc Lasgouttes wrote:
> The only good solution would be an execution mode of gnuplot that
> disables calls to system. Last time I checked, it did not exist.

For completeness, it seems there is no other workaround. It is really 
sad that we have to give up this feature, as there will be many people 
who are using gnuplot together with lyx or latex. I saw some programs 
like Excel pops up an alert when user tries to open a spreadsheet 
containing macros. Is it too risky to do the same thing? Say,

- Whenever gnuplot.py is called it pops up an alert, saying
  it is exposing the system to some risk (and explain it well)
  and urge user to check the gnuplot code
- gnuplot temporary file is made in a newly created directory
  and gnuplot is executed after chroot'ing there
- gnuplot.py stops executing if user is using it with root
  privileges

I haven't checked the feasibility of the code, but once this is done, at 
least files on the disk will not be modified. But of course, depending 
on the privileges the user has, if malicious code is *carelessly* 
executed, it may be able to do some weired things like shutting down the 
computer or else.

I'm not sure if this level of risk is acceptable or not...

Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-16 Thread Koji Yokota

if it finds out 
the expression ^\s*system or ^\s*\!, it comments out the related 
lines.


In addition, load function must be skipped because its content is not 
known to gnuplot.py. Also, we must consider the case that multiple 
commands exist in one line.


Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-16 Thread Koji Yokota


Helge Hafting wrote:

Ouch.
Could this be solved by having LyX refusing to use gnuplot file
containing the system command? Or is it much more complicated?

Helge Hafting



Yeah right... If only shell execution can be a security hall (is this 
right?), we can comment out the related lines from the source file by 
the python script. Anyway the script scans over the source file, doing 
so is rather straightforward.


So, how about modifying the gnuplot.py in a way that, if it finds out 
the expression ^\s*system or ^\s*\!, it comments out the related 
lines. It may break the consistency of the source, therefore user may 
not obtain the correct output, it may be more flexible than stopping the 
execution of gnuplot itself. We simply warn users in the help 
description, that the gnuplot source may not work correctly if system 
or ! lines are included as they will be skipped.


Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-16 Thread Koji Yokota

if it finds out 
the expression "^\s*system" or "^\s*\!", it comments out the related 
lines.


In addition, "load" function must be skipped because its content is not 
known to gnuplot.py. Also, we must consider the case that multiple 
commands exist in one line.


Koji

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-16 Thread Koji Yokota


Helge Hafting wrote:

Ouch.
Could this be solved by having LyX refusing to use gnuplot file
containing the "system" command? Or is it much more complicated?

Helge Hafting



Yeah right... If only shell execution can be a security hall (is this 
right?), we can comment out the related lines from the source file by 
the python script. Anyway the script scans over the source file, doing 
so is rather straightforward.


So, how about modifying the gnuplot.py in a way that, if it finds out 
the expression "^\s*system" or "^\s*\!", it comments out the related 
lines. It may break the consistency of the source, therefore user may 
not obtain the correct output, it may be more flexible than stopping the 
execution of gnuplot itself. We simply warn users in the help 
description, that the gnuplot source may not work correctly if "system" 
or "!" lines are included as they will be skipped.


Koji

[PATCH] Proposal for a new external template: gnuplot

2008-05-15 Thread Koji Yokota

Hi all,

The attached is a proposal for a new external template for gnuplot, a
graph plotting program. I have been using it for my personal use for a
while, but I thought it may be better included in the main body as it is
convenient.

With this template, users can directly edit the gnuplot source code from
lyx, whereas its consequent graphics is automatically included in outputs.

Although the attached script can generate other graphics formats as
well, in the purpose of external template, it is only used for
generation of an EPS graphics file from a gnuplot source code. If
necessary, users can add additional converters for each graphics format.

I think it should be better checked by professionals, but I hope it is
useful.

How do you think?

Best regards,

Koji

--- lib/configure.py.orig   2008-05-06 22:20:27.0 +0900
+++ lib/configure.py2008-05-15 01:37:48.0 +0900
@@ -244,6 +244,10 @@
 checkViewer('a FEN viewer and editor', ['xboard -lpf $$i -mode 
EditPosition'],
 rc_entry = [r'\Format fenfen FEN 
%%%%'])
 #
+checkViewer('a Gnuplot viewer and editor', ['emacs', 'emcws', 'xemacs', 
'gvim', 'kedit', 'kwrite', \
+'kate', 'nedit', 'gedit', 'notepad'],
+rc_entry = [r'\Format gnuplotgnuplot Gnuplot 
%%%%vector'])
+#
 path, iv = checkViewer('a raster image viewer', ['xv', 'kview', 
'gimp-remote', 'gimp'])
 path, ie = checkViewer('a raster image editor', ['gimp-remote', 'gimp'])
 addToRC(r'''\Format bmpbmp BMP %s  
%s
@@ -499,6 +503,10 @@
 checkProg('a Noteedit - LilyPond converter', ['noteedit --export-lilypond 
$$i'],
 rc_entry = [ r'\converter noteedit   lilypond   %%   ', ''])
 #
+checkProg('a Gnuplot - EPS converter', ['gnuplot'],
+rc_entry = [ r'\converter gnuplotepspython -tt 
$$s/scripts/gnuplot.py $$i $$o', ''])
+#
+#
 # FIXME: no rc_entry? comment it out
 # checkProg('Image converter', ['convert $$i $$o'])
 #
--- lib/external_templates.orig 2008-05-15 01:43:46.0 +0900
+++ lib/external_templates  2008-05-15 01:44:46.0 +0900
@@ -314,3 +314,58 @@
UpdateResult $$Tempname
FormatEnd
 TemplateEnd
+
+Template gnuplot
+GuiName gnuplot: $$AbsOrRelPathParent$$Basename
+HelpText
+Create plots and graphics with Gnuplot
+   
+   'gnuplot' binary must be found in path for it
+   to work correctly.
+   If you use emacs as an editor, you may want
+   to use it in the gnuplot mode.
+HelpTextEnd
+InputFormat gnuplot
+FileFilter *.{gnuplot,plt,plot,gnu}
+AutomaticProduction true
+Transform Rotate
+Transform Resize
+Transform Clip
+Transform Extra
+Format LaTeX
+Requirement graphicx
+TransformOption Rotate RotationLatexOption
+TransformOption Resize ResizeLatexOption
+TransformOption Clip   ClipLatexOption
+TransformOption Extra  ExtraOption
+Option Arg [$$Extra,$$Rotate,$$Resize,$$Clip]
+Product 
\\includegraphics$$Arg{$$AbsOrRelPathMaster$$Basename.e
+ps}
+UpdateFormat eps
+UpdateResult $$AbsPath$$Basename.eps
+ReferencedFile latex $$AbsOrRelPathMaster$$Basename.eps
+ReferencedFile dvi   $$AbsPath$$Basename.eps
+FormatEnd
+Format PDFLaTeX
+Requirement graphicx
+TransformOption Rotate RotationLatexOption
+TransformOption Resize ResizeLatexOption
+TransformOption Clip   ClipLatexOption
+TransformOption Extra  ExtraOption
+Option Arg [$$Extra,$$Rotate,$$Resize,$$Clip]
+Product 
\\includegraphics$$Arg{$$AbsOrRelPathMaster$$Basename.e
+ps}
+UpdateFormat eps
+UpdateResult $$AbsPath$$Basename.eps
+ReferencedFile pdflatex $$AbsOrRelPathMaster$$Basename.eps
+FormatEnd
+Format Ascii
+Product [gnuplot: $$FName]
+FormatEnd
+Format DocBook
+Product [gnuplot: $$FName]
+FormatEnd
+Format LinuxDoc
+Product [gnuplot: $$FName]
+FormatEnd
+TemplateEnd
--- lib/scripts/gnuplot.py.orig 2008-05-15 01:46:32.0 +0900
+++ lib/scripts/gnuplot.py  2008-05-11 03:11:09.0 +0900
@@ -0,0 +1,123 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+# file gnuplot.py
+# This file is part of LyX, the document processor.
+# Licence details can be found in the file COPYING.
+
+# \author Koji Yokota
+
+# Full author contact details are available in file CREDITS.
+
+# This script creates a graphic file from a GnuPlot source file

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-15 Thread Koji Yokota


José Matos wrote:
 Historically the problem with gnuplot was the fact that is has not any
 sandboxing scheme.

 So it should be possible to send you a gnuplot file that erases your 
home area

 if you run gnuplot over it.

 Example (this is specific to unix/linux but it can be adapted to other
 systems):

 system(rm -rf ~)

I see. It really should be used at users' own risk.

[EMAIL PROTECTED] wrote:
How about the following suggestion. Koji can upload the template to the 
wiki and create a wiki page that describes how to use it. The page 
should also warn of the dangerous case described above.


That's a good idea. If there are no other problems, I can do so.

Koji

[PATCH] Proposal for a new external template: gnuplot

2008-05-15 Thread Koji Yokota

Hi all,

The attached is a proposal for a new external template for gnuplot, a
graph plotting program. I have been using it for my personal use for a
while, but I thought it may be better included in the main body as it is
convenient.

With this template, users can directly edit the gnuplot source code from
lyx, whereas its consequent graphics is automatically included in outputs.

Although the attached script can generate other graphics formats as
well, in the purpose of external template, it is only used for
generation of an EPS graphics file from a gnuplot source code. If
necessary, users can add additional converters for each graphics format.

I think it should be better checked by professionals, but I hope it is
useful.

How do you think?

Best regards,

Koji

--- lib/configure.py.orig   2008-05-06 22:20:27.0 +0900
+++ lib/configure.py2008-05-15 01:37:48.0 +0900
@@ -244,6 +244,10 @@
 checkViewer('a FEN viewer and editor', ['xboard -lpf $$i -mode 
EditPosition'],
 rc_entry = [r'\Format fenfen FEN"" 
"%%""%%"""'])
 #
+checkViewer('a Gnuplot viewer and editor', ['emacs', 'emcws', 'xemacs', 
'gvim', 'kedit', 'kwrite', \
+'kate', 'nedit', 'gedit', 'notepad'],
+rc_entry = [r'\Format gnuplotgnuplot Gnuplot"" 
"%%""%%""vector"'])
+#
 path, iv = checkViewer('a raster image viewer', ['xv', 'kview', 
'gimp-remote', 'gimp'])
 path, ie = checkViewer('a raster image editor', ['gimp-remote', 'gimp'])
 addToRC(r'''\Format bmpbmp BMP"" "%s"  
"%s"""
@@ -499,6 +503,10 @@
 checkProg('a Noteedit -> LilyPond converter', ['noteedit --export-lilypond 
$$i'],
 rc_entry = [ r'\converter noteedit   lilypond   "%%"   ""', ''])
 #
+checkProg('a Gnuplot -> EPS converter', ['gnuplot'],
+rc_entry = [ r'\converter gnuploteps"python -tt 
$$s/scripts/gnuplot.py $$i $$o"""', ''])
+#
+#
 # FIXME: no rc_entry? comment it out
 # checkProg('Image converter', ['convert $$i $$o'])
 #
--- lib/external_templates.orig 2008-05-15 01:43:46.0 +0900
+++ lib/external_templates  2008-05-15 01:44:46.0 +0900
@@ -314,3 +314,58 @@
UpdateResult "$$Tempname"
FormatEnd
 TemplateEnd
+
+Template gnuplot
+GuiName "gnuplot: $$AbsOrRelPathParent$$Basename"
+HelpText
+Create plots and graphics with Gnuplot
+   
+   'gnuplot' binary must be found in path for it
+   to work correctly.
+   If you use emacs as an editor, you may want
+   to use it in the gnuplot mode.
+HelpTextEnd
+InputFormat gnuplot
+FileFilter "*.{gnuplot,plt,plot,gnu}"
+AutomaticProduction true
+Transform Rotate
+Transform Resize
+Transform Clip
+Transform Extra
+Format LaTeX
+Requirement "graphicx"
+TransformOption Rotate RotationLatexOption
+TransformOption Resize ResizeLatexOption
+TransformOption Clip   ClipLatexOption
+TransformOption Extra  ExtraOption
+Option Arg "[$$Extra,$$Rotate,$$Resize,$$Clip]"
+Product 
"\\includegraphics$$Arg{$$AbsOrRelPathMaster$$Basename.e
+ps}"
+UpdateFormat eps
+UpdateResult "$$AbsPath$$Basename.eps"
+ReferencedFile latex "$$AbsOrRelPathMaster$$Basename.eps"
+ReferencedFile dvi   "$$AbsPath$$Basename.eps"
+FormatEnd
+Format PDFLaTeX
+Requirement "graphicx"
+TransformOption Rotate RotationLatexOption
+TransformOption Resize ResizeLatexOption
+TransformOption Clip   ClipLatexOption
+TransformOption Extra  ExtraOption
+Option Arg "[$$Extra,$$Rotate,$$Resize,$$Clip]"
+Product 
"\\includegraphics$$Arg{$$AbsOrRelPathMaster$$Basename.e
+ps}"
+UpdateFormat eps
+UpdateResult "$$AbsPath$$Basename.eps"
+ReferencedFile pdflatex "$$AbsOrRelPathMaster$$Basename.eps"
+FormatEnd
+Format Ascii
+Product "[gnuplot: $$FName]"
+FormatEnd
+Format DocBook
+Product "[gnuplot: $$FName]"
+FormatEnd
+Format LinuxDoc
+Product "[gnuplot: $$FName]"
+FormatEnd
+TemplateEnd
--- lib/scripts/gnuplot.py.orig 2008-05-15 01:46:32.0 +0900
+++ lib/scri

Re: [PATCH] Proposal for a new external template: gnuplot

2008-05-15 Thread Koji Yokota

José Matos wrote:
> Historically the problem with gnuplot was the fact that is has not any
> sandboxing scheme.
>
> So it should be possible to send you a gnuplot file that erases your 
home area

> if you run gnuplot over it.
>
> Example (this is specific to unix/linux but it can be adapted to other
> systems):
>
> system("rm -rf ~")

I see. It really should be used at users' own risk.

[EMAIL PROTECTED] wrote:
How about the following suggestion. Koji can upload the template to the 
wiki and create a wiki page that describes how to use it. The page 
should also warn of the dangerous case described above.

That's a good idea. If there are no other problems, I can do so.

Koji

Backup file behaviour

2008-04-09 Thread Koji Yokota

Hi,

Currently, after a crash of LyX, a backup file will be deleted
immediately after a user chooses to load an original file instead of
backup. Can this behaviour be changed to leave both original and backup
files untouched at least until a user explicitly makes saving?

A user must examine both original and backup file if he is not sure
which is correct. But currently, he can never open the original file
(once he does, data in backup goes away).

Only way to escape from this situation is to use external editor or
viewer to examine them at this moment.

Koji

Backup file behaviour

2008-04-09 Thread Koji Yokota

Hi,

Currently, after a crash of LyX, a backup file will be deleted
immediately after a user chooses to load an original file instead of
backup. Can this behaviour be changed to leave both original and backup
files untouched at least until a user explicitly makes saving?

A user must examine both original and backup file if he is not sure
which is correct. But currently, he can never open the original file
(once he does, data in backup goes away).

Only way to escape from this situation is to use external editor or
viewer to examine them at this moment.

Koji

Re: [patch] fix language switch issue

2008-01-26 Thread Koji Yokota


Jürgen Spitzmüller wrote:
But this will fail for sections and if the title contains for instance french 
and Japanese.


You're right.


Here's my test document and the resulting PDF. Looks correct to me.
The ERT looks more complicated than what we'll need in the output finally.


It worked fine for me, too.

Koji

Re: [patch] fix language switch issue

2008-01-26 Thread Koji Yokota


Jürgen Spitzmüller wrote:
But this will fail for sections and if the title contains for instance french 
and Japanese.


You're right.


Here's my test document and the resulting PDF. Looks correct to me.
The ERT looks more complicated than what we'll need in the output finally.


It worked fine for me, too.

Koji

Re: [patch] fix language switch issue

2008-01-25 Thread Koji Yokota

Although I haven't extensively tested, the header issue of AMS seems to 
be resolved just by enclosing \maketitle by \begin{CJK} and \end{CJK} 
when the title includes CJK characters.


So a document should include parts such as

\title{Header problem in second page with \begin{CJK}{EUC-JP}{}日本語\ 
end{CJK}}


and

\begin{CJK}{EUC-JP}{}%
\maketitle
\end{CJK}

Koji

\batchmode
\makeatletter
[EMAIL PROTECTED]/home/uji/Desktop//}}
\makeatother
\documentclass[a4paper,oneside,english]{amsart}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{CJK}

\makeatletter
%% Textclass specific LaTeX commands.
\numberwithin{equation}{section} %% Comment out for sequentially-numbered
\numberwithin{figure}{section} %% Comment out for sequentially-numbered

\usepackage{babel}
\makeatother

\begin{document}
\selectlanguage{english}

\title{Header problem in second page with \begin{CJK}{EUC-JP}{}ÆüËÜ¸ì\end{CJK}}

\begin{CJK}{EUC-JP}{}%
\maketitle
\end{CJK}
Japanese text

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text 

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-pageMore than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-pageMore than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text

Re: [patch] fix language switch issue

2008-01-25 Thread Koji Yokota

Although I haven't extensively tested, the header issue of AMS seems to 
be resolved just by enclosing \maketitle by \begin{CJK} and \end{CJK} 
when the title includes CJK characters.


So a document should include parts such as

\title{Header problem in second page with \begin{CJK}{EUC-JP}{}日本語\ 
end{CJK}}


and

\begin{CJK}{EUC-JP}{}%
\maketitle
\end{CJK}

Koji

\batchmode
\makeatletter
[EMAIL PROTECTED]/home/uji/Desktop//}}
\makeatother
\documentclass[a4paper,oneside,english]{amsart}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{CJK}

\makeatletter
%% Textclass specific LaTeX commands.
\numberwithin{equation}{section} %% Comment out for sequentially-numbered
\numberwithin{figure}{section} %% Comment out for sequentially-numbered

\usepackage{babel}
\makeatother

\begin{document}
\selectlanguage{english}

\title{Header problem in second page with \begin{CJK}{EUC-JP}{}ÆüËÜ¸ì\end{CJK}}

\begin{CJK}{EUC-JP}{}%
\maketitle
\end{CJK}
Japanese text

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text 

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-pageMore than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-pageMore than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page

More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text More than one-page
text More than one-page text More than one-page text

Re: [patch] fix language switch issue

2008-01-24 Thread Koji Yokota


Juergen Spitzmueller wrote:
 In which respect? (I'm illiterate when it comes to kana script, but the
 output at least *looks* correct to me).

Sorry, it seems I made a mistake again (I have several versions of lyx 
installed on different machines, which causes a human error :). I 
retried with your latest patch and outcome is slightly different from 
the one I reported yesterday.


I tested [EMAIL PROTECTED], [EMAIL PROTECTED] and their 
modified versions changed to article style and their title lines changed 
to a section.


For the case of [EMAIL PROTECTED] with modification you suggested

 \title{Header problem in second page with
 \begin{CJK}{EUC-JP}{}???\end{CJK}}


and in sections:

\section{Header problem in second page with \protect\begin{CJK}{EUC-JP}{}??
\protect\end{CJK}}


Yes, output of the first page is fine. But the header of the second page 
shows  at the place of Japanese characters for amsart (it worked 
fine for article).


At my place, [EMAIL PROTECTED] with \clearpage at the end 
worked fine for both amsart and article (and no extra page at the end). 
The difference from your case may come from the version of the CJK 
package (or may not). My CJK is version 4.7.0 with teTeX-3.0.


However, we cannot adopt this because even though \clearpage doesn't 
create additional page if it comes at the end of a document, it does 
break page in the middle of the document.


Koji

Re: [patch] fix language switch issue

2008-01-24 Thread Koji Yokota

Juergen Spitzmueller wrote:
> In which respect? (I'm illiterate when it comes to kana script, but the
> output at least *looks* correct to me).

Sorry, it seems I made a mistake again (I have several versions of lyx 
installed on different machines, which causes a human error :<). I 
retried with your latest patch and outcome is slightly different from 
the one I reported yesterday.

I tested "[EMAIL PROTECTED]", "[EMAIL PROTECTED]" and their 
modified versions changed to article style and their title lines changed 
to a section.

For the case of "[EMAIL PROTECTED]" with modification you suggested

> \title{Header problem in second page with
> \begin{CJK}{EUC-JP}{}???\end{CJK}}
>

and in sections:

\section{Header problem in second page with \protect\begin{CJK}{EUC-JP}{}??
\protect\end{CJK}}

Yes, output of the first page is fine. But the header of the second page 
shows """ at the place of Japanese characters for "amsart" (it worked 
fine for "article").

At my place, "[EMAIL PROTECTED]" with \clearpage at the end 
worked fine for both amsart and article (and no extra page at the end). 
The difference from your case may come from the version of the CJK 
package (or may not). My CJK is version 4.7.0 with teTeX-3.0.

However, we cannot adopt this because even though \clearpage doesn't 
create additional page if it comes at the end of a document, it does 
break page in the middle of the document.

Koji

Re: [patch] fix language switch issue

2008-01-23 Thread Koji Yokota


Juergen Spitzmueller wrote:

But this inserts a pagebreak, right? I don't think it's a good idea to enter
pagebreaks at each language switch (moreover, the fix does not work for
me).


I also found that page break actually doesn't solve the problem 
(previously, I succeeded because I mistakenly used platex instead of 
latex as a compiler). It compiles somehow, but output is wrong. I 
included *three* Japanese characters in title, but output contains only 
two with totally different characters.



However, it seems that the following works:

\title{Header problem in second page with \begin{CJK}{EUC-JP}{}???\end{CJK}}


Yes, this makes compilation finish, but output is again not correct.


Anyway, let's put in the fix first and address this problem afterwards.
Else, the patch gets too complicated. 


Yes, I agree. This problem may be related to only AMS styles and can be 
very complicated. By changing the style to normal article, the problem 
disappears. Also, I found some CJK users were arguing about the same 
problem on the net. Unfortunately, I couldn't find a solution, but only 
suggestion I could find was don't use AMS styles with CJK (sigh).


Koji

Re: [patch] fix language switch issue

2008-01-23 Thread Koji Yokota


Juergen Spitzmueller wrote:

But this inserts a pagebreak, right? I don't think it's a good idea to enter
pagebreaks at each language switch (moreover, the fix does not work for
me).


I also found that page break actually doesn't solve the problem 
(previously, I succeeded because I mistakenly used platex instead of 
latex as a compiler). It compiles somehow, but output is wrong. I 
included *three* Japanese characters in title, but output contains only 
two with totally different characters.



However, it seems that the following works:

\title{Header problem in second page with \begin{CJK}{EUC-JP}{}???\end{CJK}}


Yes, this makes compilation finish, but output is again not correct.


Anyway, let's put in the fix first and address this problem afterwards.
Else, the patch gets too complicated. 


Yes, I agree. This problem may be related to only AMS styles and can be 
very complicated. By changing the style to normal article, the problem 
disappears. Also, I found some CJK users were arguing about the same 
problem on the net. Unfortunately, I couldn't find a solution, but only 
suggestion I could find was "don't use AMS styles with CJK" (sigh).


Koji

Re: [patch] fix language switch issue

2008-01-22 Thread Koji Yokota


Jürgen Spitzmüller wrote:
Please try the attached patch, and again, test carefully also with you other 
test cases.


The patch seems to have solved the last case.

However, I encountered another case which we need consider and which is 
probably a (known) bug of the cjk package.


When a title includes a CJK character and it is quoted in a header of a 
page, it causes a compilation error:


! Argument of [EMAIL PROTECTED] has an extra }

It can be remedied simply by inserting \clearpage or \cleardoublepage (a 
two-column page case) before \end{CJK} as shown in the attached examples.


Documentation of the CJK package (CJK.txt) says:

o   If you get the error message: `\CJK... undefined' or other `...
undefined ...' messages and you can't find an error, try
inserting \newpage, \clearpage, or \cleardoublepage (the latter
for two-column printing) before saying \end{CJK} or \end{CJK*}.
This can happen if LaTeX 2e writes headers, footers, or index
entries (both \index and \printindex) of a page containing CJK
characters after closing the CJK environment.

In case of footnotes with CJK characters which are split across
pages, you have to close the CJK environment on the page on
which the particular footnote ends (probably preceded by a
\newpage command).

So, it may be better insert these clearing commands when the CJK package 
is used.


Koji


CJK@XX_problem.lyx
Description: application/lyx


CJK@XX_problem_solved.lyx
Description: application/lyx

Re: Japanese splash file

2008-01-22 Thread Koji Yokota


Pavel Sanda さんは書きました:

I translated the splash file for Japanese. Could you please add them as
lib/examples/ja/splash.lyx?


its in.
pavel



There seems to be a typo in lib/Makefile.am. Could you fix it as 
attached patches?


Koji
--- lib/Makefile.am.orig2008-01-23 00:26:22.0 +0900
+++ lib/Makefile.am 2008-01-23 05:01:45.0 +0900
@@ -148,7 +148,7 @@
examples/it/splash.lyx
 
 jaexamplesdir = $(pkgdatadir)/examples/ja
-dist_itexamples_DATA = \
+dist_jaexamples_DATA = \
examples/ja/splash.lyx
 
 nlexamplesdir = $(pkgdatadir)/examples/nl
--- lib/Makefile.am.orig2008-01-23 01:01:49.0 +0900
+++ lib/Makefile.am 2008-01-23 05:04:31.0 +0900
@@ -143,7 +143,7 @@
examples/it/splash.lyx

 jaexamplesdir = $(pkgdatadir)/examples/ja
-dist_itexamples_DATA = \
+dist_jaexamples_DATA = \
examples/ja/splash.lyx
 
 nlexamplesdir = $(pkgdatadir)/examples/nl

Re: [patch] fix language switch issue

2008-01-22 Thread Koji Yokota


Jürgen Spitzmüller wrote:
Please try the attached patch, and again, test carefully also with you other 
test cases.


The patch seems to have solved the last case.

However, I encountered another case which we need consider and which is 
probably a (known) bug of the cjk package.


When a title includes a CJK character and it is quoted in a header of a 
page, it causes a compilation error:


! Argument of [EMAIL PROTECTED] has an extra }

It can be remedied simply by inserting \clearpage or \cleardoublepage (a 
two-column page case) before \end{CJK} as shown in the attached examples.


Documentation of the CJK package (CJK.txt) says:

o   If you get the error message: `\CJK... undefined' or other `...
undefined ...' messages and you can't find an error, try
inserting \newpage, \clearpage, or \cleardoublepage (the latter
for two-column printing) before saying \end{CJK} or \end{CJK*}.
This can happen if LaTeX 2e writes headers, footers, or index
entries (both \index and \printindex) of a page containing CJK
characters after closing the CJK environment.

In case of footnotes with CJK characters which are split across
pages, you have to close the CJK environment on the page on
which the particular footnote ends (probably preceded by a
\newpage command).

So, it may be better insert these clearing commands when the CJK package 
is used.


Koji


CJK@XX_problem.lyx
Description: application/lyx


CJK@XX_problem_solved.lyx
Description: application/lyx

Re: Japanese splash file

2008-01-22 Thread Koji Yokota


Pavel Sanda さんは書きました:

I translated the splash file for Japanese. Could you please add them as
lib/examples/ja/splash.lyx?


its in.
pavel



There seems to be a typo in lib/Makefile.am. Could you fix it as 
attached patches?


Koji
--- lib/Makefile.am.orig2008-01-23 00:26:22.0 +0900
+++ lib/Makefile.am 2008-01-23 05:01:45.0 +0900
@@ -148,7 +148,7 @@
examples/it/splash.lyx
 
 jaexamplesdir = $(pkgdatadir)/examples/ja
-dist_itexamples_DATA = \
+dist_jaexamples_DATA = \
examples/ja/splash.lyx
 
 nlexamplesdir = $(pkgdatadir)/examples/nl
--- lib/Makefile.am.orig2008-01-23 01:01:49.0 +0900
+++ lib/Makefile.am 2008-01-23 05:04:31.0 +0900
@@ -143,7 +143,7 @@
examples/it/splash.lyx

 jaexamplesdir = $(pkgdatadir)/examples/ja
-dist_itexamples_DATA = \
+dist_jaexamples_DATA = \
examples/ja/splash.lyx
 
 nlexamplesdir = $(pkgdatadir)/examples/nl

Re: [patch] fix language switch issue

2008-01-19 Thread Koji Yokota


Jürgen,

Is the attached case reproducible? I tested with 1.5.4svn. There is 
inconsistency in closing bracing brackets of \title{} and 
\begin{CJK}-\end{CJK}.


Koji


testcase.lyx
Description: application/lyx
\batchmode
\makeatletter
[EMAIL PROTECTED]/usr/home/uji//}}
\makeatother
\documentclass[english]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{CJK}

\makeatletter
\usepackage{babel}
\makeatother

\begin{document}
\selectlanguage{english}

\title{\begin{CJK}{EUC-JP}{}Japanese title}

\maketitle
Japanese text
\end{CJK}

\end{document}

Japanese splash file

2008-01-19 Thread Koji Yokota

I translated the splash file for Japanese. Could you please add them as
lib/examples/ja/splash.lyx?

In attached files, splash.lyx is for 1.6svn and splash.lyx15 is for
1.5svn (please rename to splash.lyx).

Thank you,

Koji


splash.lyx
Description: application/lyx
#LyX 1.5.4svn created this file. For more info see http://www.lyx.org/
\lyxformat 276
\begin_document
\begin_header
\textclass article
\language japanese
\inputencoding default
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 0
\use_esint 0
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\author  
\author  
\end_header

\begin_body

\begin_layout Title
LyXã¸ããããï¼
\end_layout

\begin_layout Section*
LyXãä½¿ãããã«æåã«ç¥ã£ã¦ããã¹ããã¨ãã
\end_layout

\begin_layout Enumerate
LyXã¯ãã°ãããåæ±èª¬ææ¸ç¾¤ãåæ¢±ãã¦ãã¾ããâââãããä½¿ã£ã¦ãã ããï¼ã¾ã
\family sans
ãã«ã(
\bar under
H
\bar default
)\SpecialChar \menuseparator
LyXã®ç´¹ä»(
\bar under
I
\bar default
)ãé¸ãã§ãã ãããããã¯ãå
\family default
åæ±
\family sans
èª¬ææ¸ã®ãããã¦ç°¡åãªç´¹ä»ããã¦ãã¾ãããã®å¾ããã«ã(
\bar under
H
\bar default
)\SpecialChar \menuseparator
ãã¥ã¼ããªã¢ã«(
\bar under
T
\bar default
)
\family default
ãèªãã§ãLyXã®ä½¿ãæ¹ãå¦ãã§ãã ããã
\end_layout

\begin_layout Enumerate
LyXã¯ãããããããææ¸ããã»ããµãã¨å¼ã¶ã¨ããã®ãã®ã§ãããã¶ã¤ã³ã¨ãã¦ãéå¸¸ã®ã¯ã¼ãããã»ããµã¨ã¯éãã¾ãâââææ¸ãæ¸ããã¨ãç°¡åã«ããã®ã§ãããããã
éãã¯ãããã§ãã®ã§ãæãããã¨ã¯ããã¾ãããåæ±èª¬ææ¸ãèªãã°ããã¹ã¦ããããã«ãªãã§ãããã
\begin_inset Foot
status collapsed

\begin_layout Standard
åæ±èª¬ææ¸ãèªãã§ãã ããã¨ããè¨ãã¾ããã£ãã
\end_layout

\end_inset


\end_layout

\begin_layout Enumerate
LyXã®åºåã¯ç´ æ´ãããè¦æ ãããã¾ãï¼ãè¦§ã«ãªããããã°ããã£ããã¾
\family sans
è¡¨ç¤º(
\bar under
V
\bar default
)\SpecialChar \menuseparator

\bar under
D
\bar default
VI ãé¸ãã§ãã ããã
\end_layout

\begin_layout Enumerate
ãªãã¨ãã£ã¦ããLyXã¯ãï¼ã»ã¨ãã©ï¼å¨ã¦ã®LaTeXã®æ©è½ãå®ç¾ãããã¨ãã§ãã¾ããããããããããLyXã¯LaTeXãã¡ã¤ã«ãã¤ã³ãã¼ããããã¨ãã§ãã¾ãã
çç·´ããLaTeXã¦ã¼ã¶ã¼ã®æ¹ãã¯ããã¥ã¼ããªã¢ã«ã®ä»ã®é¨åã¯ãã£ã¨é£ã°ãèªã¿ãã¦ããLaTeXã¦ã¼ã¶ã¼ã®ããã®LyXãã¨ããç« ãèªãã§ãã ãããï¼ãã®ä»ã®æ¹ã
ã¸ï¼LyXãä½¿ãã®ã«LaTeXãç¥ã£ã¦ããå¿è¦ã¯ããã¾ããã®ã§ããå®å¿ãã ãããï¼
\end_layout

\begin_layout Enumerate
LyXã¯ãè±èªä»¥å¤ã®è¨èªãèªã¿æ¸ãããæ¹ã«åããæ©è½ãããããåãã¦ãã¾ããããã«å ãã¦ããã¼ã®å²ãå½ã¦ããã¼ã«ãã¼ãããã®ä»å¤ãã®ç¹å¾´ããããã¸ãèªç±ã«è¨å®å¯
è½ã§ããè©³ããã¯ã
\family sans
ãã«ã(
\bar under
H
\bar default
)\SpecialChar \menuseparator
ã«ã¹ã¿ãã¤ãº(
\bar under
C
\bar default
)
\family default
ãè¦ã¦ãã ããã
\end_layout

\begin_layout Enumerate
LyXã®ãã¼ã ãã¼ã¸ã¯ã
\family typewriter

\begin_inset LatexCommand url
target http://www.lyx.org/;

\end_inset


\family default
ã«ããã¾ããLyXã®æå ±ãå¾ãããLyXã®ã¡ã¼ãªã³ã°ãªã¹ãã«å å¥ããããLyXã®ã°ã©ãã£ã«ã«ã»ãã¢ã¼ãè¦ã¦ã¿ããããã¾ãã¾ãªãã¨ãã§ãã¾ãã
\end_layout

\end_body
\end_document

Re: [patch] fix language switch issue

2008-01-19 Thread Koji Yokota


Jürgen,

Is the attached case reproducible? I tested with 1.5.4svn. There is 
inconsistency in closing bracing brackets of \title{} and 
\begin{CJK}-\end{CJK}.


Koji


testcase.lyx
Description: application/lyx
\batchmode
\makeatletter
[EMAIL PROTECTED]/usr/home/uji//}}
\makeatother
\documentclass[english]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{CJK}

\makeatletter
\usepackage{babel}
\makeatother

\begin{document}
\selectlanguage{english}

\title{\begin{CJK}{EUC-JP}{}Japanese title}

\maketitle
Japanese text
\end{CJK}

\end{document}

Japanese splash file

2008-01-19 Thread Koji Yokota

I translated the splash file for Japanese. Could you please add them as
lib/examples/ja/splash.lyx?

In attached files, splash.lyx is for 1.6svn and splash.lyx15 is for
1.5svn (please rename to splash.lyx).

Thank you,

Koji


splash.lyx
Description: application/lyx
#LyX 1.5.4svn created this file. For more info see http://www.lyx.org/
\lyxformat 276
\begin_document
\begin_header
\textclass article
\language japanese
\inputencoding default
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 0
\use_esint 0
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\author "" 
\author "" 
\end_header

\begin_body

\begin_layout Title
LyXã¸ããããï¼
\end_layout

\begin_layout Section*
LyXãä½¿ãããã«æåã«ç¥ã£ã¦ããã¹ããã¨ãã
\end_layout

\begin_layout Enumerate
LyXã¯ãã°ãããåæ±èª¬ææ¸ç¾¤ãåæ¢±ãã¦ãã¾ããâââãããä½¿ã£ã¦ãã ããï¼ã¾ã
\family sans
ãã«ã(
\bar under
H
\bar default
)\SpecialChar \menuseparator
LyXã®ç´¹ä»(
\bar under
I
\bar default
)ãé¸ãã§ãã ãããããã¯ãå
\family default
åæ±
\family sans
èª¬ææ¸ã®ãããã¦ç°¡åãªç´¹ä»ããã¦ãã¾ãããã®å¾ããã«ã(
\bar under
H
\bar default
)\SpecialChar \menuseparator
ãã¥ã¼ããªã¢ã«(
\bar under
T
\bar default
)
\family default
ãèªãã§ãLyXã®ä½¿ãæ¹ãå¦ãã§ãã ããã
\end_layout

\begin_layout Enumerate
LyXã¯ãããããããææ¸ããã»ããµãã¨å¼ã¶ã¨ããã®ãã®ã§ãããã¶ã¤ã³ã¨ãã¦ãéå¸¸ã®ã¯ã¼ãããã»ããµã¨ã¯éãã¾ãâââææ¸ãæ¸ããã¨ãç°¡åã«ããã®ã§ãããããã
éãã¯ãããã§ãã®ã§ãæãããã¨ã¯ããã¾ãããåæ±èª¬ææ¸ãèªãã°ããã¹ã¦ããããã«ãªãã§ãããã
\begin_inset Foot
status collapsed

\begin_layout Standard
åæ±èª¬ææ¸ãèªãã§ãã ããã¨ããè¨ãã¾ããã£ãã
\end_layout

\end_inset


\end_layout

\begin_layout Enumerate
LyXã®åºåã¯ç´ æ´ãããè¦æ ãããã¾ãï¼ãè¦§ã«ãªããããã°ããã£ããã¾
\family sans
è¡¨ç¤º(
\bar under
V
\bar default
)\SpecialChar \menuseparator

\bar under
D
\bar default
VI ãé¸ãã§ãã ããã
\end_layout

\begin_layout Enumerate
ãªãã¨ãã£ã¦ããLyXã¯ãï¼ã»ã¨ãã©ï¼å¨ã¦ã®LaTeXã®æ©è½ãå®ç¾ãããã¨ãã§ãã¾ããããããããããLyXã¯LaTeXãã¡ã¤ã«ãã¤ã³ãã¼ããããã¨ãã§ãã¾ãã
çç·´ããLaTeXã¦ã¼ã¶ã¼ã®æ¹ãã¯ããã¥ã¼ããªã¢ã«ã®ä»ã®é¨åã¯ãã£ã¨é£ã°ãèªã¿ãã¦ããLaTeXã¦ã¼ã¶ã¼ã®ããã®LyXãã¨ããç« ãèªãã§ãã ãããï¼ãã®ä»ã®æ¹ã
ã¸ï¼LyXãä½¿ãã®ã«LaTeXãç¥ã£ã¦ããå¿è¦ã¯ããã¾ããã®ã§ããå®å¿ãã ãããï¼
\end_layout

\begin_layout Enumerate
LyXã¯ãè±èªä»¥å¤ã®è¨èªãèªã¿æ¸ãããæ¹ã«åããæ©è½ãããããåãã¦ãã¾ããããã«å ãã¦ããã¼ã®å²ãå½ã¦ããã¼ã«ãã¼ãããã®ä»å¤ãã®ç¹å¾´ããããã¸ãèªç±ã«è¨å®å¯
è½ã§ããè©³ããã¯ã
\family sans
ãã«ã(
\bar under
H
\bar default
)\SpecialChar \menuseparator
ã«ã¹ã¿ãã¤ãº(
\bar under
C
\bar default
)
\family default
ãè¦ã¦ãã ããã
\end_layout

\begin_layout Enumerate
LyXã®ãã¼ã ãã¼ã¸ã¯ã
\family typewriter

\begin_inset LatexCommand url
target "http://www.lyx.org/;

\end_inset


\family default
ã«ããã¾ããLyXã®æå ±ãå¾ãããLyXã®ã¡ã¼ãªã³ã°ãªã¹ãã«å å¥ããããLyXã®ã°ã©ãã£ã«ã«ã»ãã¢ã¼ãè¦ã¦ã¿ããããã¾ãã¾ãªãã¨ãã§ãã¾ãã
\end_layout

\end_body
\end_document

Re: Update of lib/doc/LaTeXConfig.lyx: added location of jsclasses and Japanese standard classes

2007-12-20 Thread Koji Yokota


I guess it was a stony road to convince ASCII Corp. to put it on CTAN.


No, it was not that hard :) Actually, they had a plan to do it in near 
future.



What is the current official license for PTeX? I only found this:
http://www.ctan.org/tex-archive/help/Catalogue/licenses.other-free.html
(http://www.ctan.org/tex-archive/help/Catalogue/entries/ptex.html)


Its license is the BSD license:
http://www.ctan.org/tex-archive/language/japanese/ptex/COPYRIGHT


I did this now.


Thank you very much :)

Koji

Re: Update of lib/doc/LaTeXConfig.lyx: added location of jsclasses and Japanese standard classes

2007-12-20 Thread Koji Yokota


I guess it was a stony road to convince ASCII Corp. to put it on CTAN.


No, it was not that hard :) Actually, they had a plan to do it in near 
future.



What is the current official license for PTeX? I only found this:
http://www.ctan.org/tex-archive/help/Catalogue/licenses.other-free.html
(http://www.ctan.org/tex-archive/help/Catalogue/entries/ptex.html)


Its license is the BSD license:
http://www.ctan.org/tex-archive/language/japanese/ptex/COPYRIGHT


I did this now.


Thank you very much :)

Koji

Update of lib/doc/LaTeXConfig.lyx: added location of jsclasses and Japanese standard classes

2007-12-16 Thread Koji Yokota

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

pTeX (a modified TeX to handle Japanese) including Japanese standard
classes and also jsclasses have been uploaded to CTAN.

Accordingly, could you update lib/doc/LaTexConfig.lyx as the attached
patch? I added lines to indicate the places of Japanese class files in CTAN.

Regards,

Koji
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHZh+kbrHz2oqsCNsRArfeAJ41JgiKAztpyl5KlzSue0136OaVoQCcCxrY
afq4hdBi5898xRha+vjMB1Y=
=uXxv
-END PGP SIGNATURE-
--- lib/doc/LaTeXConfig.lyx.orig	2007-12-08 03:20:40.0 +0900
+++ lib/doc/LaTeXConfig.lyx	2007-12-09 02:13:47.0 +0900
@@ -1,5 +1,5 @@
 #LyX 1.6.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 299
+\lyxformat 307
 \begin_document
 \begin_header
 \textclass article
@@ -1284,14 +1284,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 ftp://ftp.springer.de/pub/tex/latex/compsc/proc/author
 \end_layout
 
@@ -1361,14 +1353,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.sgmltools.org
 \end_layout
 
@@ -1436,14 +1420,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.dante.de
 \end_layout
 
@@ -1535,14 +1511,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://math.tulane.edu/~entcs/
 \end_layout
 
@@ -1874,14 +1842,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.ieee.org
 \end_layout
 
@@ -1943,14 +1903,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.worldscinet.com/ijmpc/mkt/guidelines.shtml
 \end_layout
 
@@ -1994,14 +1946,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.worldscinet.com/ijmpd/mkt/guidelines.shtml
 \end_layout
 
@@ -2045,14 +1989,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 ftp://ftp.iop.org/pub/journals/latex2e
 \end_layout
 
@@ -2129,7 +2065,9 @@
 \end_layout
 
 \begin_layout Description
-CTAN: N/A
+CTAN: 
+\family typewriter
+install/language/japanese/ptex.tds.zip
 \end_layout
 
 \begin_layout Description
@@ -2188,7 +2126,9 @@
 \end_layout
 
 \begin_layout Description
-CTAN: N/A
+CTAN: 
+\family typewriter
+macros/latex/contrib/jsclasses/
 \end_layout
 
 \begin_layout Description
@@ -2250,14 +2190,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.wkap.nl/kaphtml.htm/STYLEFILES
 \end_layout
 
@@ -2282,14 +2214,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.wkap.nl/jrnllist.htm/JRNLHOME
 \end_layout
 
@@ -2540,14 +2464,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 ftp://trick.ntp.springer.de/pub/tex/latex/llncs/latex2e
 \end_layout
 
@@ -2746,14 +2662,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://public.lanl.gov/kmh/spie/
 \end_layout
 
@@ -2775,14 +2683,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://spie.org/app/Publications/index.cfm?fuseaction=authinfotype=proceedings
 \end_layout
 
@@ -2865,14 +2765,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://publish.aps.org/revtex4/
 \end_layout
 
@@ -2984,14 +2876,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.springeronline.com
 \end_layout
 
@@ -3067,14 +2951,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.springeronline.com
 \end_layout
 
@@ -3128,14 +3004,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.springeronline.com
 \end_layout
 
@@ -3204,14 +3072,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.tug.org
 \end_layout
 
@@ -3253,14 +3113,6 @@
 
 \begin_layout Standard

Update of lib/doc/LaTeXConfig.lyx: added location of jsclasses and Japanese standard classes

2007-12-16 Thread Koji Yokota

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

pTeX (a modified TeX to handle Japanese) including Japanese standard
classes and also jsclasses have been uploaded to CTAN.

Accordingly, could you update lib/doc/LaTexConfig.lyx as the attached
patch? I added lines to indicate the places of Japanese class files in CTAN.

Regards,

Koji
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHZh+kbrHz2oqsCNsRArfeAJ41JgiKAztpyl5KlzSue0136OaVoQCcCxrY
afq4hdBi5898xRha+vjMB1Y=
=uXxv
-END PGP SIGNATURE-
--- lib/doc/LaTeXConfig.lyx.orig	2007-12-08 03:20:40.0 +0900
+++ lib/doc/LaTeXConfig.lyx	2007-12-09 02:13:47.0 +0900
@@ -1,5 +1,5 @@
 #LyX 1.6.0svn created this file. For more info see http://www.lyx.org/
-\lyxformat 299
+\lyxformat 307
 \begin_document
 \begin_header
 \textclass article
@@ -1284,14 +1284,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 ftp://ftp.springer.de/pub/tex/latex/compsc/proc/author
 \end_layout
 
@@ -1361,14 +1353,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.sgmltools.org
 \end_layout
 
@@ -1436,14 +1420,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.dante.de
 \end_layout
 
@@ -1535,14 +1511,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://math.tulane.edu/~entcs/
 \end_layout
 
@@ -1874,14 +1842,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.ieee.org
 \end_layout
 
@@ -1943,14 +1903,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.worldscinet.com/ijmpc/mkt/guidelines.shtml
 \end_layout
 
@@ -1994,14 +1946,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.worldscinet.com/ijmpd/mkt/guidelines.shtml
 \end_layout
 
@@ -2045,14 +1989,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 ftp://ftp.iop.org/pub/journals/latex2e
 \end_layout
 
@@ -2129,7 +2065,9 @@
 \end_layout
 
 \begin_layout Description
-CTAN: N/A
+CTAN: 
+\family typewriter
+install/language/japanese/ptex.tds.zip
 \end_layout
 
 \begin_layout Description
@@ -2188,7 +2126,9 @@
 \end_layout
 
 \begin_layout Description
-CTAN: N/A
+CTAN: 
+\family typewriter
+macros/latex/contrib/jsclasses/
 \end_layout
 
 \begin_layout Description
@@ -2250,14 +2190,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.wkap.nl/kaphtml.htm/STYLEFILES
 \end_layout
 
@@ -2282,14 +2214,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.wkap.nl/jrnllist.htm/JRNLHOME
 \end_layout
 
@@ -2540,14 +2464,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 ftp://trick.ntp.springer.de/pub/tex/latex/llncs/latex2e
 \end_layout
 
@@ -2746,14 +2662,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://public.lanl.gov/kmh/spie/
 \end_layout
 
@@ -2775,14 +2683,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://spie.org/app/Publications/index.cfm?fuseaction=authinfo=proceedings
 \end_layout
 
@@ -2865,14 +2765,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://publish.aps.org/revtex4/
 \end_layout
 
@@ -2984,14 +2876,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.springeronline.com
 \end_layout
 
@@ -3067,14 +2951,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.springeronline.com
 \end_layout
 
@@ -3128,14 +3004,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.springeronline.com
 \end_layout
 
@@ -3204,14 +3072,6 @@
 
 \begin_layout Standard
 
-\family roman
-\series medium
-\shape up
-\size normal
-\emph off
-\bar no
-\noun off
-\color none
 http://www.tug.org
 \end_layout
 
@@ -3253,14 +3113,6 @@
 
 \begin_layout Standard

Re: Support request for Japanese without CJK

2007-11-07 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

Koji Yokota [EMAIL PROTECTED] writes:
  

   Yes, that's the problem. It should work well for a user who changed
the default converter of latex - DVI to platex and writes only
Japanese exclusively. But once he begins to write French with the same
setting, he may face trouble in preview and output, unless he changes
the default converter back to latex.

Should binaries be dynamically switched depending on languages?



I do not know how to handle that actually. Even worse, what if some
people try to make a document in french+japanese?
  


As far as babel is used, platex can cover most of major western 
languages (maybe all languages) that babel supports, if a user has set 
up necessary latex environment. (If babel is not used, one may get a 
weird output with *no errors*.) So far, based on trustworthy information 
on web, I could confirm that the following language could be handled 
with babel  platex at least (with appropriate settings of latex): 
English, Esperanto, Interlingua, Dutch, Afrikaaans, German (incl. 
ngerman), Breton, Welsh, Irish, Scottish, Greek, French, Italian, Latin, 
Portuguese, Spanish,  Catalan,  Galician,  Basque,  Romanian, Danish, 
Icelandic, Norsk, Nynorsk, Swedish, Samin, Finnish, Magyar, Estonian, 
Croatian, Cyech, Polish, Sebian, Slovak, Slovene, Russian, Bulgarian, 
Ukrainian, Upper Sorbian, Lower Sorbian, Turkish, Bahasa, Copt, 
Mongorian, Classical Greek.


For platex to coexist with Chinese and Korean, it's not straightforward. 
In that case, the otfcjk package should be used (I haven't tested this 
approach yet). Such a tex file should begin in UTF-8 with:


\documentclass{jarticle}

\usepackage[multi]{otf}
\usepackage{mlotf}

\begin{document}

... Japanese or English ...

\begin{繁体中文}
... Taiwanese ...
\end{繁体中文}

\begin{簡体中文}
... Mainland Chinese ...
\end{簡体中文}

\begin{ハングル}
... Korean ...
\end{ハングル}


and convert it to SJIS (EUC and JIS also possible?) using

utf8toutf cjk.tex cjk-sjis.tex


(conversion via iconv also works?) and apply platex to compile. I think 
I need to test this approach more before including Chinese and Korean 
support with platex.


If one wants to include more languages such as Thai, Mongolian or 
Vietnamese, more tweaks are needed (but possible). This is not a problem 
of platex, but because of localisation of these languages.


I personally think that the coverage above is sufficient for non-CJK 
Japanese to begin with. If someone wants to include more languages he 
should rely on CJK + unicode setting at the expense of quality (and that 
seems what TeX users are normally doing).


Koji

Re: Support request for Japanese without CJK

2007-11-07 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

Koji Yokota <[EMAIL PROTECTED]> writes:
  

   Yes, that's the problem. It should work well for a user who changed
the default converter of "latex -> DVI" to "platex" and writes only
Japanese exclusively. But once he begins to write French with the same
setting, he may face trouble in preview and output, unless he changes
the default converter back to "latex".

Should binaries be dynamically switched depending on languages?



I do not know how to handle that actually. Even worse, what if some
people try to make a document in french+japanese?
  


As far as babel is used, platex can cover most of major western 
languages (maybe all languages) that babel supports, if a user has set 
up necessary latex environment. (If babel is not used, one may get a 
weird output with *no errors*.) So far, based on trustworthy information 
on web, I could confirm that the following language could be handled 
with babel & platex at least (with appropriate settings of latex): 
English, Esperanto, Interlingua, Dutch, Afrikaaans, German (incl. 
ngerman), Breton, Welsh, Irish, Scottish, Greek, French, Italian, Latin, 
Portuguese, Spanish,  Catalan,  Galician,  Basque,  Romanian, Danish, 
Icelandic, Norsk, Nynorsk, Swedish, Samin, Finnish, Magyar, Estonian, 
Croatian, Cyech, Polish, Sebian, Slovak, Slovene, Russian, Bulgarian, 
Ukrainian, Upper Sorbian, Lower Sorbian, Turkish, Bahasa, Copt, 
Mongorian, Classical Greek.


For platex to coexist with Chinese and Korean, it's not straightforward. 
In that case, the otfcjk package should be used (I haven't tested this 
approach yet). Such a tex file should begin in UTF-8 with:


\documentclass{jarticle}

\usepackage[multi]{otf}
\usepackage{mlotf}

\begin{document}

... Japanese or English ...

\begin{繁体中文}
... Taiwanese ...
\end{繁体中文}

\begin{簡体中文}
... Mainland Chinese ...
\end{簡体中文}

\begin{ハングル}
... Korean ...
\end{ハングル}


and convert it to SJIS (EUC and JIS also possible?) using

utf8toutf cjk.tex cjk-sjis.tex


(conversion via iconv also works?) and apply platex to compile. I think 
I need to test this approach more before including Chinese and Korean 
support with platex.


If one wants to include more languages such as Thai, Mongolian or 
Vietnamese, more tweaks are needed (but possible). This is not a problem 
of platex, but because of localisation of these languages.


I personally think that the coverage above is sufficient for non-CJK 
Japanese to begin with. If someone wants to include more languages he 
should rely on CJK + unicode setting at the expense of quality (and that 
seems what TeX users are normally doing).


Koji

Re: Support request for Japanese without CJK

2007-11-03 Thread Koji Yokota

Uwe Stöhr wrote:
 This file was broken. It seems you have copied the text manually with
 and editor into the section about kluwer.

Oops, sorry about that.

 The CTAN paths you gave in your don't exist - I can't find a path
 http://www.ctan.org/tex-archive/language/japanese/ptex-texmf/
 and
 http://www.ctan.org/tex-archive/language/japanese/jsclasses/
 
 I therefore set it to unknown. What are the right paths?

As I'm arranging with CTAN to include additional documentations, they
are currently suspended. They will be uploaded soon (in a several days,
I hope). So, please keep them as unknown for the moment.

 I committed this version:
 http://www.lyx.org/trac/changeset/21415

Thank you,

Koji

Re: Support request for Japanese without CJK

2007-11-03 Thread Koji Yokota

Uwe Stöhr wrote:
> This file was broken. It seems you have copied the text manually with
> and editor into the section about kluwer.

Oops, sorry about that.

> The CTAN paths you gave in your don't exist - I can't find a path
> http://www.ctan.org/tex-archive/language/japanese/ptex-texmf/
> and
> http://www.ctan.org/tex-archive/language/japanese/jsclasses/
> 
> I therefore set it to unknown. What are the right paths?

As I'm arranging with CTAN to include additional documentations, they
are currently suspended. They will be uploaded soon (in a several days,
I hope). So, please keep them as unknown for the moment.

> I committed this version:
> http://www.lyx.org/trac/changeset/21415

Thank you,

Koji

Re: Support request for Japanese without CJK

2007-11-02 Thread Koji Yokota


Uwe Stöhr wrote:
This description is independent from CTAN. We need an explanation for 
all document classes we ship with LyX in LateXConfig.lyx. So it would 
be nice when you could send a patch for LaTeXConfig.lyx the next days.



Sorry for being late. Please apply the attached patch to add description 
in LaTeXConfig.lyx.


Thanks,

Koji
--- lib/doc/LaTeXConfig.lyx.orig	Fri Oct 12 23:59:48 2007
+++ lib/doc/LaTeXConfig.lyx	Sat Nov  3 12:54:44 2007
@@ -1959,6 +1999,175 @@
 \end_layout
 
 \begin_layout Subsection
+Japanese standard classes
+\end_layout
+
+\begin_layout Description
+Found: 
+\family sans
+jarticle
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   jarticle
+\end_inset
+
+, 
+\family sans
+jreport
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   jreport
+\end_inset
+
+, 
+\family sans
+jbook
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   jbook
+\end_inset
+
+, 
+\family sans
+tarticle
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   tarticle
+\end_inset
+
+, 
+\family sans
+treport
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   treport
+\end_inset
+
+, 
+\family sans
+tbook
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   tbook
+\end_inset
+
+
+\end_layout
+
+\begin_layout Description
+CTAN: 
+\family typewriter
+language/japanese/ptex-texmf/
+\end_layout
+
+\begin_layout Description
+Notes: These document classes provide different versions of the base LaTeX
+ document classes 
+\family sans
+article
+\family default
+, 
+\family sans
+report
+\family default
+ and 
+\family sans
+book
+\family default
+.
+ They are modified to suit Japanese writing.
+ Classes beginning with 
+\begin_inset Quotes eld
+\end_inset
+
+t-
+\begin_inset Quotes erd
+\end_inset
+
+ should be used for traditional vertical writing.
+\end_layout
+
+\begin_layout Subsection
+Japanese new standard classes
+\end_layout
+
+\begin_layout Description
+Found: 
+\family sans
+jsarticle
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   jsarticle
+\end_inset
+
+, 
+\family sans
+jsbook
+\family default
+: 
+\begin_inset Info
+type  textclass
+arg   jsbook
+\end_inset
+
+
+\end_layout
+
+\begin_layout Description
+CTAN: 
+\family typewriter
+language/japanese/jsclasses/
+\end_layout
+
+\begin_layout Description
+Notes: These document classes provide different versions of the base LaTeX
+ document classes 
+\family sans
+article
+\family default
+, 
+\family sans
+report
+\family default
+ and 
+\family sans
+book
+\family default
+ with better look for Japanese typesettings.
+ Equivalence of the 
+\family sans
+report
+\family default
+ class can be obtained by using the
+\family sans
+ jsbook
+\family default
+ class with option 
+\begin_inset Quotes eld
+\end_inset
+
+report
+\begin_inset Quotes erd
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Subsection
 kluwer
 \end_layout

Re: Support request for Japanese without CJK

2007-11-02 Thread Koji Yokota


Uwe Stöhr wrote:
This description is independent from CTAN. We need an explanation for 
all document classes we ship with LyX in LateXConfig.lyx. So it would 
be nice when you could send a patch for LaTeXConfig.lyx the next days.



Sorry for being late. Please apply the attached patch to add description 
in LaTeXConfig.lyx.


Thanks,

Koji
--- lib/doc/LaTeXConfig.lyx.orig	Fri Oct 12 23:59:48 2007
+++ lib/doc/LaTeXConfig.lyx	Sat Nov  3 12:54:44 2007
@@ -1959,6 +1999,175 @@
 \end_layout
 
 \begin_layout Subsection
+Japanese standard classes
+\end_layout
+
+\begin_layout Description
+Found: 
+\family sans
+jarticle
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "jarticle"
+\end_inset
+
+, 
+\family sans
+jreport
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "jreport"
+\end_inset
+
+, 
+\family sans
+jbook
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "jbook"
+\end_inset
+
+, 
+\family sans
+tarticle
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "tarticle"
+\end_inset
+
+, 
+\family sans
+treport
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "treport"
+\end_inset
+
+, 
+\family sans
+tbook
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "tbook"
+\end_inset
+
+
+\end_layout
+
+\begin_layout Description
+CTAN: 
+\family typewriter
+language/japanese/ptex-texmf/
+\end_layout
+
+\begin_layout Description
+Notes: These document classes provide different versions of the base LaTeX
+ document classes 
+\family sans
+article
+\family default
+, 
+\family sans
+report
+\family default
+ and 
+\family sans
+book
+\family default
+.
+ They are modified to suit Japanese writing.
+ Classes beginning with 
+\begin_inset Quotes eld
+\end_inset
+
+t-
+\begin_inset Quotes erd
+\end_inset
+
+ should be used for traditional vertical writing.
+\end_layout
+
+\begin_layout Subsection
+Japanese new standard classes
+\end_layout
+
+\begin_layout Description
+Found: 
+\family sans
+jsarticle
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "jsarticle"
+\end_inset
+
+, 
+\family sans
+jsbook
+\family default
+: 
+\begin_inset Info
+type  "textclass"
+arg   "jsbook"
+\end_inset
+
+
+\end_layout
+
+\begin_layout Description
+CTAN: 
+\family typewriter
+language/japanese/jsclasses/
+\end_layout
+
+\begin_layout Description
+Notes: These document classes provide different versions of the base LaTeX
+ document classes 
+\family sans
+article
+\family default
+, 
+\family sans
+report
+\family default
+ and 
+\family sans
+book
+\family default
+ with better look for Japanese typesettings.
+ Equivalence of the 
+\family sans
+report
+\family default
+ class can be obtained by using the
+\family sans
+ jsbook
+\family default
+ class with option 
+\begin_inset Quotes eld
+\end_inset
+
+report
+\begin_inset Quotes erd
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Subsection
 kluwer
 \end_layout

Re: Support request for Japanese without CJK

2007-10-23 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

But doesn't this mean that somebody who has platex installed is now unable to
use LyX to prepare documents in, say, latin1? 
  


Yes, that's the problem. It should work well for a user who changed the 
default converter of latex - DVI to platex and writes only Japanese 
exclusively. But once he begins to write French with the same setting, 
he may face trouble in preview and output, unless he changes the default 
converter back to latex.


Should binaries be dynamically switched depending on languages?

Koji

Re: Support request for Japanese without CJK

2007-10-23 Thread Koji Yokota


Dear Uwe,

Uwe Stöhr wrote:
Besides the problem that the platex encoding must be checked by 
configure.py, we are now ready, right?


Yes. I think we have all building blocks by now. It's running well for 
Japanese documents. Thank you very much.


Could you anyway please create a bug report for the platex encoding 
check problematic?


I did it now.


Koji

Re: Support request for Japanese without CJK

2007-10-23 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

But doesn't this mean that somebody who has platex installed is now unable to
use LyX to prepare documents in, say, latin1? 
  


Yes, that's the problem. It should work well for a user who changed the 
default converter of "latex -> DVI" to "platex" and writes only Japanese 
exclusively. But once he begins to write French with the same setting, 
he may face trouble in preview and output, unless he changes the default 
converter back to "latex".


Should binaries be dynamically switched depending on languages?

Koji

Re: Support request for Japanese without CJK

2007-10-23 Thread Koji Yokota


Dear Uwe,

Uwe Stöhr wrote:
Besides the problem that the platex encoding must be checked by 
configure.py, we are now ready, right?


Yes. I think we have all building blocks by now. It's running well for 
Japanese documents. Thank you very much.


Could you anyway please create a bug report for the platex encoding 
check problematic?


I did it now.


Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota


Koji Yokota wrote:

Uwe Stöhr wrote:
I implemented JMarcs suggestion that the japanese packaeg is only 
loaded when a textclass doesn't already provide it.


Thank you. I attach layout files for standard Japanese classes using 
this feature. Could you include these in trunk?


Currently, platex cannot find these classes with configure.py because it 
is not recognized as a latex binary. Could you apply the attached 
patches (or else) so that it can find the classes (and also preview of 
math to work)?


Koji
--- lib/configure.py.orig	Tue Oct 16 00:25:55 2007
+++ lib/configure.py	Tue Oct 16 00:44:52 2007
@@ -202,7 +202,7 @@
 \converter dvi2   dvipython -tt $$s/scripts/clean_dvi.py $$i $$o	'''
 else:
 converter_entry = r'\converter latex  dvi%%	latex'
-path, LATEX = checkProg('a Latex2e program', ['pplatex $$i', 'latex $$i', 'latex2e $$i'],
+path, LATEX = checkProg('a Latex2e program', ['pplatex $$i', 'platex $$i', 'latex $$i', 'latex2e $$i'],
 rc_entry = [converter_entry])
 # no latex
 if LATEX != '':
--- lib/scripts/legacy_lyxpreview2ppm.py.orig	Wed Jul 11 16:40:55 2007
+++ lib/scripts/legacy_lyxpreview2ppm.py	Tue Oct 16 00:44:52 2007
@@ -234,7 +234,7 @@
 
 # External programs used by the script.
 path = string.split(os.environ[PATH], os.pathsep)
-latex   = find_exe_or_terminate([pplatex, latex2e, latex], path)
+latex   = find_exe_or_terminate([pplatex, platex, latex2e, latex], path)
 dvips   = find_exe_or_terminate([dvips], path)
 gs  = find_exe_or_terminate([gswin32c, gs], path)
 pnmcrop = find_exe([pnmcrop], path)
--- lib/scripts/lyxpreview2bitmap.py.orig	Wed Jul 11 16:40:55 2007
+++ lib/scripts/lyxpreview2bitmap.py	Tue Oct 16 00:44:52 2007
@@ -150,7 +150,7 @@
 
 # External programs used by the script.
 path = string.split(os.environ[PATH], os.pathsep)
-latex = find_exe_or_terminate([pplatex, latex2e, latex], path)
+latex = find_exe_or_terminate([pplatex, platex, latex2e, latex], path)
 
 # This can go once dvipng becomes widespread.
 dvipng = find_exe([dvipng], path)

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

What is the difference between platex and latex?
  


platex is a latex binary that can handle Japanese characters (in EUC, 
JIS or SJIS) which is derived from the original latex. The platex system 
comes with latex binary as well, but the search path for platex set in 
web2c/texmf.cnf of the platex distribution is independent from the one 
for latex:


 TEXINPUTS.latex  = .;$TEXMF/tex/{latex,generic,}//
 TEXINPUTS.platex = .;$TEXMF/{ptex/{platex,generic,}, \
   
tex/{latex,generic,}}//


Therefore, latex fails to find out the default directory of Japanese 
standard classes. platex must be used instead.


Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota


Koji Yokota wrote:
For pTeX, the output of 'ptex -version' (or 'platex -version') 
contains a line:


 pTeX 3.141592-p3.1.9 (EUC) (Web2C 7.5.4)


Dear Uwe,

Possible outputs of the above are: EUC, SJIS and JIS.

However, I found that Kanji code can be modified using an option -kanji:

$ platex -kanji=euc
This is pTeX, Version 3.141592-p3.1.9 (euc) (Web2C 7.5.4)
$ platex -kanji=jis
This is pTeX, Version 3.141592-p3.1.9 (jis) (Web2C 7.5.4)
$ platex -kanji=sjis
This is pTeX, Version 3.141592-p3.1.9 (sjis) (Web2C 7.5.4)

So, the kanji code need not be fixed by configure.py, but can be changed 
from the menu of encoding setting using the above option.



Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota


Koji Yokota wrote:
However, I found that Kanji code can be modified using an option 
-kanji:


ps. This feature can only be used with newer version of ptex than p3.0.4.

This is pTeX, Version 3.1415-p3.0.4 (euc) (Web2C 7.3.9)


Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

Bt can platex handle all non-japanese documents that latex can handle?
In other words, can we really use platex as a replacement for latex
when it is available?
  


platex can handle English -- 7bit code -- perfectly, so probably there 
is no problem in using it for configuration purpose.


However, we need to be careful in using it for math preview. README2 in 
the platex distribution says:


 Current pTeX may recognize a sequence of 8bit codes as a 16bit code.
 Therefore, it cannot handle a TeX source or a hyphen pattern which
 contains a sequence of 8bit codes such as French or Cyrillic.

 Threfore, pLaTeX2e has its own hyphen.cfg in the directory
 $TEXMF/tex/platex/base so that it doesn't load other hyphen patterns
 which may cause a problem.

But, conversion of the documents that contain 8bit codes to a 16bit code 
such as EUC will probably raise a problem in itself and stops 
(correct?). Should we allow lyx to use platex for preview purpose, once 
the document succeeds in conversion because a problematic document fails 
in conversion anyway?


Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota


Koji Yokota wrote:

Uwe Stöhr wrote:
I implemented JMarcs suggestion that the japanese packaeg is only 
loaded when a textclass doesn't already provide it.


Thank you. I attach layout files for standard Japanese classes using 
this feature. Could you include these in trunk?


Currently, platex cannot find these classes with configure.py because it 
is not recognized as a latex binary. Could you apply the attached 
patches (or else) so that it can find the classes (and also preview of 
math to work)?


Koji
--- lib/configure.py.orig	Tue Oct 16 00:25:55 2007
+++ lib/configure.py	Tue Oct 16 00:44:52 2007
@@ -202,7 +202,7 @@
 \converter dvi2   dvi"python -tt $$s/scripts/clean_dvi.py $$i $$o"	""'''
 else:
 converter_entry = r'\converter latex  dvi"%%"	"latex"'
-path, LATEX = checkProg('a Latex2e program', ['pplatex $$i', 'latex $$i', 'latex2e $$i'],
+path, LATEX = checkProg('a Latex2e program', ['pplatex $$i', 'platex $$i', 'latex $$i', 'latex2e $$i'],
 rc_entry = [converter_entry])
 # no latex
 if LATEX != '':
--- lib/scripts/legacy_lyxpreview2ppm.py.orig	Wed Jul 11 16:40:55 2007
+++ lib/scripts/legacy_lyxpreview2ppm.py	Tue Oct 16 00:44:52 2007
@@ -234,7 +234,7 @@
 
 # External programs used by the script.
 path = string.split(os.environ["PATH"], os.pathsep)
-latex   = find_exe_or_terminate(["pplatex", "latex2e", "latex"], path)
+latex   = find_exe_or_terminate(["pplatex", "platex", "latex2e", "latex"], path)
 dvips   = find_exe_or_terminate(["dvips"], path)
 gs  = find_exe_or_terminate(["gswin32c", "gs"], path)
 pnmcrop = find_exe(["pnmcrop"], path)
--- lib/scripts/lyxpreview2bitmap.py.orig	Wed Jul 11 16:40:55 2007
+++ lib/scripts/lyxpreview2bitmap.py	Tue Oct 16 00:44:52 2007
@@ -150,7 +150,7 @@
 
 # External programs used by the script.
 path = string.split(os.environ["PATH"], os.pathsep)
-latex = find_exe_or_terminate(["pplatex", "latex2e", "latex"], path)
+latex = find_exe_or_terminate(["pplatex", "platex", "latex2e", "latex"], path)
 
 # This can go once dvipng becomes widespread.
 dvipng = find_exe(["dvipng"], path)

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota

Jean-Marc Lasgouttes wrote:

What is the difference between platex and latex?

platex is a latex binary that can handle Japanese characters (in EUC, 
JIS or SJIS) which is derived from the original latex. The platex system 
comes with latex binary as well, but the search path for platex set in 
web2c/texmf.cnf of the platex distribution is independent from the one 
for latex:

> TEXINPUTS.latex  = .;$TEXMF/tex/{latex,generic,}//
> TEXINPUTS.platex = .;$TEXMF/{ptex/{platex,generic,}, \

tex/{latex,generic,}}//

Therefore, latex fails to find out the default directory of Japanese 
standard classes. platex must be used instead.

Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota

Koji Yokota wrote:
For pTeX, the output of 'ptex -version' (or 'platex -version') 
contains a line:

> pTeX 3.141592-p3.1.9 (EUC) (Web2C 7.5.4)

Dear Uwe,

Possible outputs of the above are: EUC, SJIS and JIS.

However, I found that Kanji code can be modified using an option "-kanji":

   > $ platex -kanji=euc
   > This is pTeX, Version 3.141592-p3.1.9 (euc) (Web2C 7.5.4)
   > $ platex -kanji=jis
   > This is pTeX, Version 3.141592-p3.1.9 (jis) (Web2C 7.5.4)
   > $ platex -kanji=sjis
   > This is pTeX, Version 3.141592-p3.1.9 (sjis) (Web2C 7.5.4)

So, the kanji code need not be fixed by configure.py, but can be changed 
from the menu of encoding setting using the above option.

Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota


Koji Yokota wrote:
However, I found that Kanji code can be modified using an option 
"-kanji":


ps. This feature can only be used with newer version of ptex than p3.0.4.

   > This is pTeX, Version 3.1415-p3.0.4 (euc) (Web2C 7.3.9)


Koji

Re: Support request for Japanese without CJK

2007-10-16 Thread Koji Yokota

Jean-Marc Lasgouttes wrote:

Bt can platex handle all non-japanese documents that latex can handle?
In other words, can we really use platex as a replacement for latex
when it is available?

platex can handle English -- 7bit code -- perfectly, so probably there 
is no problem in using it for configuration purpose.

However, we need to be careful in using it for math preview. README2 in 
the platex distribution says:

> Current pTeX may recognize a sequence of 8bit codes as a 16bit code.
> Therefore, it cannot handle a TeX source or a hyphen pattern which
> contains a sequence of 8bit codes such as French or Cyrillic.
>
> Threfore, pLaTeX2e has its own hyphen.cfg in the directory
> $TEXMF/tex/platex/base so that it doesn't load other hyphen patterns
> which may cause a problem.

But, conversion of the documents that contain 8bit codes to a 16bit code 
such as EUC will probably raise a problem in itself and stops 
(correct?). Should we allow lyx to use platex for preview purpose, once 
the document succeeds in conversion because a problematic document fails 
in conversion anyway?

Koji

Re: Support request for Japanese without CJK

2007-10-15 Thread Koji Yokota


Uwe Stöhr wrote:
Then we couldn't do much in this case. But english will only be loaded 
when you mark text with this language. So the fix for this would be to 
prepaer a template file for the two problematic classes and add there 
a note describing this.


With the newest svn, I confirmed that when language is japanese-plain, 
the output is \documentclass{jsarticle}. This is fine. It now outputs 
Japanese headings correctly.


Please ignore this problem (there may have been malign effects from old 
files).


Thank you,

Koji

Re: Support request for Japanese without CJK

2007-10-15 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

It would be nice to have an entry in LaTeXConfig.lyx explaining what
these things are good for and where to find them.
  


I will send a patch after the CTAN thing is settled.

Thanks,

Koji

Re: Support request for Japanese without CJK

2007-10-15 Thread Koji Yokota


Uwe Stöhr wrote:
Then we couldn't do much in this case. But english will only be loaded 
when you mark text with this language. So the fix for this would be to 
prepaer a template file for the two problematic classes and add there 
a note describing this.


With the newest svn, I confirmed that when language is "japanese-plain", 
the output is "\documentclass{jsarticle}". This is fine. It now outputs 
Japanese headings correctly.


Please ignore this problem (there may have been malign effects from old 
files).


Thank you,

Koji

Re: Support request for Japanese without CJK

2007-10-15 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

It would be nice to have an entry in LaTeXConfig.lyx explaining what
these things are good for and where to find them.
  


I will send a patch after the CTAN thing is settled.

Thanks,

Koji

Re: Support request for Japanese without CJK

2007-10-13 Thread Koji Yokota


Uwe Stöhr wrote:
I'll try to implement the encoding check when I find some more time. 
Therefore I requested bugzilla entries as this assures that it won't 
be forgotten.


OK, I'll do so.

I implemented JMarcs suggestion that the japanese packaeg is only 
loaded when a textclass doesn't already provide it.


Thank you. I attach layout files for standard Japanese classes using 
this feature. Could you include these in trunk?


And, when japanese-plain is used, it seems that we have to omit 
[english] option from \documentclass declaration, i.e. the line current 
output of jsarticle has


 \documentclass[english]{jsarticle}

but this must be changed to

 \documentclass{jsarticle}

otherwise output such as Part I remains English, not Japanese.

I furthermore disables the SJIS-plain encoding for now until we have 
better support for it using the needed conversion your described.


Yes, thank you.

Koji
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{article (Japanese)}
# Japanese article textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features
Provides japanese 1

# Input general definitions
Input article.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{book (Japanese)}
# Japanese book textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input book.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{report (Japanese)}
# Japanese report textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input report.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{article (Japanese New)}
# Japanese new article textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input article.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{book (Japanese New)}
# Japanese new book textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input book.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{article (Japanese in vertical writing)}
# Definition file of Japanese article textclass for vertical writing.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input article.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{book (Japanese in vertical writing)}
# Definition file of Japanese book textclass for vertical writing.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input book.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{report (Japanese in vertical writing)}
# Definition file of Japanese report textclass for vertical writing.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input report.layout

Re: Support request for Japanese without CJK

2007-10-13 Thread Koji Yokota


Uwe Stöhr wrote:

I'll have a look at them and check them into SVN when they are correct.


OK. Thanks.


Also when you have this?:
\documentclass[english]{jsarticle}
\usepackage{japan}


This happens without the japanese package. Also, adding 
\usepackage{japanese} line does not help for jsarticle class.



Does it work when we use this instead?:
\documentclass[english,japanese]{jsarticle}


No, this doesn't seem to work (also, bringing japanese before 
english doesn't work). This problem arises only for jsarticle and 
jsbook. Other styles such as jarticle doesn't redeem the language option 
in \documentclass, so they don't raise a problem even if english is 
specified.


Regards,

Koji

Re: Support request for Japanese without CJK

2007-10-13 Thread Koji Yokota

Uwe Stöhr wrote:
I'll try to implement the encoding check when I find some more time. 
Therefore I requested bugzilla entries as this assures that it won't 
be forgotten.

OK, I'll do so.

I implemented JMarcs suggestion that the japanese packaeg is only 
loaded when a textclass doesn't already provide it.

Thank you. I attach layout files for standard Japanese classes using 
this feature. Could you include these in trunk?

And, when japanese-plain is used, it seems that we have to omit 
[english] option from \documentclass declaration, i.e. the line current 
output of jsarticle has

> \documentclass[english]{jsarticle}

but this must be changed to

> \documentclass{jsarticle}

otherwise output such as "Part I" remains English, not Japanese.

I furthermore disables the SJIS-plain encoding for now until we have 
better support for it using the needed conversion your described.

Yes, thank you.

Koji
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{article (Japanese)}
# Japanese article textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features
Provides japanese 1

# Input general definitions
Input article.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{book (Japanese)}
# Japanese book textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input book.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{report (Japanese)}
# Japanese report textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input report.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{article (Japanese New)}
# Japanese new article textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input article.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{book (Japanese New)}
# Japanese new book textclass definition file.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input book.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{article (Japanese in vertical writing)}
# Definition file of Japanese article textclass for vertical writing.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input article.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{book (Japanese in vertical writing)}
# Definition file of Japanese book textclass for vertical writing.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input book.layout
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass{report (Japanese in vertical writing)}
# Definition file of Japanese report textclass for vertical writing.
# Author : Koji Yokota ([EMAIL PROTECTED])

# This style provides japanese features 
Provides japanese 1

# Input general definitions
Input report.layout

Re: Support request for Japanese without CJK

2007-10-13 Thread Koji Yokota


Uwe Stöhr wrote:

I'll have a look at them and check them into SVN when they are correct.


OK. Thanks.


Also when you have this?:
\documentclass[english]{jsarticle}
\usepackage{japan}


This happens without the japanese package. Also, adding 
\usepackage{japanese} line does not help for jsarticle class.



Does it work when we use this instead?:
\documentclass[english,japanese]{jsarticle}


No, this doesn't seem to work (also, bringing "japanese" before 
"english" doesn't work). This problem arises only for jsarticle and 
jsbook. Other styles such as jarticle doesn't redeem the language option 
in \documentclass, so they don't raise a problem even if "english" is 
specified.


Regards,

Koji

Re: Support request for Japanese without CJK

2007-10-11 Thread Koji Yokota


Uwe Stöhr さんは書きました:

What about adding this encoding?:

# For japanese
Encoding shift-jis SJIS SJIS variable CJK
End

Or don't we have this encoding because the CJK package don't support 
it? I'm wondering because in your patch I applied your defined


Encoding shift-jis-plain SJIS-plain SJIS variable none
End

So now we have an encoding SJIS-plain but no SJIS.


Shift-JIS (Japanese encoding by Microsoft) can contain problematic 
character in the second byte, so the CJK package cannot be handled *as 
is*. To use Shift-JIS code, the document file must be pre-processed 
with sjisconv which comes with the CJK package before compiling with 
latex. Can this be implemented?


The lines in my patch was commented out only in the hope of future use, 
so please ignore it. I called it SJIS-plain when CJK is not used simply 
to distinguish from SJIS with CJK.


Koji

Re: Support request for Japanese without CJK

2007-10-11 Thread Koji Yokota


Uwe Stöhr さんは書きました:

To put it in the nutshell: Now LyX supports all you need, right?


Yes, I believe the core part is already implemented. Thank you very much.

# Our competitors (YKWIM) have been promoting their product in the 
Japanese market saying that its advantage is it can handle 
Japanese-aware latex's. It's good that we can stand on the same ground :)


Another problem is that these Japanese-aware latex's are usually 
compiled separately for EUC, JIS, SJIS and UTF-8 to suit users' 
environment. Now, default of Japanese (non-CJK) is to use EUC but this 
may cause a problem for users on Windows (SJIS).


Indeed, when I change the encoding to JIS-plain when the language is 
Japanese (non-CJK) on my EUC platform, lyx crashes when compiling a 
latex file, with an exception error (iconv_open(out_cd_): invalid argument).


This situation must be resolved, for example, either by stopping 
compilation when encoding is not suitable, or the best thing is to fix 
relation between the entry Japanese (non-CJK) and encodings at the 
configuration time (latex binary's encoding is fixed by the environment, 
so users need not change it). Can this be handled somehow?



Koji

Re: Support request for Japanese without CJK

2007-10-11 Thread Koji Yokota


Uwe Stöhr さんは書きました:
That means the LyX's configure.py should check what encoding is used 
by the found LaTeX-system and then set the correct default encoding 
for japanese-plain in LyX's encodings file?
I think we could try this, but how can we get the information what 
encoding a LaTeX is built for?

Could you also please add for this issue a bug report at bugzilla?


Yes, if configure.py can do it, it'd be great. As Japanese-aware 
latex's, there have been two major versions, pTeX by ASCII co. and jTeX 
by NTT co.. The latter is now becoming less popular, so we may be able 
to focus on the former (this is a matter of choice. Caring both is 
another choice).


For pTeX, the output of 'ptex -version' (or 'platex -version') contains 
a line:


 pTeX 3.141592-p3.1.9 (EUC) (Web2C 7.5.4)

from which we can judge which encodings this tex binary is built for 
(EUC in the above case).


I'm going to compile these problems to bugzilla (with the LF/CR problem).

Regards,

Koji

Re: Support request for Japanese without CJK

2007-10-11 Thread Koji Yokota


Uwe Stöhr さんは書きました:

What about adding this encoding?:

# For japanese
Encoding shift-jis SJIS SJIS variable CJK
End

Or don't we have this encoding because the CJK package don't support 
it? I'm wondering because in your patch I applied your defined


Encoding shift-jis-plain SJIS-plain SJIS variable none
End

So now we have an encoding "SJIS-plain" but no "SJIS".


Shift-JIS (Japanese encoding by Microsoft) can contain problematic 
character in the second byte, so the CJK package cannot be handled *as 
is*. To use Shift-JIS code, the document file must be "pre-processed" 
with sjisconv which comes with the CJK package before compiling with 
latex. Can this be implemented?


The lines in my patch was commented out only in the hope of future use, 
so please ignore it. I called it SJIS-plain when CJK is not used simply 
to distinguish from SJIS with CJK.


Koji

Re: Support request for Japanese without CJK

2007-10-11 Thread Koji Yokota


Uwe Stöhr さんは書きました:

To put it in the nutshell: Now LyX supports all you need, right?


Yes, I believe the core part is already implemented. Thank you very much.

# Our competitors (YKWIM) have been promoting their product in the 
Japanese market saying that its advantage is it can handle 
Japanese-aware latex's. It's good that we can stand on the same ground :)


Another problem is that these Japanese-aware latex's are usually 
compiled separately for EUC, JIS, SJIS and UTF-8 to suit users' 
environment. Now, default of "Japanese (non-CJK)" is to use EUC but this 
may cause a problem for users on Windows (SJIS).


Indeed, when I change the encoding to "JIS-plain" when the language is 
"Japanese (non-CJK)" on my EUC platform, lyx crashes when compiling a 
latex file, with an exception error (iconv_open(out_cd_): invalid argument).


This situation must be resolved, for example, either by stopping 
compilation when encoding is not suitable, or the best thing is to fix 
relation between the entry "Japanese (non-CJK)" and encodings at the 
configuration time (latex binary's encoding is fixed by the environment, 
so users need not change it). Can this be handled somehow?



Koji

Re: Support request for Japanese without CJK

2007-10-11 Thread Koji Yokota


Uwe Stöhr さんは書きました:
That means the LyX's configure.py should check what encoding is used 
by the found LaTeX-system and then set the correct default encoding 
for japanese-plain in LyX's encodings file?
I think we could try this, but how can we get the information what 
encoding a LaTeX is built for?

Could you also please add for this issue a bug report at bugzilla?


Yes, if configure.py can do it, it'd be great. As Japanese-aware 
latex's, there have been two major versions, pTeX by ASCII co. and jTeX 
by NTT co.. The latter is now becoming less popular, so we may be able 
to focus on the former (this is a matter of choice. Caring both is 
another choice).


For pTeX, the output of 'ptex -version' (or 'platex -version') contains 
a line:


> pTeX 3.141592-p3.1.9 (EUC) (Web2C 7.5.4)

from which we can judge which encodings this tex binary is built for 
(EUC in the above case).


I'm going to compile these problems to bugzilla (with the LF/CR problem).

Regards,

Koji

Re: Support request for Japanese without CJK

2007-10-10 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

  if (!textclass.provides(japanese))
 os  \\usepackage{japanese}\n;
  

Oh, great! That's the solution we need.

Koji

Re: Support request for Japanese without CJK

2007-10-10 Thread Koji Yokota


Keiichi Morisato wrote:

About j(s)classes , they are  to be desired that you go for advice
Mr. Okumura ?

cf. ptex http://oku.edu.mie-u.ac.jp/~okumura/texfaq/japanese/ptex.html
 Now the License is the modified BSD license and any UTF-8 editions
 exist. (They are based tetex3 , texlive and more. ) 
  

Morisato-san,

I'm almost sure that BSD license allows redistribution via CTAN, but I 
feel I'd better double-check (you know, legal matters are scary :). I 
will consult with him and ASCII Co..


Thank you for your advice,

Koji

Re: Support request for Japanese without CJK

2007-10-10 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

  if (!textclass.provides("japanese"))
 os << "\\usepackage{japanese}\n";
  

Oh, great! That's the solution we need.

Koji

Re: Support request for Japanese without CJK

2007-10-10 Thread Koji Yokota


Keiichi Morisato wrote:

About j(s)classes , they are  to be desired that you go for advice
Mr. Okumura ?

cf. ptex http://oku.edu.mie-u.ac.jp/~okumura/texfaq/japanese/ptex.html
 Now the License is the modified BSD license and any UTF-8 editions
 exist. (They are based tetex3 , texlive and more. ) 
  

Morisato-san,

I'm almost sure that BSD license allows redistribution via CTAN, but I 
feel I'd better double-check (you know, legal matters are scary :). I 
will consult with him and ASCII Co..


Thank you for your advice,

Koji

Re: Support request for Japanese without CJK

2007-10-09 Thread Koji Yokota

Uwe Stöhr wrote:
 But the word Part appears for me still in English and not in Japanese. But 
 the japanese-package 
 should have translated it. Does the translation work for you with your system 
 and my example?

The file you attached worked fine except that I had to convert from the
DOS (CR/LF) format to UNIX (LF) format :P (BTW, isn't this problematic
to exchange documents between Windows and Unix? LyX on FreeBSD judges a
lyx document written on Windows as a wrong format, raises an error and
simply stops. One must convert the format manually.)

Part is not translated on the lyx screen due to an untraslated entry
in the Japanese message file of LyX. But the DVI file it generates
contains Part in Japanese correctly.

 One remaining issue:
 I currently built in that \usepackage{japanese} is loaded when the document 
 language is 
 japanese-plain; should is also be loaded when the document language is 
 japanese (the one that 
 uses CJK and inputenc)?

I'm not very sure at the moment, but an adhoc test shows that it seems
necessary.

INFO: there are de-facto-standard Japanese-aware styles such as
jarticle, jreport, jbook, jsarticle and jsbook. As far as users use
these styles, the japanese package is not necessary. In other words,
when users use these styles, the call of japanese package is redundant
(and the result may be slightly different). But as a universal solution,
using japanese package will be second-best.

I personally think layouts for these styles should be included in LyX
because they are standard for Japanese language, but again, problem is
that these are not found in CTAN.

These styles are in the modified BSD license. I wonder if I can upload
them to CTAN as a proxy. Is anyone sure about this?

Koji

Re: Support request for Japanese without CJK

2007-10-09 Thread Koji Yokota

Uwe Stöhr wrote:
> But the word "Part" appears for me still in English and not in Japanese. But 
> the japanese-package 
> should have translated it. Does the translation work for you with your system 
> and my example?

The file you attached worked fine except that I had to convert from the
DOS (CR/LF) format to UNIX (LF) format :P (BTW, isn't this problematic
to exchange documents between Windows and Unix? LyX on FreeBSD judges a
lyx document written on Windows as a wrong format, raises an error and
simply stops. One must convert the format manually.)

"Part" is not translated on the lyx screen due to an untraslated entry
in the Japanese message file of LyX. But the DVI file it generates
contains "Part" in Japanese correctly.

> One remaining issue:
> I currently built in that \usepackage{japanese} is loaded when the document 
> language is 
> "japanese-plain"; should is also be loaded when the document language is 
> "japanese" (the one that 
> uses CJK and inputenc)?

I'm not very sure at the moment, but an adhoc test shows that it seems
necessary.

INFO: there are de-facto-standard Japanese-aware styles such as
jarticle, jreport, jbook, jsarticle and jsbook. As far as users use
these styles, the japanese package is not necessary. In other words,
when users use these styles, the call of japanese package is redundant
(and the result may be slightly different). But as a universal solution,
using japanese package will be second-best.

I personally think layouts for these styles should be included in LyX
because they are standard for Japanese language, but again, problem is
that these are not found in CTAN.

These styles are in the modified BSD license. I wonder if I can upload
them to CTAN as a proxy. Is anyone sure about this?

Koji

Re: Support request for Japanese without CJK

2007-10-08 Thread Koji Yokota


Uwe Stöhr wrote:
Can you process LyX's current LaTeX code? For me it only works when I 
omit the inputenc package.


Uwe,

No, you must omit the inputenc package, and the japanese package should 
be loaded after babel declaration. To avoid inputenc, I had to tweak 
current LyX to write Japanese with the following two patches and make 
preamble declaration in each document as:


   \usepackage{babel}
   \usepackage{japanese}

Since LyX loads babel after users' preamble, this means 
\usepackage{babel} is called twice but this is currently necessary to 
load babel before japanese package.


I will check the wiki page.

Regards,

Koji

--- lib/encodings.orig  Fri Jul 13 01:10:01 2007
+++ lib/encodings   Fri Jul 13 01:10:01 2007
@@ -183,6 +183,15 @@
Encoding utf8-plain utf8-plain UTF-8 variable none
End

+# Traditional Japanese TeX programs require neither CJK nor inputenc
+# package.
+Encoding euc-jp-plain EUC-JP-plain EUC-JP variable none
+End
+Encoding jis-plain JIS-plain JIS variable none
+End
+#Encoding shift-jis-plain SJIS-plain SJIS variable none
+#End
+
# Pure 7bit ASCII encoding (partially hardcoded in LyX)
Encoding ascii ascii ascii fixed none
End


--- lib/languages.orig  Fri Jul 13 02:41:51 2007
+++ lib/languages   Fri Jul 13 02:41:51 2007
@@ -41,6 +41,7 @@
irish   irish   Irish   false  iso8859-15 ga_IE  
italian italian Italian false  iso8859-15 it_IT  
japaneseJapanesefalse  euc-jp ja_JP  
+japanese-plain Japanese (non-CJK) false euc-jp-plain ja_JP  
kazakh  kazakh  Kazakh  false  pt154  kk_KZ  
# there is no country code for Korean because ko_KR is the same as ko_KI
korean  Korean  false  euc-kr ko

Re: Support request for Japanese without CJK

2007-10-08 Thread Koji Yokota


Uwe Stöhr wrote:
Can you process LyX's current LaTeX code? For me it only works when I 
omit the inputenc package.


Uwe,

No, you must omit the inputenc package, and the japanese package should 
be loaded after babel declaration. To avoid inputenc, I had to tweak 
current LyX to write Japanese with the following two patches and make 
preamble declaration in each document as:


   \usepackage{babel}
   \usepackage{japanese}

Since LyX loads babel after users' preamble, this means 
\usepackage{babel} is called twice but this is currently necessary to 
load babel before japanese package.


I will check the wiki page.

Regards,

Koji

--- lib/encodings.orig  Fri Jul 13 01:10:01 2007
+++ lib/encodings   Fri Jul 13 01:10:01 2007
@@ -183,6 +183,15 @@
Encoding utf8-plain utf8-plain UTF-8 variable none
End

+# Traditional Japanese TeX programs require neither CJK nor inputenc
+# package.
+Encoding euc-jp-plain EUC-JP-plain EUC-JP variable none
+End
+Encoding jis-plain JIS-plain JIS variable none
+End
+#Encoding shift-jis-plain SJIS-plain SJIS variable none
+#End
+
# Pure 7bit ASCII encoding (partially hardcoded in LyX)
Encoding ascii ascii ascii fixed none
End


--- lib/languages.orig  Fri Jul 13 02:41:51 2007
+++ lib/languages   Fri Jul 13 02:41:51 2007
@@ -41,6 +41,7 @@
irish   irish   "Irish"   false  iso8859-15 ga_IE  ""
italian italian "Italian" false  iso8859-15 it_IT  ""
japanese"""Japanese"false  euc-jp ja_JP  ""
+japanese-plain """Japanese (non-CJK)" false euc-jp-plain ja_JP  ""
kazakh  kazakh  "Kazakh"  false  pt154  kk_KZ  ""
# there is no country code for Korean because ko_KR is the same as ko_KI
korean  """Korean"  false  euc-kr ko ""

Apparently sane po file makes lyx crash

2007-10-03 Thread Koji Yokota

Hi,

I'm currently updating the Japanese message file and facing an error in
which the updated message file causes lyx to crash. Can anyone tell me
whether this can happen because of any problem in the message file or it
can be a bug in LyX? Conversion of the po file by msgfmt emits no error
messages and any grammatical checks by the editor (KBabel) returns OK.
Encoding also seems OK.

When I start LyX with the updated message file, it emits error:

 Assertion triggered in const std::string lyx::to_ascii(const
lyx::docstring) by failing check
 ucs4[i]  0x80 in file docstring.cpp:55
 Abort (dumped core)

and dies. The error obviously relates to handling Japanese messages and
LyX runs in sane with LC_ALL=C. The problem occurred with svn-version on
Monday.

I put the debug message of `lyx -dbg any' and the problematic po
file at http://www.otaru-uc.ac.jp/~yokota/comp/lyx/debug.log and
http://www.otaru-uc.ac.jp/~yokota/comp/lyx/ja.po respectively.

Thanks in advance,

Koji

Re: Apparently sane po file makes lyx crash

2007-10-03 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

[[Context]] is used to distinguish otherwise identical strings, which could
have different translation dependent on the Context. [[Context]] appears only
in msgid string and should not be repeated in the translated version.
-

You should leave it as it was in the file:

#: src/support/filetools.cpp:313
msgid [[Replace with the code of your language]]
msgstr ja

It is used internally by LyX to find out what language has been
loaded.
  

JMarc,

It seems this was causing the problem.

Thank you for your help.


Juergen Spitzmueller wrote:

this is just to remind you that we need your translation by Friday.


I think I can post the updated message file for 1.5.2 by Friday(GMT) 
utilizing the location of Far East :)


Koji

Apparently sane po file makes lyx crash

2007-10-03 Thread Koji Yokota

Hi,

I'm currently updating the Japanese message file and facing an error in
which the updated message file causes lyx to crash. Can anyone tell me
whether this can happen because of any problem in the message file or it
can be a bug in LyX? Conversion of the po file by msgfmt emits no error
messages and any grammatical checks by the editor (KBabel) returns OK.
Encoding also seems OK.

When I start LyX with the updated message file, it emits error:

> Assertion triggered in const std::string lyx::to_ascii(const
lyx::docstring&) by failing check
> "ucs4[i] < 0x80" in file docstring.cpp:55
> Abort (dumped core)

and dies. The error obviously relates to handling Japanese messages and
LyX runs in sane with LC_ALL=C. The problem occurred with svn-version on
Monday.

I put the debug message of `lyx -dbg any' and the problematic po
file at http://www.otaru-uc.ac.jp/~yokota/comp/lyx/debug.log and
http://www.otaru-uc.ac.jp/~yokota/comp/lyx/ja.po respectively.

Thanks in advance,

Koji

Re: Apparently sane po file makes lyx crash

2007-10-03 Thread Koji Yokota


Jean-Marc Lasgouttes wrote:

[[Context]] is used to distinguish otherwise identical strings, which could
have different translation dependent on the Context. [[Context]] appears only
in msgid string and should not be repeated in the translated version.
-

You should leave it as it was in the file:

#: src/support/filetools.cpp:313
msgid "[[Replace with the code of your language]]"
msgstr "ja"

It is used internally by LyX to find out what language has been
loaded.
  

JMarc,

It seems this was causing the problem.

Thank you for your help.


Juergen Spitzmueller wrote:

this is just to remind you that we need your translation by Friday.


I think I can post the updated message file for 1.5.2 by Friday(GMT) 
utilizing the location of Far East :)


Koji

Support request for Japanese without CJK (was: CJK-testers needed)

2007-08-07 Thread Koji Yokota


Uwe Stöhr wrote:
Thanks. Could you please post on the list when e.g. the Japanese 
package is on CTAN?


I expect it would be too late to support this package before LyX 1.5.0 
directly in LyX's menus, but I could then implement this for LyX 1.6.0.


thanks and regards
Uwe
Japanese package is now on CTAN 
(http://www.ctan.org/tex-archive/language/japanese/japanese/) and a 
Japanese-aware latex, jtex is also available there 
(http://www.ctan.org/tex-archive/language/japanese/jtex/).


Is it possible to provide an option for Japanese language to use the 
combination of jtex and japanese package in the next release? It means 
that Japanese language should be available without CJK nor inputenc 
package in Japanese encodings such as EUC-JP and JIS. It would be a 
great improvement to use lyx in Japanese.


Koji

Support request for Japanese without CJK (was: CJK-testers needed)

2007-08-07 Thread Koji Yokota


Uwe Stöhr wrote:
Thanks. Could you please post on the list when e.g. the Japanese 
package is on CTAN?


I expect it would be too late to support this package before LyX 1.5.0 
directly in LyX's menus, but I could then implement this for LyX 1.6.0.


thanks and regards
Uwe
Japanese package is now on CTAN 
(http://www.ctan.org/tex-archive/language/japanese/japanese/) and a 
Japanese-aware latex, jtex is also available there 
(http://www.ctan.org/tex-archive/language/japanese/jtex/).


Is it possible to provide an option for Japanese language to use the 
combination of jtex and japanese package in the next release? It means 
that Japanese language should be available without CJK nor inputenc 
package in Japanese encodings such as EUC-JP and JIS. It would be a 
great improvement to use lyx in Japanese.


Koji

1 2 3 >

1 - 100 of 212 matches

Mail list logo