Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 I hereby grant permission to use my contributions to LyX under the GPL
 license version 2 or later.

Thanks, your name shines in light now:
http://www.lyx.org/trac/changeset/26202
http://www.lyx.org/trac/changeset/26203

Of course we are looking forward to more improvements (not only) concerning 
the Japanese language support :-)

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 #4697:
 Recognition of platex binary when encoding is {EUC-JP|JIS|SJIS}-pLaTeX

 Partially fixed.

 The reporter, Koji Yokota-san, wants to pass encoding of an active LyX
 document to the converter 'platex' by an option, such as 'platex
 -kanji=euc'. However, the option is not implimented.

BTW this would be easy to implement: we would need to introduce an $$enc tag 
and use 'platex -kanji=$$enc $$i' as default command of pLaTeX.

The $$enc tag then just needed to be substituted with the given encoding (or 
the equivalent argument of -kanji). Cf. LaTeX::runMakeIndex for an example, 
where the $$lang tag is similarly handled.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> I hereby grant permission to use my contributions to LyX under the GPL
> license version 2 or later.

Thanks, your name shines in light now:
http://www.lyx.org/trac/changeset/26202
http://www.lyx.org/trac/changeset/26203

Of course we are looking forward to more improvements (not only) concerning 
the Japanese language support :-)

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> #4697:
> Recognition of platex binary when encoding is {EUC-JP|JIS|SJIS}-pLaTeX
>
> Partially fixed.
>
> The reporter, Koji Yokota-san, wants to pass encoding of an active LyX
> document to the converter 'platex' by an option, such as 'platex
> -kanji=euc'. However, the option is not implimented.

BTW this would be easy to implement: we would need to introduce an $$enc tag 
and use 'platex -kanji=$$enc $$i' as default command of pLaTeX.

The $$enc tag then just needed to be substituted with the given encoding (or 
the equivalent argument of -kanji). Cf. LaTeX::runMakeIndex for an example, 
where the $$lang tag is similarly handled.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Sat, 16 Aug 2008 13:38:05 +0200
Jürgen Spitzmüller [EMAIL PROTECTED] wrote:

 Tetsuya Makimura wrote:
  If you do not mind mixing of package name and language name used for
  babel, your patch works well.
 
 Good.
 
  === Note ==
  It is noted that there is no way to specify encoding of japanese
  characters.
 
 I do not understand this.

If you apply only your patch, you have no way to specfy an encoding of
Japanese characters in an English document, because your patch is
inteded for only selecting languages. So, You need additional codes
for selecting encodings. There is no problem anymore with
my patch or the patch you submitted
( http://bugzilla.lyx.org/attachment.cgi?id=2734action=view ).


  Therefore, the patch you have reverted would work well, although I
 have not tested it yet.

I have tested the patch. See below.
 
 OK, then I'm gonna apply this. Can I close these two bugs as well then?
 http://bugzilla.lyx.org/show_bug.cgi?id=4697
 http://bugzilla.lyx.org/show_bug.cgi?id=4863

#4697:
Recognition of platex binary when encoding is {EUC-JP|JIS|SJIS}-pLaTeX

Partially fixed.

The reporter, Koji Yokota-san, wants to pass encoding of an active LyX
document to the converter 'platex' by an option, such as 'platex
-kanji=euc'. However, the option is not implimented.

Instead, the encoding is selected by users in the GUI panel: (Document
- Settings- Language- Encoding: Other: Japanese (pLaTeX, EUC-JP)).
It is possible that executing a platex command for sjis encoding fails
to convert a file in euc encoding to a dvi file. Therefore, it would be
better to check available encodings by the lib/configure.py script.

#4863: jarticle cannot be found by configure.py even if installed
Fixed.

#4290: Configuration and preview support by pLaTeX
Fixed.

#4700: multilingual CJK broken
How about #4700 ?
I cannot find any problem anymore.

  [4]
  With my patch, LATEX is set to be 'platex' if PPLATEX ==''.
  Now I think the following script is better for latex users:
  --- configure.py ---
      if cmdOutput(PLATEX + ' chklatex.ltx').find('pLaTeX2e') != -1:
          # We have the Japanese pLaTeX2e
          addToRC(r'\converter japaneseplatex   dvi    %s   latex' %
  PLATEX)
  -       LATEX = PLATEX
  +       # LATEX = PLATEX
 Let's do this afterwards, if necessary.

OK.

  Could you please prepare a LyX file for testing the special
  characters ?
 
 Since we reimplemented CJK japanese, this is not urgent.

OK.

 As this is your first contribution to LyX, I need a license statement from 
 you 
 before I can commit the patch. A message to this list containing a statement 
 such as
 
 I hereby grant permission to use my contributions to LyX under the GPL
 license version 2 or later.
 
 will do.

I see. I will send the statement in a separate mail.


###
I have tested the patch you submitted
( http://bugzilla.lyx.org/attachment.cgi?id=2734action=view ) and
found no problem.
--
Note that the bullets 'o' indicate settings by lib/configure.py, while
the bullets '*' by users in the GUI panels.


$ svn info
Repository Root: svn://svn.lyx.org/lyx
Revision: 26196

$ patch -p0 ../2734.patch
$ make
$ rm -rf ~/lyx
$ src/lyx ../2720.lyx



requirements:
pLaTeX which can process \usepackage[japanese,english]{babel} and
\selectlanguage{japanese} . For example,  ptetex3.

Settings:
o Converter Definitions: LaTeX(plain) - DVI
  Converter: platex

o Tools - Preferences - Language Settings
  Default language: English
  Language package: \usepackage{babel}
  \selectlangauge{$$lang}

o Document - Settings - Language
  Language: English, Encoding: Language Default

results:
View - DVI OK
View - PDF (dvipdfm) OK
View - pdflatex (not available in my PC)
View - PDF (ps2pdf) OK
View - Postscript OK



setttings:

* Tools - Preferences - Language Settings
  Default language: Japanese
  (No) Use babel

* Tools - Preferences - Look  Feel
  Instant Preview: On

--- Quit and restart ---

* Document - Settings - Document Class
  Document class: jsarticle (Japanese New)

* Document - Settings - Language
  Language: Japanese
  Encoding: Language Default

results:

View - DVI OK
View - PDF (dvipdfm) OK
View - PDF (pdflatex) (not available in my PC or menu)
View - PDF(ps2pdf) OK

File - Export - LaTeX (pLaTeX)
a LaTeX file in encoding of JIS (ISO-2022-JP) is exported properly.

###
Further, encoding is explicitly specified.

settings:

* Document - Settings - Language
  Language: Japanese
  Encoding: Other: Japanese (pLaTeX, EUC-JP)

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Sat, 16 Aug 2008 13:38:05 +0200
Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
 
 As this is your first contribution to LyX, I need a license
statement from you 
 before I can commit the patch. A message to this list containing a statement 
 such as
 
 I hereby grant permission to use my contributions to LyX under the GPL
 license version 2 or later.
 
 will do.

I hereby grant permission to use my contributions to LyX under the GPL
license version 2 or later.

Betst regards,
Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 I have tested the patch.

It's in. I care about the rest (e.g. adding you to the credits ;-) tomorrow.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Sat, 16 Aug 2008 13:38:05 +0200
Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:

> Tetsuya Makimura wrote:
> > If you do not mind mixing of package name and language name used for
> > babel, your patch works well.
> 
> Good.
> 
> > === Note ==
> > It is noted that there is no way to specify encoding of japanese
> > characters.
> 
> I do not understand this.

If you apply only your patch, you have no way to specfy an encoding of
Japanese characters in an English document, because your patch is
inteded for only selecting languages. So, You need additional codes
for selecting encodings. There is no problem anymore with
my patch or the patch you submitted
( http://bugzilla.lyx.org/attachment.cgi?id=2734=view ).


> > Therefore, the patch you have reverted would work well, although I
>> have not tested it yet.

I have tested the patch. See below.
 
> OK, then I'm gonna apply this. Can I close these two bugs as well then?
> http://bugzilla.lyx.org/show_bug.cgi?id=4697
> http://bugzilla.lyx.org/show_bug.cgi?id=4863

#4697:
Recognition of platex binary when encoding is {EUC-JP|JIS|SJIS}-pLaTeX

Partially fixed.

The reporter, Koji Yokota-san, wants to pass encoding of an active LyX
document to the converter 'platex' by an option, such as 'platex
-kanji=euc'. However, the option is not implimented.

Instead, the encoding is selected by users in the GUI panel: (Document
-> Settings-> Language-> Encoding: Other: Japanese (pLaTeX, EUC-JP)).
It is possible that executing a platex command for sjis encoding fails
to convert a file in euc encoding to a dvi file. Therefore, it would be
better to check available encodings by the lib/configure.py script.

#4863: jarticle cannot be found by configure.py even if installed
Fixed.

#4290: Configuration and preview support by pLaTeX
Fixed.

#4700: multilingual CJK broken
How about #4700 ?
I cannot find any problem anymore.

> > [4]
> > With my patch, LATEX is set to be 'platex' if PPLATEX ==''.
> > Now I think the following script is better for latex users:
> > --- configure.py ---
> >     if cmdOutput(PLATEX + ' chklatex.ltx').find('pLaTeX2e') != -1:
> >         # We have the Japanese pLaTeX2e
> >         addToRC(r'\converter japaneseplatex   dvi    "%s"   "latex"' %
> > PLATEX)
> > -       LATEX = PLATEX
> > +       # LATEX = PLATEX
> Let's do this afterwards, if necessary.

OK.

> > Could you please prepare a LyX file for testing the special
> > characters ?
> 
> Since we reimplemented CJK japanese, this is not urgent.

OK.

> As this is your first contribution to LyX, I need a license statement from 
> you 
> before I can commit the patch. A message to this list containing a statement 
> such as
> 
> "I hereby grant permission to use my contributions to LyX under the GPL
> license version 2 or later."
> 
> will do.

I see. I will send the statement in a separate mail.


###
I have tested the patch you submitted
( http://bugzilla.lyx.org/attachment.cgi?id=2734=view ) and
found no problem.
--
Note that the bullets 'o' indicate settings by lib/configure.py, while
the bullets '*' by users in the GUI panels.


$ svn info
Repository Root: svn://svn.lyx.org/lyx
Revision: 26196

$ patch -p0 ../2734.patch
$ make
$ rm -rf ~/lyx
$ src/lyx ../2720.lyx



requirements:
pLaTeX which can process \usepackage[japanese,english]{babel} and
\selectlanguage{japanese} . For example,  ptetex3.

Settings:
o Converter Definitions: LaTeX(plain) -> DVI
  Converter: platex

o Tools -> Preferences -> Language Settings
  Default language: English
  Language package: \usepackage{babel}
  \selectlangauge{$$lang}

o Document -> Settings -> Language
  Language: English, Encoding: Language Default

results:
View -> DVI OK
View -> PDF (dvipdfm) OK
View -> pdflatex (not available in my PC)
View -> PDF (ps2pdf) OK
View -> Postscript OK



setttings:

* Tools -> Preferences -> Language Settings
  Default language: Japanese
  (No) Use babel

* Tools -> Preferences -> Look & Feel
  Instant Preview: On

--- Quit and restart ---

* Document -> Settings -> Document Class
  Document class: jsarticle (Japanese New)

* Document -> Settings -> Language
  Language: Japanese
  Encoding: Language Default

results:

View -> DVI OK
View -> PDF (dvipdfm) OK
View -> PDF (pdflatex) (not available in my PC or menu)
View -> PDF(ps2pdf) OK

File -> Export -> LaTeX (pLaTeX)
a LaTeX file in encoding of JIS (ISO-2022-JP) is exported properly.

###
Further, encoding is explicitly specified.

settings:

* Document -> 

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Sat, 16 Aug 2008 13:38:05 +0200
Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
 
> As this is your first contribution to LyX, I need a license
statement from you 
> before I can commit the patch. A message to this list containing a statement 
> such as
> 
> "I hereby grant permission to use my contributions to LyX under the GPL
> license version 2 or later."
> 
> will do.

I hereby grant permission to use my contributions to LyX under the GPL
license version 2 or later.

Betst regards,
Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> I have tested the patch.

It's in. I care about the rest (e.g. adding you to the credits ;-) tomorrow.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 If you do not mind mixing of package name and language name used for
 babel, your patch works well.

Good.

 === Note ==
 It is noted that there is no way to specify encoding of japanese
 characters.

I do not understand this.

 Therefore, the patch you have reverted would work well, although I have
 not tested it yet.

OK, then I'm gonna apply this. Can I close these two bugs as well then?
http://bugzilla.lyx.org/show_bug.cgi?id=4697
http://bugzilla.lyx.org/show_bug.cgi?id=4863

 [4]
 With my patch, LATEX is set to be 'platex' if PPLATEX ==''.
 Now I think the following script is better for latex users:
 --- configure.py ---
     if cmdOutput(PLATEX + ' chklatex.ltx').find('pLaTeX2e') != -1:
         # We have the Japanese pLaTeX2e
         addToRC(r'\converter japaneseplatex   dvi    %s   latex' %
 PLATEX)
 -       LATEX = PLATEX
 +       # LATEX = PLATEX

 In this case, users who use Japanese as a minor language needs to change
 settings as follows:

 LaTeX(plain) - DVI converter: platex

 or
 Document Setting - Language - Encoding -
 Other:Japanese (pLaTeX, EUC-JP), while Language: english

Let's do this afterwards, if necessary.

 Could you please prepare a LyX file for testing the special characters ?

Since we reimplemented CJK japanese, this is not urgent.

As this is your first contribution to LyX, I need a license statement from you 
before I can commit the patch. A message to this list containing a statement 
such as

I hereby grant permission to use my contributions to LyX under the GPL
license version 2 or later.

will do.

 Thank you.
 Tetsuya Makimura

Thanks for testing,
Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> If you do not mind mixing of package name and language name used for
> babel, your patch works well.

Good.

> === Note ==
> It is noted that there is no way to specify encoding of japanese
> characters.

I do not understand this.

> Therefore, the patch you have reverted would work well, although I have
> not tested it yet.

OK, then I'm gonna apply this. Can I close these two bugs as well then?
http://bugzilla.lyx.org/show_bug.cgi?id=4697
http://bugzilla.lyx.org/show_bug.cgi?id=4863

> [4]
> With my patch, LATEX is set to be 'platex' if PPLATEX ==''.
> Now I think the following script is better for latex users:
> --- configure.py ---
>     if cmdOutput(PLATEX + ' chklatex.ltx').find('pLaTeX2e') != -1:
>         # We have the Japanese pLaTeX2e
>         addToRC(r'\converter japaneseplatex   dvi    "%s"   "latex"' %
> PLATEX)
> -       LATEX = PLATEX
> +       # LATEX = PLATEX
>
> In this case, users who use Japanese as a minor language needs to change
> settings as follows:
>
> LaTeX(plain) -> DVI converter: platex
>
> or
> Document Setting -> Language -> Encoding ->
> Other:Japanese (pLaTeX, EUC-JP), while Language: english

Let's do this afterwards, if necessary.

> Could you please prepare a LyX file for testing the special characters ?

Since we reimplemented CJK japanese, this is not urgent.

As this is your first contribution to LyX, I need a license statement from you 
before I can commit the patch. A message to this list containing a statement 
such as

"I hereby grant permission to use my contributions to LyX under the GPL
license version 2 or later."

will do.

> Thank you.
> Tetsuya Makimura

Thanks for testing,
Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Tue, 29 Jul 2008 17:10:36 +0200
Jürgen Spitzmüller [EMAIL PROTECTED] wrote:

 The current status is that, without my patch applied, Japanese characters are 
 not encoded correctly if Japanese (i.e. the pLaTeX-variant) is chosen as a 
 foreign language in a non-Japanese (e.g. English) document.
 
 This is because Japanese is (IMHO) not correctly implemented in LyX.
 
 My patch aims at fixing this.
...
 Yes, it needs testing. I do not have pLaTeX installed, so all I can do is 
 judge from the LaTeX export.
 
 Could you please test if this testcase
 http://bugzilla.lyx.org/attachment.cgi?id=2720action=view
 
 is compiled correctly to DVI/PDF with my (or your) patch attached? And also, 
 if it's true that compilation fails without the patch?

If you do not mind mixing of package name and language name used for
babel, your patch works well.
[1] Without any patch Japanese characters are 'uncodable'.
[2] With your patch Japanese characters are codable.
[3] With my patch  Japanese characters are codable,
but test case lyx file needs to be modified slightly.
The patch that you revered my naming convention would work well
without the modification.

=== OS, compiler ===
Debian etch

=== LyX ===
$ svn info
URL: svn://svn.lyx.org/lyx/lyx-devel/trunk
Revision: 26122

=== platex ===
I used ptetex3, a recent version of platex package which can handle
bable: ( http://www.nn.iij4u.or.jp/~tutimura/tex/ptetex.html , 
http://tutimura.ath.cx/~nob/tex/ptetex/ptetex3/ptetex3-20080616.tar.gz )
based on tetex-texmf-3.0po.tar.gz and tetex-src-3.0.tar.gz .
There seems to be pdflatex which can convert Japanese characters in MS
Windows
( http://www.fsci.fuk.kindai.ac.jp/kakuto/win32-ptex/web2c75.html ),
but I have not tested it.

[1] Without any patch
$ rm -rf ~/.lyx
$ lyx 2720.lyx

=== settingsA===
- 
Document - Settings -
Language: Language: English, Encoding: Language Default

Tools - Preferences - Language Settings - Language:
Default language: English
Language package: \usepackage{babel}
\selectlanguage{$$lang}
=== results==
--- % Preview source code-
\selectlanguage{japanese}
LyX Warning: uncodable character 'NI'
LyX Warning:uncodable character 'HON'
LyX Warning: uncodable character 'GO'
-
File - Export - LaTeX (plain) fails with a message
Could not find LaTeX command for character 'NI' (code point 0x65e5).

=== settings B==
Document -Settigs - Language Language: japanese
Encoding: Other japanese(non-CJK)(EUC-JP)
---
Tools - Preferences - File Handling - Converters:
Converter Definitions - LaTeX (plain) - DVI:
converter: platex
---
results--
View -DVI OK Export LaTeX (plain) suceeds


[2] with your patch
$ patch -p0 ../2711.patch
$ make
$ rm -rf ~/.lyx
$ src/lyx ../2720.lyx

===settings=
--- same as the output of the configure script-
Document - Settings - Language - 
Language:english, Encoding: Language Default

--- same as the output of the configure script-
Tools - Preferences - Language Settings :
Default language: English
Language package: \usepackage{babel}
\selectlanguage{$$lang}

--- I changed the latex converter--
Tools - Preferences- FileHandling- Converters- 
Converter Difinitions - latex(plain)-DVI converter: platex

===results
View-DVI OK View-dvipdfm OK View-pdflatex (Not Available in my PC.)
View-ps2pdf OK View-Postscript OK

=== Note == 
It is noted that there is no way to specify encoding of japanese
characters.

[3] With my original patch that I posted last time

=== Test case file 2720.lyx ===
--- % Preview source code -
\selectlanguage {japanese}
 LyX Warning: uncodable character 'NI'
LyX Warning: uncodable character 'HON'
LyX Warning: uncodable character 'GO'

 
--- stdout or stderr --
Export fails with a message: LyX: Unknown language `japanese' ...

=== Thereofre, I need to modify test case file 2720.lyx ==
- \lang japanese
+ \lang japanese-platex
See also below[5].

--- same as the output of the configure script -
Document - Settings - Language - Language: english, Encoding:
Language Default

--- same as the output of the configure script --
Tools - Preferences - Language Settings : Default language: English

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Tue, 29 Jul 2008 17:10:36 +0200
Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:

> The current status is that, without my patch applied, Japanese characters are 
> not encoded correctly if "Japanese" (i.e. the pLaTeX-variant) is chosen as a 
> foreign language in a non-Japanese (e.g. English) document.
> 
> This is because Japanese is (IMHO) not correctly implemented in LyX.
> 
> My patch aims at fixing this.
...
> Yes, it needs testing. I do not have pLaTeX installed, so all I can do is 
> judge from the LaTeX export.
> 
> Could you please test if this testcase
> http://bugzilla.lyx.org/attachment.cgi?id=2720=view
> 
> is compiled correctly to DVI/PDF with my (or your) patch attached? And also, 
> if it's true that compilation fails without the patch?

If you do not mind mixing of package name and language name used for
babel, your patch works well.
[1] Without any patch Japanese characters are 'uncodable'.
[2] With your patch Japanese characters are codable.
[3] With my patch  Japanese characters are codable,
but test case lyx file needs to be modified slightly.
The patch that you revered my naming convention would work well
without the modification.

=== OS, compiler ===
Debian etch

=== LyX ===
$ svn info
URL: svn://svn.lyx.org/lyx/lyx-devel/trunk
Revision: 26122

=== platex ===
I used ptetex3, a recent version of platex package which can handle
bable: ( http://www.nn.iij4u.or.jp/~tutimura/tex/ptetex.html , 
http://tutimura.ath.cx/~nob/tex/ptetex/ptetex3/ptetex3-20080616.tar.gz )
based on tetex-texmf-3.0po.tar.gz and tetex-src-3.0.tar.gz .
There seems to be pdflatex which can convert Japanese characters in MS
Windows
( http://www.fsci.fuk.kindai.ac.jp/kakuto/win32-ptex/web2c75.html ),
but I have not tested it.

[1] Without any patch
$ rm -rf ~/.lyx
$ lyx 2720.lyx

=== settingsA===
- 
Document -> Settings ->
Language: Language: English, Encoding: Language Default

Tools -> Preferences -> Language Settings -> Language:
Default language: English
Language package: \usepackage{babel}
\selectlanguage{$$lang}
=== results==
--- % Preview source code-
\selectlanguage{japanese}



-
File -> Export -> LaTeX (plain) fails with a message
"Could not find LaTeX command for character 'NI' (code point 0x65e5)."

=== settings B==
Document ->Settigs -> Language Language: japanese
Encoding: Other japanese(non-CJK)(EUC-JP)
---
Tools -> Preferences -> File Handling -> Converters:
Converter Definitions -> LaTeX (plain) -> DVI:
converter: platex
---
results--
View ->DVI OK Export LaTeX (plain) suceeds


[2] with your patch
$ patch -p0 ../2711.patch
$ make
$ rm -rf ~/.lyx
$ src/lyx ../2720.lyx

===settings=
--- same as the output of the configure script-
Document -> Settings -> Language -> 
Language:english, Encoding: Language Default

--- same as the output of the configure script-
Tools -> Preferences -> Language Settings :
Default language: English
Language package: \usepackage{babel}
\selectlanguage{$$lang}

--- I changed the latex converter--
Tools -> Preferences-> FileHandling-> Converters-> 
Converter Difinitions -> latex(plain)->DVI converter: platex

===results
View->DVI OK View->dvipdfm OK View->pdflatex (Not Available in my PC.)
View->ps2pdf OK View->Postscript OK

=== Note == 
It is noted that there is no way to specify encoding of japanese
characters.

[3] With my original patch that I posted last time

=== Test case file 2720.lyx ===
--- % Preview source code -
\selectlanguage {japanese}
 



 
--- stdout or stderr --
Export fails with a message: LyX: Unknown language `japanese' ...

=== Thereofre, I need to modify test case file 2720.lyx ==
- \lang japanese
+ \lang japanese-platex
See also below[5].

--- same as the output of the configure script -
Document -> Settings -> Language -> Language: english, Encoding:
Language Default

--- same as the output of the configure script --
Tools -> Preferences -> Language Settings : Default language: English
Language package: \usepackage{babel}
\selectlanguage{$$lang}

--- Note that the latex converter is configured to be platex -
Tools -> Preferences -> File Handling-> 

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller [EMAIL PROTECTED] wrote:

  Anyway, this is the big chance for Japanse to use LyX.
  I will read the disuccusion on the bug and may contribute to squash it.
  But you may be faster to solve it becuase you knows LyX much better.
 
 But I don't know Japanese and the pLaTeX :-)
 
 Jürgen
 

Hi, Jürgen.

I have read http://bugzilla.lyx.org/show_bug.cgi?id=4700 ,
but I can not understand the current status.

Could you please explain the current status ?

In the #22 comment,
You have written a patch:
http://bugzilla.lyx.org/attachment.cgi?id=2711action=view .

With the patch,

The Japanese characters are shown in the source code window without any
warning.

A LaTeX (plain) file exported via File-Export-LaTeX (plain) can be
converted by Japanese platex command to a dvi file.

I need some settings via GUI panels for the above prcedures.

What is the problem with your path ?
You just need testing the patch by users ?

Thank you.

Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 Hi, Jürgen.

Hi Tetsuya,

 I have read http://bugzilla.lyx.org/show_bug.cgi?id=4700 ,
 but I can not understand the current status.

 Could you please explain the current status ?

The current status is that, without my patch applied, Japanese characters are 
not encoded correctly if Japanese (i.e. the pLaTeX-variant) is chosen as a 
foreign language in a non-Japanese (e.g. English) document.

This is because Japanese is (IMHO) not correctly implemented in LyX.

My patch aims at fixing this.

 In the #22 comment,
 You have written a patch:
 http://bugzilla.lyx.org/attachment.cgi?id=2711action=view .

 With the patch,

 The Japanese characters are shown in the source code window without any
 warning.

 A LaTeX (plain) file exported via File-Export-LaTeX (plain) can be
 converted by Japanese platex command to a dvi file.

 I need some settings via GUI panels for the above prcedures.

 What is the problem with your path ?
 You just need testing the patch by users ?

Yes, it needs testing. I do not have pLaTeX installed, so all I can do is 
judge from the LaTeX export.

Could you please test if this testcase
http://bugzilla.lyx.org/attachment.cgi?id=2720action=view

is compiled correctly to DVI/PDF with my (or your) patch attached? And also, 
if it's true that compilation fails without the patch?

Also, I would be interested to know if it works if languages with special 
characters (French, German, etc.) are involved?

Thanks
Jürgen

 Thank you.

 Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:

> > Anyway, this is the big chance for Japanse to use LyX.
> > I will read the disuccusion on the bug and may contribute to squash it.
> > But you may be faster to solve it becuase you knows LyX much better.
> 
> But I don't know Japanese and the pLaTeX :-)
> 
> Jürgen
> 

Hi, Jürgen.

I have read http://bugzilla.lyx.org/show_bug.cgi?id=4700 ,
but I can not understand the current status.

Could you please explain the current status ?

In the #22 comment,
You have written a patch:
http://bugzilla.lyx.org/attachment.cgi?id=2711=view .

With the patch,

The Japanese characters are shown in the source code window without any
warning.

A LaTeX (plain) file exported via File->Export->LaTeX (plain) can be
converted by Japanese "platex" command to a dvi file.

I need some settings via GUI panels for the above prcedures.

What is the problem with your path ?
You just need testing the patch by users ?

Thank you.

Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> Hi, Jürgen.

Hi Tetsuya,

> I have read http://bugzilla.lyx.org/show_bug.cgi?id=4700 ,
> but I can not understand the current status.
>
> Could you please explain the current status ?

The current status is that, without my patch applied, Japanese characters are 
not encoded correctly if "Japanese" (i.e. the pLaTeX-variant) is chosen as a 
foreign language in a non-Japanese (e.g. English) document.

This is because Japanese is (IMHO) not correctly implemented in LyX.

My patch aims at fixing this.

> In the #22 comment,
> You have written a patch:
> http://bugzilla.lyx.org/attachment.cgi?id=2711=view .
>
> With the patch,
>
> The Japanese characters are shown in the source code window without any
> warning.
>
> A LaTeX (plain) file exported via File->Export->LaTeX (plain) can be
> converted by Japanese "platex" command to a dvi file.
>
> I need some settings via GUI panels for the above prcedures.
>
> What is the problem with your path ?
> You just need testing the patch by users ?

Yes, it needs testing. I do not have pLaTeX installed, so all I can do is 
judge from the LaTeX export.

Could you please test if this testcase
http://bugzilla.lyx.org/attachment.cgi?id=2720=view

is compiled correctly to DVI/PDF with my (or your) patch attached? And also, 
if it's true that compilation fails without the patch?

Also, I would be interested to know if it works if languages with special 
characters (French, German, etc.) are involved?

Thanks
Jürgen

> Thank you.
>
> Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Subject: Re: Support request for Japanese without CJK, again
(Re: [Fwd: About Japanese edition ...)
Jürgen Spitzmuller wrote on 2008-07-21 17:26:56 GMT

 Looks like we are getting there.

 I have only some minor formal comments. Could you have a look, change that, 
 and please resend the patch as a real attachment (not inline) and without the 
 changes from my patch #2678? Then I can commit it to my tree and test the 
 thing.

Jürgen, thank you for your comments.

What do you mean by the phrase 'without the change from my patch
#2678' ?

I will post a patch against the svn revision 25916. The patch includes
further modifications since the last post:

[A] A file converter from Japanese pLaTeX file in a buffer to bitmap
images for previewing.

[B] Names of identifiers.  I renamed the term 'japanese' more
distinguishable ones by the following two resions. I do not mind if
you revert the changes so that you will be able to maintain LyX
easier.

[B1] 'japanese' is ambiguous in the current svn source tree and your
patch.  Currently, 'japanese' indicates

(a) Encoding::japanese
A package name, which declares that Japanese LaTeX file is used and the
'platex' command is invoked. It also assure that a Japanese class file
is used.
== Encoding::japanese_platex

(b) features.isRequired(japanese); features.required(japanese);
In this context, japanese is a language name in bable and inputenc.
In addition, OutputParams::use_japanese = features.isRequired
(japanese); == I keep them as they are, that is, japanese. This
can be used as option name in the \usepackage command.

(c) language()-lang() == japanese
A language name derived from the first column in the file configuration
file lib/language.
== japanese-platex

(d) Provides japanese 1
== I keep them as they are.

[B2] There is another latex variant called 'JLaTeX'. It is developed by
a NTT group, who put emphasis on compatibility to the original LaTeX,
while pLaTeX is less compatible but have higher quality. Therefore,
'jlatex' means JLaTeX, and 'japanese-plain' implys JLaTeX more.


Tetsuya Makimura wrote:
 Index: src/Buffer.cpp
 ===
 --- src/Buffer.cpp  (revision 25709)
 +++ src/Buffer.cpp  (working copy)
 @@ -1079,6 +1079,8 @@
 // Write the preamble
 runparams.use_babel = params().writeLaTeX(os, features, d-texrow);

 +   runparams.use_japanese = features.isRequired(japanese);
 +
 if (!output_body)
 return;

 @@ -2299,6 +2301,9 @@
 return docbook;
 if (isLiterate())
 return literate;
 +   // if( isPLATEX() )
 +   if ( params().encoding().package() == Encoding::japanese )
 +   return jlatex;
 return latex;
  }

 You could also use

 OutputParams runparams(params().encoding());
 if (runparams.use_japanese)
   return jlatex;

Strikes me slightly better, but it's probably a matter of taste.

The following two should be distinguishable:

japanese in features are used as a language name
according to the sentence
   runparams.use_japanese = features.isRequired(japanese);
The name have been used in the context of babel and inputenc.

Encoding::japanese is a 'package' name, which involves that it requires
the Japanese platex as converter from *.tex to *.dvi. Further, 'Package'
is not appropriate anymore because pLaTeX does not require any special
package. It should be a 'Language Extention'.

 Index: src/BufferParams.cpp
 ===
 --- src/BufferParams.cpp(revision 25709)
 +++ src/BufferParams.cpp(working copy)
 @@ -1055,6 +1055,8 @@
 os  \\usepackage[  from_ascii(lyxrc.fontenc)
 ,LFE,LAE]{fontenc}\n;
 texrow.newline();
 +   }else if (language-lang() == japanese){
 +   ; // do nothing.

rather use

   if (lyxrc.fontenc != default  language-lang() != japanese) {

O.K.

 Index: lib/languages
 ===
 --- lib/languages   (revision 25709)
 +++ lib/languages   (working copy)
 @@ -52,7 +52,7 @@
  interlingua   interlingua  Interlingua   false  iso8859-15 ia 
  irish   irish  Irish false  iso8859-15 ga_IE  
  italian italianItalian   false  iso8859-15 it_IT  
 -japanesejapanese   Japanese  false  jis-plain ja_JP   
 +japanesejapanese   Japanese  false  jis-platex ja_JP  

There's no need to rename the encoding.
...
dito.

Although you inteded that pLaTeX do not require any package and hence
that it is plain, we have anothor plain latex variant called JLaTeX, as
mentioned above.

Thank you.
Tetsuya Makimura
Index: src/graphics/PreviewLoader.cpp
===
--- src/graphics/PreviewLoader.cpp	(revision 25916)
+++ src/graphics/PreviewLoader.cpp	(working copy)
@@ -67,9 +67,9 @@
 }
 
 
-lyx::Converter const * setConverter()
+lyx::Converter const * setConverter(string const from

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Mon, 28 Jul 2008 17:26:32 +0200
Jürgen Spitzmüller [EMAIL PROTECTED] wrote:

 Tetsuya Makimura wrote:
  What do you mean by the phrase 'without the change from my patch
  #2678' ?
 
 Well, that patch addresses a different problem, and I'd like to keep the 
 patches separate, if possible.

http://bugzilla.lyx.org/show_bug.cgi?id=4700 ?
I have just noticed it today while reading a post by Abdelrazak
Younes. The patch ID(2678) was not enough for me.
 
 Also, they all refer to the same kind of japanese support (i.e., 
 non-CJK support).
Today, it is true. But maybe not in the near future; It's
difficult to keep up with the original latex system using pLaTeX,
and we have several latex candidates other than pLaTeX.

 I have done some further tweaks (mostly whitespace and coding style issues), 
 an updated patch is attached.
 
 I'm gonna upload this to bugzilla and ask for some more testing.

Thanks a lot.
Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
  Well, that patch addresses a different problem, and I'd like to keep the
  patches separate, if possible.

 http://bugzilla.lyx.org/show_bug.cgi?id=4700 ?
 I have just noticed it today while reading a post by Abdelrazak
 Younes. The patch ID(2678) was not enough for me.

So what's missing?

  Also, they all refer to the same kind of japanese support (i.e.,
  non-CJK support).

 Today, it is true. But maybe not in the near future; It's
 difficult to keep up with the original latex system using pLaTeX,
 and we have several latex candidates other than pLaTeX.

We'll see then.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Mon, 28 Jul 2008 18:45:44 +0200
Jürgen Spitzmüller [EMAIL PROTECTED] wrote:

 Tetsuya Makimura wrote:
   Well, that patch addresses a different problem, and I'd like to keep the
   patches separate, if possible.
 
  http://bugzilla.lyx.org/show_bug.cgi?id=4700 ?
  I have just noticed it today while reading a post by Abdelrazak
  Younes. The patch ID(2678) was not enough for me.
 
 So what's missing?

I tried to reach the bug report using the patch ID and some keywords.
But I could not find a way in the bugzilla. I needed the bug ID.

Anyway, this is the big chance for Japanse to use LyX.
I will read the disuccusion on the bug and may contribute to squash it.
But you may be faster to solve it becuase you knows LyX much better.

Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 I tried to reach the bug report using the patch ID and some keywords.
 But I could not find a way in the bugzilla. I needed the bug ID.

 Anyway, this is the big chance for Japanse to use LyX.
 I will read the disuccusion on the bug and may contribute to squash it.
 But you may be faster to solve it becuase you knows LyX much better.

But I don't know Japanese and the pLaTeX :-)

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Subject: Re: Support request for Japanese without CJK, again
(Re: [Fwd: About Japanese edition ...)
Jürgen Spitzmuller wrote on 2008-07-21 17:26:56 GMT

> Looks like we are getting there.
>
> I have only some minor formal comments. Could you have a look, change that, 
> and please resend the patch as a real attachment (not inline) and without the 
> changes from my patch #2678? Then I can commit it to my tree and test the 
> thing.

Jürgen, thank you for your comments.

What do you mean by the phrase 'without the change from my patch
#2678' ?

I will post a patch against the svn revision 25916. The patch includes
further modifications since the last post:

[A] A file converter from Japanese pLaTeX file in a buffer to bitmap
images for previewing.

[B] Names of identifiers.  I renamed the term 'japanese' more
distinguishable ones by the following two resions. I do not mind if
you revert the changes so that you will be able to maintain LyX
easier.

[B1] 'japanese' is ambiguous in the current svn source tree and your
patch.  Currently, 'japanese' indicates

(a) Encoding::japanese
A package name, which declares that Japanese LaTeX file is used and the
'platex' command is invoked. It also assure that a Japanese class file
is used.
==> Encoding::japanese_platex

(b) features.isRequired("japanese"); features.required("japanese");
In this context, "japanese" is a language name in bable and inputenc.
In addition, OutputParams::use_japanese = features.isRequired
("japanese"); ==> I keep them as they are, that is, "japanese". This
can be used as option name in the \usepackage command.

(c) language()->lang() == "japanese"
A language name derived from the first column in the file configuration
file lib/language.
==> "japanese-platex"

(d) Provides japanese 1
==> I keep them as they are.

[B2] There is another latex variant called 'JLaTeX'. It is developed by
a NTT group, who put emphasis on compatibility to the original LaTeX,
while pLaTeX is less compatible but have higher quality. Therefore,
'jlatex' means JLaTeX, and 'japanese-plain' implys JLaTeX more.


>Tetsuya Makimura wrote:
>> Index: src/Buffer.cpp
>> ===
>> --- src/Buffer.cpp  (revision 25709)
>> +++ src/Buffer.cpp  (working copy)
>> @@ -1079,6 +1079,8 @@
>> // Write the preamble
>> runparams.use_babel = params().writeLaTeX(os, features, d->texrow);
>>
>> +   runparams.use_japanese = features.isRequired("japanese");
>> +
>> if (!output_body)
>> return;
>>
>> @@ -2299,6 +2301,9 @@
>> return "docbook";
>> if (isLiterate())
>> return "literate";
>> +   // if( isPLATEX() )
>> +   if ( params().encoding().package() == Encoding::japanese )
>> +   return "jlatex";
>> return "latex";
>>  }
>
> You could also use
>
> OutputParams runparams(().encoding());
> if (runparams.use_japanese)
>   return "jlatex";
>
>Strikes me slightly better, but it's probably a matter of taste.

The following two should be distinguishable:

"japanese" in features are used as a language name
according to the sentence
   runparams.use_japanese = features.isRequired("japanese");
The name have been used in the context of babel and inputenc.

Encoding::japanese is a 'package' name, which involves that it requires
the Japanese platex as converter from *.tex to *.dvi. Further, 'Package'
is not appropriate anymore because pLaTeX does not require any special
package. It should be a 'Language Extention'.

>> Index: src/BufferParams.cpp
>> ===
>> --- src/BufferParams.cpp(revision 25709)
>> +++ src/BufferParams.cpp(working copy)
>> @@ -1055,6 +1055,8 @@
>> os << "\\usepackage[" << from_ascii(lyxrc.fontenc)
>><< ",LFE,LAE]{fontenc}\n";
>> texrow.newline();
>> +   }else if (language->lang() == "japanese"){
>> +   ; // do nothing.
>
>rather use
>
>   if (lyxrc.fontenc != "default" && language->lang() != "japanese") {

O.K.

>> Index: lib/languages
>> ===
>> --- lib/languages   (revision 25709)
>> +++ lib/languages   (working copy)
>> @@ -52,7 +52,7 @@
>>  interlingua   interlingua  "Interlingua"   false  iso8859-15 ia ""
>>  irish   irish  "Irish" false  iso8859-15 ga_IE  ""
>>  italian

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Mon, 28 Jul 2008 17:26:32 +0200
Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:

> Tetsuya Makimura wrote:
> > What do you mean by the phrase 'without the change from my patch
> > #2678' ?
> 
> Well, that patch addresses a different problem, and I'd like to keep the 
> patches separate, if possible.

http://bugzilla.lyx.org/show_bug.cgi?id=4700 ?
I have just noticed it today while reading a post by Abdelrazak
Younes. The patch ID(2678) was not enough for me.
 
> Also, they all refer to the same kind of "japanese" support (i.e., 
> non-CJK support).
Today, it is true. But maybe not in the near future; It's
difficult to keep up with the original latex system using pLaTeX,
and we have several latex candidates other than pLaTeX.

> I have done some further tweaks (mostly whitespace and coding style issues), 
> an updated patch is attached.
> 
> I'm gonna upload this to bugzilla and ask for some more testing.

Thanks a lot.
Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> > Well, that patch addresses a different problem, and I'd like to keep the
> > patches separate, if possible.
>
> http://bugzilla.lyx.org/show_bug.cgi?id=4700 ?
> I have just noticed it today while reading a post by Abdelrazak
> Younes. The patch ID(2678) was not enough for me.

So what's missing?

> > Also, they all refer to the same kind of "japanese" support (i.e.,
> > non-CJK support).
>
> Today, it is true. But maybe not in the near future; It's
> difficult to keep up with the original latex system using pLaTeX,
> and we have several latex candidates other than pLaTeX.

We'll see then.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

On Mon, 28 Jul 2008 18:45:44 +0200
Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:

> Tetsuya Makimura wrote:
> > > Well, that patch addresses a different problem, and I'd like to keep the
> > > patches separate, if possible.
> >
> > http://bugzilla.lyx.org/show_bug.cgi?id=4700 ?
> > I have just noticed it today while reading a post by Abdelrazak
> > Younes. The patch ID(2678) was not enough for me.
> 
> So what's missing?

I tried to reach the bug report using the patch ID and some keywords.
But I could not find a way in the bugzilla. I needed the bug ID.

Anyway, this is the big chance for Japanse to use LyX.
I will read the disuccusion on the bug and may contribute to squash it.
But you may be faster to solve it becuase you knows LyX much better.

Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> I tried to reach the bug report using the patch ID and some keywords.
> But I could not find a way in the bugzilla. I needed the bug ID.
>
> Anyway, this is the big chance for Japanse to use LyX.
> I will read the disuccusion on the bug and may contribute to squash it.
> But you may be faster to solve it becuase you knows LyX much better.

But I don't know Japanese and the pLaTeX :-)

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller [EMAIL PROTECTED] writes:

 First, we need to use our LaTeXFeatures 
 mechanism to tell LyX that we use the 
 japanese package. I've done that 
 in the following patch, which is not applied 
 yet (since it still needs testing):
 http://bugzilla.lyx.org/attachment.cgi?id=2678action=view

Hi, Jürgen.
Thank you very much for your patch.

Based on your patch #2678, I implemented automatic configuration, as attached
below. As you suggested, I added jlatex format and a converter from jlatex to
dvi in lib/configure.py. In addition, I rewrote the script to detect Japanese
pLaTeX by itself without any option.

 Using this, you could then specify
 e.g. in Buffer::doExport and probably other 
 places, where this is needed:
 
   } else {
   backend_format = format;
   // FIXME: Don't hardcode format names here, but use a flag
   if (backend_format == pdflatex)
   runparams.flavor = OutputParams::PDFLATEX;
 + else if (runparams.use_japanese)
 + runparams.flavor = OutputParams::PLATEX;
   }

If you are going to pass runparams to theConverters().convert
as an additional argument, your codes above will works fine.
It is noted that the converter do not have any way to detect the flavor:
in the function Buffer::doExport
bool const success = theConverters().convert(this, FileName(filename),
tmp_result_file, FileName(absFileName()), backend_format, format,
error_list);


Instead, I have changed the function Buffer::bufferFormat() using the file
format 'jlatex' that you introduced:
string Buffer::bufferFormat() const
{
if (isDocBook())
return docbook;
if (isLiterate())
return literate;
// if( isPLATEX() )
if ( params().encoding().package() == Encoding::japanese )
return jlatex;
return latex;
}

Although OutputParams::flavor is used to adjust LaTeX source codes
to fit converters, OupputParam::PLATEX uses just the codes
as OutputParam::LATEX does. The exceptions are babel, inputenc and CJK,
which are processed by language, encoding and package not by flavor.

 I guess you will need to go further through the code.
 Flavor is spreaded all 
 over the place, but I'm sure it can be implemented this way.
 
  Therefore, there should be a way for platex users to specify flavor
  manually, say, in a GUI panel.
 
 I think we can do better.

In your framework, 'platex' is selected by 
Document-Settings-Language--{Language,Encoding}
in the Document Settings panel.

Thank you.
Tetsuya Makimura

Note that \\\ indicates continued lines.
###
Index: src/OutputParams.h
===
--- src/OutputParams.h  (revision 25709)
+++ src/OutputParams.h  (working copy)
@@ -98,6 +98,10 @@
*/
bool use_babel;
 
+   /** Are we using japanese (pLaTeX)?
+   */
+   bool use_japanese;
+
/** Line length to use with plaintext export.
*/
size_type linelen;
Index: src/LaTeXFeatures.cpp
===
--- src/LaTeXFeatures.cpp   (revision 25709)
+++ src/LaTeXFeatures.cpp   (working copy)
@@ -379,6 +379,9 @@
// They use the CJK package
if (lang-encoding()-package() == Encoding::CJK)
require(CJK);
+   // japanese package is special
+   if (lang-encoding()-package() == Encoding::japanese)
+   require(japanese);
 }
 
 
@@ -420,7 +423,8 @@
LanguageList::const_iterator end = UsedLanguages_.end();
for (; it != end; ++it)
if ((*it)-encoding()-latexName() != doc_encoding 
-   (*it)-encoding()-package() == Encoding::inputenc)
+   ((*it)-encoding()-package() == Encoding::inputenc
+|| (*it)-encoding()-package() == Encoding::japanese))
encodings.insert((*it)-encoding()-latexName());
return encodings;
 }
@@ -582,7 +586,7 @@
 
// setspace.sty
if (mustProvide(setspace)  !tclass.provides(SetSpace))
-packages  \\usepackage{setspace}\n;
+   packages  \\usepackage{setspace}\n;
 
// amssymb.sty
if (mustProvide(amssymb)
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(revision 25709)
+++ src/output_latex.cpp(working copy)
@@ -900,6 +900,7 @@
docstring const inputenc_arg(from_ascii(newEnc.latexName()));
switch (newEnc.package()) {
case Encoding::none:
+   case Encoding::japanese:
// shouldn't ever reach here, see above
return make_pair(true, 0);
case Encoding::inputenc: {
@@ -923,6 +924,9 @@
count += 7;
open_encoding_ = inputenc;
}
+   // with the japanese option, inputenc is ommitted.
+   if (runparams.use_japanese)
+   return make_pair(true, count);
os  \\inputencoding{  inputenc_arg  '}';

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Many Thanks, Tetsyua. 

Looks like we are getting there.

I have only some minor formal comments. Could you have a look, change that, 
and please resend the patch as a real attachment (not inline) and without the 
changes from my patch #2678? Then I can commit it to my tree and test the 
thing.

Tetsuya Makimura wrote:
 Index: src/Buffer.cpp
 ===
 --- src/Buffer.cpp  (revision 25709)
 +++ src/Buffer.cpp  (working copy)
 @@ -1079,6 +1079,8 @@
 // Write the preamble
 runparams.use_babel = params().writeLaTeX(os, features, d-texrow);

 +   runparams.use_japanese = features.isRequired(japanese);
 +
 if (!output_body)
 return;

 @@ -2299,6 +2301,9 @@
 return docbook;
 if (isLiterate())
 return literate;
 +   // if( isPLATEX() )
 +   if ( params().encoding().package() == Encoding::japanese )
 +   return jlatex;
 return latex;
  }

You could also use

OutputParams runparams(params().encoding());
if (runparams.use_japanese)
return jlatex;

Strikes me slightly better, but it's probably a matter of taste.

 Index: src/BufferParams.cpp
 ===
 --- src/BufferParams.cpp(revision 25709)
 +++ src/BufferParams.cpp(working copy)
 @@ -1055,6 +1055,8 @@
 os  \\usepackage[  from_ascii(lyxrc.fontenc)
 ,LFE,LAE]{fontenc}\n;
 texrow.newline();
 +   }else if (language-lang() == japanese){
 +   ; // do nothing.

rather use

if (lyxrc.fontenc != default  language-lang() != japanese) {

 Index: lib/languages
 ===
 --- lib/languages   (revision 25709)
 +++ lib/languages   (working copy)
 @@ -52,7 +52,7 @@
  interlingua   interlingua  Interlingua   false  iso8859-15 ia 
  irish   irish  Irish false  iso8859-15 ga_IE  
  italian italianItalian   false  iso8859-15 it_IT  
 -japanesejapanese   Japanese  false  jis-plain ja_JP   
 +japanesejapanese   Japanese  false  jis-platex ja_JP  

There's no need to rename the encoding.

 %%document Index: lib/encodings
 ===
 --- lib/encodings   (revision 25709)
 +++ lib/encodings   (working copy)
 @@ -173,11 +173,11 @@

  # Traditional Japanese TeX programs require neither CJK nor inputenc
  # package.
 -Encoding euc-jp-plain EUC-JP-pLaTeX \\\
   Japanese (non-CJK) (EUC-JP) EUC-JP variable
 none +Encoding euc-jp-platex EUC-JP-pLaTeX \\\
 Japanese (pLaTeX, EUC-JP) EUC-JP variable
 japanese End
 -Encoding jis-plain JIS-pLaTeX \\\
Japanese (non-CJK) (JIS) ISO-2022-JP variable none
 +Encoding jis-platex JIS-pLaTeX \\\
  Japanese (pLaTeX, JIS) ISO-2022-JP variable japanese
  End
 -Encoding shift-jis-plain SJIS-pLaTeX \\\
Japanese (non-CJK) (SJIS) CP932 variable none
 +Encoding shift-jis-platex SJIS-pLaTeX \\\
  Japanese (pLaTeX, SJIS) CP932 variable japanese
  End

dito.

  # This one needs hardcoded support, since the inputenc package does not
 know
 ###

Thanks,
Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:

> First, we need to use our LaTeXFeatures 
> mechanism to tell LyX that we use the 
> japanese package. I've done that 
> in the following patch, which is not applied 
> yet (since it still needs testing):
> http://bugzilla.lyx.org/attachment.cgi?id=2678=view

Hi, Jürgen.
Thank you very much for your patch.

Based on your patch #2678, I implemented automatic configuration, as attached
below. As you suggested, I added jlatex format and a converter from jlatex to
dvi in lib/configure.py. In addition, I rewrote the script to detect Japanese
pLaTeX by itself without any option.

> Using this, you could then specify
> e.g. in Buffer::doExport and probably other 
> places, where this is needed:
> 
>   } else {
>   backend_format = format;
>   // FIXME: Don't hardcode format names here, but use a flag
>   if (backend_format == "pdflatex")
>   runparams.flavor = OutputParams::PDFLATEX;
> + else if (runparams.use_japanese)
> + runparams.flavor = OutputParams::PLATEX;
>   }

If you are going to pass runparams to theConverters().convert
as an additional argument, your codes above will works fine.
It is noted that the converter do not have any way to detect the flavor:
in the function Buffer::doExport
bool const success = theConverters().convert(this, FileName(filename),
tmp_result_file, FileName(absFileName()), backend_format, format,
error_list);


Instead, I have changed the function Buffer::bufferFormat() using the file
format 'jlatex' that you introduced:
string Buffer::bufferFormat() const
{
if (isDocBook())
return "docbook";
if (isLiterate())
return "literate";
// if( isPLATEX() )
if ( params().encoding().package() == Encoding::japanese )
return "jlatex";
return "latex";
}

Although OutputParams::flavor is used to adjust LaTeX source codes
to fit converters, OupputParam::PLATEX uses just the codes
as OutputParam::LATEX does. The exceptions are babel, inputenc and CJK,
which are processed by language, encoding and package not by flavor.

> I guess you will need to go further through the code.
> Flavor is spreaded all 
> over the place, but I'm sure it can be implemented this way.
> 
> > Therefore, there should be a way for platex users to specify flavor
> > manually, say, in a GUI panel.
> 
> I think we can do better.

In your framework, 'platex' is selected by 
Document->Settings->Language->->{Language,Encoding}
in the Document Settings panel.

Thank you.
Tetsuya Makimura

Note that \\\ indicates continued lines.
###
Index: src/OutputParams.h
===
--- src/OutputParams.h  (revision 25709)
+++ src/OutputParams.h  (working copy)
@@ -98,6 +98,10 @@
*/
bool use_babel;
 
+   /** Are we using japanese (pLaTeX)?
+   */
+   bool use_japanese;
+
/** Line length to use with plaintext export.
*/
size_type linelen;
Index: src/LaTeXFeatures.cpp
===
--- src/LaTeXFeatures.cpp   (revision 25709)
+++ src/LaTeXFeatures.cpp   (working copy)
@@ -379,6 +379,9 @@
// They use the CJK package
if (lang->encoding()->package() == Encoding::CJK)
require("CJK");
+   // japanese package is special
+   if (lang->encoding()->package() == Encoding::japanese)
+   require("japanese");
 }
 
 
@@ -420,7 +423,8 @@
LanguageList::const_iterator end = UsedLanguages_.end();
for (; it != end; ++it)
if ((*it)->encoding()->latexName() != doc_encoding &&
-   (*it)->encoding()->package() == Encoding::inputenc)
+   ((*it)->encoding()->package() == Encoding::inputenc
+|| (*it)->encoding()->package() == Encoding::japanese))
encodings.insert((*it)->encoding()->latexName());
return encodings;
 }
@@ -582,7 +586,7 @@
 
// setspace.sty
if (mustProvide("setspace") && !tclass.provides("SetSpace"))
-packages << "\\usepackage{setspace}\n";
+   packages << "\\usepackage{setspace}\n";
 
// amssymb.sty
if (mustProvide("amssymb")
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(revision 25709)
+++ src/output_latex.cpp(working copy)
@@ -900,6 +900,7 @@
docstring const inputenc_arg(from_ascii(newEnc.latexName()));
switch (newEnc.package()) {
case Encoding::none:
+   case Encoding::japanese:
// shouldn't ever reach here, see above
return make_pair(true, 0);
case Encoding::inputenc: {
@@ -923,6 +924,9 @@
count += 7;
open_encoding_ = inputenc;
}
+   // with the japanese option, inputenc is ommitted.
+   if (runparams.use_japanese)
+   return make_pair(true, 

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Many Thanks, Tetsyua. 

Looks like we are getting there.

I have only some minor formal comments. Could you have a look, change that, 
and please resend the patch as a real attachment (not inline) and without the 
changes from my patch #2678? Then I can commit it to my tree and test the 
thing.

Tetsuya Makimura wrote:
> Index: src/Buffer.cpp
> ===
> --- src/Buffer.cpp  (revision 25709)
> +++ src/Buffer.cpp  (working copy)
> @@ -1079,6 +1079,8 @@
> // Write the preamble
> runparams.use_babel = params().writeLaTeX(os, features, d->texrow);
>
> +   runparams.use_japanese = features.isRequired("japanese");
> +
> if (!output_body)
> return;
>
> @@ -2299,6 +2301,9 @@
> return "docbook";
> if (isLiterate())
> return "literate";
> +   // if( isPLATEX() )
> +   if ( params().encoding().package() == Encoding::japanese )
> +   return "jlatex";
> return "latex";
>  }

You could also use

OutputParams runparams(().encoding());
if (runparams.use_japanese)
return "jlatex";

Strikes me slightly better, but it's probably a matter of taste.

> Index: src/BufferParams.cpp
> ===
> --- src/BufferParams.cpp(revision 25709)
> +++ src/BufferParams.cpp(working copy)
> @@ -1055,6 +1055,8 @@
> os << "\\usepackage[" << from_ascii(lyxrc.fontenc)
><< ",LFE,LAE]{fontenc}\n";
> texrow.newline();
> +   }else if (language->lang() == "japanese"){
> +   ; // do nothing.

rather use

if (lyxrc.fontenc != "default" && language->lang() != "japanese") {

> Index: lib/languages
> ===
> --- lib/languages   (revision 25709)
> +++ lib/languages   (working copy)
> @@ -52,7 +52,7 @@
>  interlingua   interlingua  "Interlingua"   false  iso8859-15 ia ""
>  irish   irish  "Irish" false  iso8859-15 ga_IE  ""
>  italian italian"Italian"   false  iso8859-15 it_IT  ""
> -japanesejapanese   "Japanese"  false  jis-plain ja_JP   ""
> +japanesejapanese   "Japanese"  false  jis-platex ja_JP  ""

There's no need to rename the encoding.

> """%%""document" Index: lib/encodings
> ===
> --- lib/encodings   (revision 25709)
> +++ lib/encodings   (working copy)
> @@ -173,11 +173,11 @@
>
>  # Traditional Japanese TeX programs require neither CJK nor inputenc
>  # package.
> -Encoding euc-jp-plain EUC-JP-pLaTeX \\\
>   "Japanese (non-CJK) (EUC-JP)" EUC-JP variable
> none +Encoding euc-jp-platex EUC-JP-pLaTeX \\\
> "Japanese (pLaTeX, EUC-JP)" EUC-JP variable
> japanese End
> -Encoding jis-plain JIS-pLaTeX \\\
>"Japanese (non-CJK) (JIS)" ISO-2022-JP variable none
> +Encoding jis-platex JIS-pLaTeX \\\
>  "Japanese (pLaTeX, JIS)" ISO-2022-JP variable japanese
>  End
> -Encoding shift-jis-plain SJIS-pLaTeX \\\
>"Japanese (non-CJK) (SJIS)" CP932 variable none
> +Encoding shift-jis-platex SJIS-pLaTeX \\\
>  "Japanese (pLaTeX, SJIS)" CP932 variable japanese
>  End

dito.

>  # This one needs hardcoded support, since the inputenc package does not
> know
> ###

Thanks,
Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Hi again,

Tetsuya Makimura wrote:
 How about introducing --latex-command to these scripts, as you suggested
 for lyxpreview2bitmap.py ? The patches to realize this are attached
 below.

Yes, this seems to be the way to go, generally. However, I think some 
adjustments are necessary.

 We need to control the helper script from the LyX binary:
 You suggested that we should introduce an OutputParam::flavor PLATEX.  I
 I have tried to introduce the OutputParam::flavor PLATEX, but,
 unfortunately, I can not change the situation.  The flavor PLATEX can
 control the LyX binary program but can not control the helper scripts such
 as configure.py and lyxpreview2bitmap.py, which are out of the LyX binary.

Why? We just need to pass it to the helper scripts. See below

 

 I have implimented the patches from the following point of view.

 (1) Now I understand that we can not change the order of latex commands
 such as  latex, pplatex, platex, latex2e, in configure.py or
 lyxpreview2bitmat.py.

OK.

 (2) lyx::theConverters().latex_command_ is the most basic latex command in
 LyX. The latex_command_ variable is set by 'configure.py'. Users can
 change the latex_command_ in  Preferences - Converters - LaTeX
 (plain) - DVI. I have introduced '--latex-command' option, though which
 LyX binary can pass the latex command name that the users specified, upon
 reconfigure process.

So one still needs to change that manually? I don't think this is needed, and 
the flavor approach could help here (at least for preview).

 (3) As you suggested, I have introduced '--latex-command' option. The
 value can be supplied by configure.py as well as the converter
 'LyX Preview - PNG' and 'LyX Preview - PPM' in LyX binary by the users.

Good.

[...]
 In the present framework,

 (1) Installation

 a) The 'configure.py' script produces a system-wide 'lyxrc.defaults',
 in which \converter latex dvi is the first available command among
 'latex', 'platex', 'latex2e'. A installer or a user may specify the
 'latex' command, say --latex-command=platex during installation.

 b) The latex_commnad name is also distributed to the converters
 '\converter lyxpreview png' and '\converter lyxpreview ppm' through
 --latex-command options to the 'lyxpreview2bitmap.py' script.

 (2) Customization

 a) A user can change the 'LaTeX (plain) - DVI' converter in the Preference
 panel.

 b) The latex command which is used for preivew can also be specified
 in the Preference panel by the converter 'LyX Preview - PPM' like:
 python -tt $$s/scripts/lyxpreview2bitmap --latex-command=/usr/bin/platex

 These converters are stored in ~/.lyx/Preference for the future use.

My proposal: Add an output flavor PLATEX, add a new file format LaTeX 
(pLaTeX) and respective converters to PDF and DVI, and if japanese is 
required (we store that in LaTeXFeatures) use this flavor, which lets LyX 
automatically pass those converters to the scripts instead of latex and 
pdflatex.

This means that configure.py needed something like

\Format jlatex   texLaTeX (pLaTeX)%%document

and then separately check for converters

checkProg('pLaTeX, the Japanese LaTeX', ['platex $$i'],
rc_entry = [ r'\converter jlatex   dvi   %%   latex'])

(and converters for pdf output, if available and required)

Then, no explicit user configuration is required.

 (3) Customized Reconfiguration

 a) Once a user have chnaged the 'LaTeX (plain) - DVI' converter,
 the LFUN_RECONFIGURE function invoked from 'Tools-Reconfiguration using
 the converter (LaTeX plain - DVI)' with an argument '--latex-command'
 will pass the lyx::theConverters().latex_command() to the 'configure.py'
 script.
   This time, the Japanese platex-specific class files can be parsed
 normally because the 'configure.py' use 'platex' as LATEX command name.

For reconfiguring, I wonder if we could not automatically run platex, if a 
converter for the new file format LaTeX (pLaTeX) is found.

 b) By the customized reconfiguration,
 the converters '\converter lyxpreview png' and '\converter lyxpreview ppm'
 have the customized latex command as their options like:
 python -tt $$s/scripts/lyxpreview2bitmap.py
 --latex-command=/usr/bin/platex

Again, why hardcode this? I can imagine that there are users who like to use 
latex or platex, depending on their actual document. The flavor approach 
would allow for this.

 ---

 If there is no problem,
 I will write the GUI dialog related to recofigure something like:

 ++

 | RECONFIGURE                                            |

 ++

 | LaTeX commnand                                         |
 | ==                                         |
 | (X) default (pplatex)                                  |
 | ( ) using  LaTeX (plain) - DVI converter (platex)     |
 | ( ) without latex config                               

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller [EMAIL PROTECTED] writes:
 
 My proposal: Add an output flavor PLATEX, add a new file format LaTeX 
 (pLaTeX) and respective converters to PDF and DVI, and if japanese is 
 required (we store that in LaTeXFeatures) use this flavor, which lets LyX 
 automatically pass those converters to the scripts instead of latex and 
 pdflatex.

Hi, Jürgen. 
Thank you for your reply.

I still do not understand the flavor mechanism well.
Could you please tell me how LyX automatically detect if Japanese platex
is required ?

I can not find any automatic way to select flavor PLATEX between PLATEX and
LATEX.

It is impossible to select flavor by means of file extention; The file
extenstion of platex file (.tex) is the same as that of latex file.

It might be possible to determine flavor by a class file name that a user
specified. However, class files have not been activated in the
conventional LyX. This is the most crucial problem in the conventional LyX
for platex users.

Therefore, there should be a way for platex users to specify flavor
manually, say, in a GUI panel.

In the previous patch, I used the LaTeX - DVI converter to specify
'flavor'. Then, it is obvious that the user wants to use platex.
Even though you introduce PLATEX flaver, only defference between
PLATEX and LATEX is lyx::theConverter::latex_converter_ . Reconfigure
panel will be another chance to specify the flavor.

Thank you.
Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 Hi, Jürgen.
 Thank you for your reply.

 I still do not understand the flavor mechanism well.
 Could you please tell me how LyX automatically detect if Japanese platex
 is required ?

First, we need to use our LaTeXFeatures mechanism to tell LyX that we use the 
japanese package. I've done that in the following patch, which is not applied 
yet (since it still needs testing):
http://bugzilla.lyx.org/attachment.cgi?id=2678action=view

Using this, you could then specify e.g. in Buffer::doExport and probably other 
places, where this is needed:

} else {
backend_format = format;
// FIXME: Don't hardcode format names here, but use a flag
if (backend_format == pdflatex)
runparams.flavor = OutputParams::PDFLATEX;
+   else if (runparams.use_japanese)
+   runparams.flavor = OutputParams::PLATEX;
}


I guess you will need to go further through the code. Flavor is spreaded all 
over the place, but I'm sure it can be implemented this way.

 Therefore, there should be a way for platex users to specify flavor
 manually, say, in a GUI panel.

I think we can do better.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Hi again,

Tetsuya Makimura wrote:
> How about introducing --latex-command to these scripts, as you suggested
> for lyxpreview2bitmap.py ? The patches to realize this are attached
> below.

Yes, this seems to be the way to go, generally. However, I think some 
adjustments are necessary.

> We need to control the helper script from the LyX binary:
> You suggested that we should introduce an OutputParam::flavor PLATEX.  I
> I have tried to introduce the OutputParam::flavor PLATEX, but,
> unfortunately, I can not change the situation.  The flavor PLATEX can
> control the LyX binary program but can not control the helper scripts such
> as configure.py and lyxpreview2bitmap.py, which are out of the LyX binary.

Why? We just need to pass it to the helper scripts. See below

> 
>
> I have implimented the patches from the following point of view.
>
> (1) Now I understand that we can not change the order of latex commands
> such as  "latex", "pplatex", "platex", "latex2e", in configure.py or
> lyxpreview2bitmat.py.

OK.

> (2) lyx::theConverters().latex_command_ is the most basic latex command in
> LyX. The latex_command_ variable is set by 'configure.py'. Users can
> change the latex_command_ in  "Preferences" -> "Converters" -> "LaTeX
> (plain) -> DVI". I have introduced '--latex-command' option, though which
> LyX binary can pass the latex command name that the users specified, upon
> reconfigure process.

So one still needs to change that manually? I don't think this is needed, and 
the flavor approach could help here (at least for preview).

> (3) As you suggested, I have introduced '--latex-command' option. The
> value can be supplied by configure.py as well as the converter
> 'LyX Preview -> PNG' and 'LyX Preview -> PPM' in LyX binary by the users.

Good.

[...]
> In the present framework,
>
> (1) Installation
>
> a) The 'configure.py' script produces a system-wide 'lyxrc.defaults',
> in which \converter latex dvi is the first available command among
> 'latex', 'platex', 'latex2e'. A installer or a user may specify the
> 'latex' command, say "--latex-command=platex" during installation.
>
> b) The latex_commnad name is also distributed to the converters
> '\converter lyxpreview png' and '\converter lyxpreview ppm' through
> --latex-command options to the 'lyxpreview2bitmap.py' script.
>
> (2) Customization
>
> a) A user can change the 'LaTeX (plain) -> DVI' converter in the Preference
> panel.
>
> b) The latex command which is used for preivew can also be specified
> in the Preference panel by the converter 'LyX Preview -> PPM' like:
> python -tt $$s/scripts/lyxpreview2bitmap --latex-command=/usr/bin/platex
>
> These converters are stored in ~/.lyx/Preference for the future use.

My proposal: Add an output flavor PLATEX, add a new file format "LaTeX 
(pLaTeX)" and respective converters to PDF and DVI, and if japanese is 
required (we store that in LaTeXFeatures) use this flavor, which lets LyX 
automatically pass those converters to the scripts instead of latex and 
pdflatex.

This means that configure.py needed something like

\Format jlatex   tex"LaTeX (pLaTeX)"  "" "" "%%""document"

and then separately check for converters

checkProg('pLaTeX, the Japanese LaTeX', ['platex $$i'],
rc_entry = [ r'\converter jlatex   dvi   "%%"   "latex"'])

(and converters for pdf output, if available and required)

Then, no explicit user configuration is required.

> (3) Customized Reconfiguration
>
> a) Once a user have chnaged the 'LaTeX (plain) -> DVI' converter,
> the LFUN_RECONFIGURE function invoked from 'Tools->Reconfiguration using
> the converter (LaTeX plain -> DVI)' with an argument '--latex-command'
> will pass the lyx::theConverters().latex_command() to the 'configure.py'
> script.
>   This time, the Japanese platex-specific class files can be parsed
> normally because the 'configure.py' use 'platex' as LATEX command name.

For reconfiguring, I wonder if we could not automatically run platex, if a 
converter for the new file format "LaTeX (pLaTeX") is found.

> b) By the customized reconfiguration,
> the converters '\converter lyxpreview png' and '\converter lyxpreview ppm'
> have the customized latex command as their options like:
> "python -tt $$s/scripts/lyxpreview2bitmap.py
> --latex-command=/usr/bin/platex"

Again, why hardcode this? I can imagine that there are users who like to use 
latex or platex, depending on their actual document. The flavor approach 
would allow for this.

> ---
>
> If there is no problem,
> I will write the GUI dialog related to recofigure something like:
>
> ++
>
> | RECONFIGURE                                            |
>
> ++
>
> | LaTeX commnand                                         |
> | ==                                         |
> | (X) default (pplatex)                               

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
 
> My proposal: Add an output flavor PLATEX, add a new file format "LaTeX 
> (pLaTeX)" and respective converters to PDF and DVI, and if japanese is 
> required (we store that in LaTeXFeatures) use this flavor, which lets LyX 
> automatically pass those converters to the scripts instead of latex and 
> pdflatex.

Hi, Jürgen. 
Thank you for your reply.

I still do not understand the flavor mechanism well.
Could you please tell me how LyX automatically detect if Japanese platex
is required ?

I can not find any automatic way to select flavor PLATEX between PLATEX and
LATEX.

It is impossible to select flavor by means of file extention; The file
extenstion of platex file (.tex) is the same as that of latex file.

It might be possible to determine flavor by a class file name that a user
specified. However, class files have not been activated in the
conventional LyX. This is the most crucial problem in the conventional LyX
for platex users.

Therefore, there should be a way for platex users to specify flavor
manually, say, in a GUI panel.

In the previous patch, I used the LaTeX -> DVI converter to specify
'flavor'. Then, it is obvious that the user wants to use platex.
Even though you introduce PLATEX flaver, only defference between
PLATEX and LATEX is lyx::theConverter::latex_converter_ . Reconfigure
panel will be another chance to specify the flavor.

Thank you.
Tetsuya Makimura

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> Hi, Jürgen.
> Thank you for your reply.
>
> I still do not understand the flavor mechanism well.
> Could you please tell me how LyX automatically detect if Japanese platex
> is required ?

First, we need to use our LaTeXFeatures mechanism to tell LyX that we use the 
japanese package. I've done that in the following patch, which is not applied 
yet (since it still needs testing):
http://bugzilla.lyx.org/attachment.cgi?id=2678=view

Using this, you could then specify e.g. in Buffer::doExport and probably other 
places, where this is needed:

} else {
backend_format = format;
// FIXME: Don't hardcode format names here, but use a flag
if (backend_format == "pdflatex")
runparams.flavor = OutputParams::PDFLATEX;
+   else if (runparams.use_japanese)
+   runparams.flavor = OutputParams::PLATEX;
}


I guess you will need to go further through the code. Flavor is spreaded all 
over the place, but I'm sure it can be implemented this way.

> Therefore, there should be a way for platex users to specify flavor
> manually, say, in a GUI panel.

I think we can do better.

Jürgen

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller [EMAIL PROTECTED] writes:

 Rather than that, we should introduce an OutputParam::flavor PLATEX and use 
 that as soon as japanese is required. As for the preview scipts, we could 
 pass the binary name via a new command line option.

This will have the big advantage that platex is only (and always) used if 
 required. With your proposal, platex is always used if installed. I don't 
 think this is desirable.

Hi, Jürgen.
Thank you for you comments.

The problems in using Japanese 'platex' are:
  (a) The platex-specific class files can not be activated.
  (b) Instant preview fails.
These occur because lib/configure.py and lib/scripts/lyxpreview2bitmap.py
are imcompatible with the Japanese 'platex'.

How about introducing --latex-command to these scripts, as you suggested
for lyxpreview2bitmap.py ? The patches to realize this are attached
below.

We need to control the helper script from the LyX binary:
You suggested that we should introduce an OutputParam::flavor PLATEX.  I
I have tried to introduce the OutputParam::flavor PLATEX, but,
unfortunately, I can not change the situation.  The flavor PLATEX can
control the LyX binary program but can not control the helper scripts such
as configure.py and lyxpreview2bitmap.py, which are out of the LyX binary.



I have implimented the patches from the following point of view.

(1) Now I understand that we can not change the order of latex commands
such as  latex, pplatex, platex, latex2e, in configure.py or
lyxpreview2bitmat.py.

(2) lyx::theConverters().latex_command_ is the most basic latex command in
LyX. The latex_command_ variable is set by 'configure.py'. Users can
change the latex_command_ in  Preferences - Converters - LaTeX
(plain) - DVI. I have introduced '--latex-command' option, though which
LyX binary can pass the latex command name that the users specified, upon
reconfigure process.

(3) As you suggested, I have introduced '--latex-command' option. The
value can be supplied by configure.py as well as the converter 
'LyX Preview - PNG' and 'LyX Preview - PPM' in LyX binary by the users.

Thus, latex_command is consistent in LyX binary and helper scripts.
In the conventional LyX, configuration information such as latex name is
one-directional and user can not change latex command in helper scripts
even though the users changes the LaTeX (plain) - DVI converter.

-

 I propose that chkconfig.ltx should check pfmtname as shown above[1].
 The \pfmtname is defined in plcore.ltx, which is inclued in platex.ltx

 Yes, this change looks sensible. However, we have to find a method where we 
 can parse the jlatex classes without changing the order.

In the present framework,

(1) Installation

a) The 'configure.py' script produces a system-wide 'lyxrc.defaults',
in which \converter latex dvi is the first available command among
'latex', 'platex', 'latex2e'. A installer or a user may specify the
'latex' command, say --latex-command=platex during installation.

b) The latex_commnad name is also distributed to the converters
'\converter lyxpreview png' and '\converter lyxpreview ppm' through
--latex-command options to the 'lyxpreview2bitmap.py' script.

(2) Customization

a) A user can change the 'LaTeX (plain) - DVI' converter in the Preference
panel.

b) The latex command which is used for preivew can also be specified
in the Preference panel by the converter 'LyX Preview - PPM' like:
python -tt $$s/scripts/lyxpreview2bitmap --latex-command=/usr/bin/platex

These converters are stored in ~/.lyx/Preference for the future use.

(3) Customized Reconfiguration

a) Once a user have chnaged the 'LaTeX (plain) - DVI' converter,
the LFUN_RECONFIGURE function invoked from 'Tools-Reconfiguration using
the converter (LaTeX plain - DVI)' with an argument '--latex-command'
will pass the lyx::theConverters().latex_command() to the 'configure.py'
script.
  This time, the Japanese platex-specific class files can be parsed normally
because the 'configure.py' use 'platex' as LATEX command name.

b) By the customized reconfiguration,
the converters '\converter lyxpreview png' and '\converter lyxpreview ppm'
have the customized latex command as their options like:
python -tt $$s/scripts/lyxpreview2bitmap.py --latex-command=/usr/bin/platex

---

If there is no problem,
I will write the GUI dialog related to recofigure something like:

++
| RECONFIGURE|
++
| LaTeX commnand |
| == |
| (X) default (pplatex)  |
| ( ) using  LaTeX (plain) - DVI converter (platex) |
| ( ) without latex config   |
| ++ |
| ( ) using latex commnad +| |
|

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Tetsuya Makimura]

Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:

> Rather than that, we should introduce an OutputParam::flavor PLATEX and use 
> that as soon as japanese is required. As for the preview scipts, we could 
> pass the binary name via a new command line option.
>
>This will have the big advantage that platex is only (and always) used if 
> required. With your proposal, platex is always used if installed. I don't 
> think this is desirable.

Hi, Jürgen.
Thank you for you comments.

The problems in using Japanese 'platex' are:
  (a) The platex-specific class files can not be activated.
  (b) Instant preview fails.
These occur because lib/configure.py and lib/scripts/lyxpreview2bitmap.py
are imcompatible with the Japanese 'platex'.

How about introducing --latex-command to these scripts, as you suggested
for lyxpreview2bitmap.py ? The patches to realize this are attached
below.

We need to control the helper script from the LyX binary:
You suggested that we should introduce an OutputParam::flavor PLATEX.  I
I have tried to introduce the OutputParam::flavor PLATEX, but,
unfortunately, I can not change the situation.  The flavor PLATEX can
control the LyX binary program but can not control the helper scripts such
as configure.py and lyxpreview2bitmap.py, which are out of the LyX binary.



I have implimented the patches from the following point of view.

(1) Now I understand that we can not change the order of latex commands
such as  "latex", "pplatex", "platex", "latex2e", in configure.py or
lyxpreview2bitmat.py.

(2) lyx::theConverters().latex_command_ is the most basic latex command in
LyX. The latex_command_ variable is set by 'configure.py'. Users can
change the latex_command_ in  "Preferences" -> "Converters" -> "LaTeX
(plain) -> DVI". I have introduced '--latex-command' option, though which
LyX binary can pass the latex command name that the users specified, upon
reconfigure process.

(3) As you suggested, I have introduced '--latex-command' option. The
value can be supplied by configure.py as well as the converter 
'LyX Preview -> PNG' and 'LyX Preview -> PPM' in LyX binary by the users.

Thus, latex_command is consistent in LyX binary and helper scripts.
In the conventional LyX, configuration information such as latex name is
one-directional and user can not change latex command in helper scripts
even though the users changes the LaTeX (plain) -> DVI converter.

-

>> I propose that chkconfig.ltx should check pfmtname as shown above[1].
>> The \pfmtname is defined in plcore.ltx, which is inclued in platex.ltx
>
> Yes, this change looks sensible. However, we have to find a method where we 
> can parse the jlatex classes without changing the order.

In the present framework,

(1) Installation

a) The 'configure.py' script produces a system-wide 'lyxrc.defaults',
in which \converter latex dvi is the first available command among
'latex', 'platex', 'latex2e'. A installer or a user may specify the
'latex' command, say "--latex-command=platex" during installation.

b) The latex_commnad name is also distributed to the converters
'\converter lyxpreview png' and '\converter lyxpreview ppm' through
--latex-command options to the 'lyxpreview2bitmap.py' script.

(2) Customization

a) A user can change the 'LaTeX (plain) -> DVI' converter in the Preference
panel.

b) The latex command which is used for preivew can also be specified
in the Preference panel by the converter 'LyX Preview -> PPM' like:
python -tt $$s/scripts/lyxpreview2bitmap --latex-command=/usr/bin/platex

These converters are stored in ~/.lyx/Preference for the future use.

(3) Customized Reconfiguration

a) Once a user have chnaged the 'LaTeX (plain) -> DVI' converter,
the LFUN_RECONFIGURE function invoked from 'Tools->Reconfiguration using
the converter (LaTeX plain -> DVI)' with an argument '--latex-command'
will pass the lyx::theConverters().latex_command() to the 'configure.py'
script.
  This time, the Japanese platex-specific class files can be parsed normally
because the 'configure.py' use 'platex' as LATEX command name.

b) By the customized reconfiguration,
the converters '\converter lyxpreview png' and '\converter lyxpreview ppm'
have the customized latex command as their options like:
"python -tt $$s/scripts/lyxpreview2bitmap.py --latex-command=/usr/bin/platex"

---

If there is no problem,
I will write the GUI dialog related to recofigure something like:

++
| RECONFIGURE|
++
| LaTeX commnand |
| == |
| (X) default (pplatex)  |
| ( ) using  LaTeX (plain) -> DVI converter (platex) |
| ( ) without latex config   |
| ++ |
| ( ) using latex 

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
 [A] I propose that the configure.py and lib/scripts/lyxpreview2bitmat.py
 scripts read the .lyx/preference and use the the field of '\converter' as
 laatex command name. Then 'reconfigure' invoked in LyX can configure LyX
 most suitably to the users who needs to change the latex command.

 [B] I propose that chkconfig.ltx should check \pfmtname as shown above[1].
 The \pfmtname is defined in plcore.ltx, which is inclued in platex.ltx.

Rather than that, we should introduce an OutputParam::flavor PLATEX and use 
that as soon as japanese is required. As for the preview scipts, we could 
pass the binary name via a new command line option.

This will have the big advantage that platex is only (and always) used if 
required. With your proposal, platex is always used if installed. I don't 
think this is desirable.

Also your proposal probably entails some problems (see below).

 I can manage these with the patches below.

 [1]
 Note that '\' indicates continued lines.
 Line length is restricted to be less than 80 characters in GMANE.
 #
 lyx-devel$ svn diff
 #
 Index: lib/scripts/lyxpreview2bitmap.py
 ===
 --- lib/scripts/lyxpreview2bitmap.py(revision 25455)
 +++ lib/scripts/lyxpreview2bitmap.py(working copy)
 @@ -171,7 +171,7 @@

  # External programs used by the script.
  path = string.split(os.environ[PATH], os.pathsep)
 -latex = find_exe_or_terminate(\
   [latex, pplatex, platex, latex2e], path)
 +latex = find_exe_or_terminate(\
   [platex, latex, pplatex, latex2e], path)

The problem is that MikTeX apparently has a binary platex that is actually 
pdflatex. So just searching for platex will break some setups.

Also, this will most probably again trigger bug 2165: 
http://bugzilla.lyx.org/show_bug.cgi?id=2165

  # This can go once dvipng becomes widespread.
  dvipng = find_exe([dvipng], path)
 Index: lib/chkconfig.ltx
 ===
 --- lib/chkconfig.ltx   (revision 25455)
 +++ lib/chkconfig.ltx   (working copy)
 @@ -166,8 +166,13 @@

  % (2) strip the useless parts from \mesg. This uses the fact that TeX
  % allows to define macros with parameters delimited by arbitrary text.
 -\def\strip#1patterns for #2, loaded.#3\endmark{\def\langs{#2}}
 -\expandafter\strip\mesg\endmark
 +\def\platexname{pLaTeX2e}
 +\ifx\pfmtname\platexname
 +  \def\langs{japanese}
 +\else
 +  \def\strip#1patterns for #2, loaded.#3\endmark{\def\langs{#2}}
 +  \expandafter\strip\mesg\endmark
 +\fi

  % (3) handle the result
  \message{^^J\prefix checking for available hyphenation patterns... \langs}
 Index: lib/configure.py
 ===
 --- lib/configure.py(revision 25455)
 +++ lib/configure.py(working copy)
 @@ -198,7 +198,7 @@

  def checkLatex(dtl_tools):
  ''' Check latex, return lyx_check_config '''
 -path, LATEX = checkProg('a Latex2e program',\
   ['latex $$i', 'platex $$i', 'latex2e $$i'])
 +path, LATEX = checkProg('a Latex2e program',\
   ['platex $$i', 'latex $$i', 'latex2e $$i'])

See above.

  path, PPLATEX = checkProg('a DVI postprocessing program', ['pplatex
 $$i']) # use LATEX to convert from latex to dvi if PPLATEX is not available
 if PPLATEX == '':
 ###
###

 

 The latex command/program name in configure.py and lyxpreview2bitmap.py
 should be 'platex'. Because I have also latex and pplatex in the command
 search paths, one of these are selected as the latex command instead of
 platex. Because 'latex' or 'pplatex' fail to parse Japanse-specific class
 files, the class files inactive after the configuration.

 (A-a)
 If the order of the candidates is changed so that 'platex' has higher
 priority than 'latex' and 'pplatex', 'platex' is selected as the latex
 command, as shown in the patch above.

 (A-b)
 For users who wants to use 'latex' and have installed 'platex', the
 solution (A-a) may cause a trouble because 'platex' is not upper
 compatible with the latest 'latex'.

 The users specify the command in the Preference Panel and LyX stores the
 command name in the 'CONVERTERS SECTION' as
\converter latex dvi platex latex
 I propose that the configure.py script read the .lyx/preference and use
 the the field of '\converter' as latex command name. Then 'reconfigure'
 invoked in LyX can configure LyX most suitably to the users who needs to
 change the latex command.

All this can be solved more elegantly with the flavor approach.

 

Re: Support request for Japanese without CJK, again (Re: [Fwd: About Japanese edition ...)

[Jürgen Spitzmüller]

Tetsuya Makimura wrote:
> [A] I propose that the configure.py and lib/scripts/lyxpreview2bitmat.py
> scripts read the .lyx/preference and use the the field of '\converter' as
> laatex command name. Then 'reconfigure' invoked in LyX can configure LyX
> most suitably to the users who needs to change the latex command.
>
> [B] I propose that chkconfig.ltx should check \pfmtname as shown above[1].
> The \pfmtname is defined in plcore.ltx, which is inclued in platex.ltx.

Rather than that, we should introduce an OutputParam::flavor PLATEX and use 
that as soon as japanese is required. As for the preview scipts, we could 
pass the binary name via a new command line option.

This will have the big advantage that platex is only (and always) used if 
required. With your proposal, platex is always used if installed. I don't 
think this is desirable.

Also your proposal probably entails some problems (see below).

> I can manage these with the patches below.
>
> [1]
> Note that '\' indicates continued lines.
> Line length is restricted to be less than 80 characters in GMANE.
> #
> lyx-devel$ svn diff
> #
> Index: lib/scripts/lyxpreview2bitmap.py
> ===
> --- lib/scripts/lyxpreview2bitmap.py(revision 25455)
> +++ lib/scripts/lyxpreview2bitmap.py(working copy)
> @@ -171,7 +171,7 @@
>
>  # External programs used by the script.
>  path = string.split(os.environ["PATH"], os.pathsep)
> -latex = find_exe_or_terminate(\
>   ["latex", "pplatex", "platex", "latex2e"], path)
> +latex = find_exe_or_terminate(\
>   ["platex", "latex", "pplatex", "latex2e"], path)

The problem is that MikTeX apparently has a binary "platex" that is actually 
pdflatex. So just searching for "platex" will break some setups.

Also, this will most probably again trigger bug 2165: 
http://bugzilla.lyx.org/show_bug.cgi?id=2165

>  # This can go once dvipng becomes widespread.
>  dvipng = find_exe(["dvipng"], path)
> Index: lib/chkconfig.ltx
> ===
> --- lib/chkconfig.ltx   (revision 25455)
> +++ lib/chkconfig.ltx   (working copy)
> @@ -166,8 +166,13 @@
>
>  % (2) strip the useless parts from \mesg. This uses the fact that TeX
>  % allows to define macros with parameters delimited by arbitrary text.
> -\def\strip#1patterns for #2, loaded.#3\endmark{\def\langs{#2}}
> -\expandafter\strip\mesg\endmark
> +\def\platexname{pLaTeX2e}
> +\ifx\pfmtname\platexname
> +  \def\langs{japanese}
> +\else
> +  \def\strip#1patterns for #2, loaded.#3\endmark{\def\langs{#2}}
> +  \expandafter\strip\mesg\endmark
> +\fi
>
>  % (3) handle the result
>  \message{^^J\prefix checking for available hyphenation patterns... \langs}
> Index: lib/configure.py
> ===
> --- lib/configure.py(revision 25455)
> +++ lib/configure.py(working copy)
> @@ -198,7 +198,7 @@
>
>  def checkLatex(dtl_tools):
>  ''' Check latex, return lyx_check_config '''
> -path, LATEX = checkProg('a Latex2e program',\
>   ['latex $$i', 'platex $$i', 'latex2e $$i'])
> +path, LATEX = checkProg('a Latex2e program',\
>   ['platex $$i', 'latex $$i', 'latex2e $$i'])

See above.

>  path, PPLATEX = checkProg('a DVI postprocessing program', ['pplatex
> $$i']) # use LATEX to convert from latex to dvi if PPLATEX is not available
> if PPLATEX == '':
> ###
>###
>
> 
>
> The latex command/program name in configure.py and lyxpreview2bitmap.py
> should be 'platex'. Because I have also latex and pplatex in the command
> search paths, one of these are selected as the latex command instead of
> platex. Because 'latex' or 'pplatex' fail to parse Japanse-specific class
> files, the class files inactive after the configuration.
>
> (A-a)
> If the order of the candidates is changed so that 'platex' has higher
> priority than 'latex' and 'pplatex', 'platex' is selected as the latex
> command, as shown in the patch above.
>
> (A-b)
> For users who wants to use 'latex' and have installed 'platex', the
> solution (A-a) may cause a trouble because 'platex' is not upper
> compatible with the latest 'latex'.
>
> The users specify the command in the Preference Panel and LyX stores the
> command name in the 'CONVERTERS SECTION' as
>\converter "latex" "dvi" "platex" "latex"
> I propose that the configure.py script read the .lyx/preference and use
> the the field of '\converter' as latex command name. Then 'reconfigure'
> invoked in LyX can configure LyX most suitably to the users who needs to
> change the latex 

Re: Support request for Japanese without CJK

[Jean-Marc Lasgouttes]

Koji Yokota [EMAIL PROTECTED] writes:

 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.

Everything is OK then. Thanks for checking.
JMarc

Re: Support request for Japanese without CJK

[Jean-Marc Lasgouttes]

Koji Yokota <[EMAIL PROTECTED]> writes:

>> 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.

Everything is OK then. Thanks for checking.
JMarc

Re: Support request for Japanese without CJK

[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

[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

[Jean-Marc Lasgouttes]

Koji Yokota [EMAIL PROTECTED] writes:

 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?

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

JMarc

Re: Support request for Japanese without CJK

[Jean-Marc Lasgouttes]

Koji Yokota <[EMAIL PROTECTED]> writes:

> 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?

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

JMarc

Re: Support request for Japanese without CJK

[Uwe Stöhr]

Koji Yokota schrieb:

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


This file was broken. It seems you have copied the text manually with and editor into the section 
about kluwer.


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?

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

regards Uwe

Re: Support request for Japanese without CJK

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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


This file was broken. It seems you have copied the text manually with and editor into the section 
about kluwer.


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?

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

regards Uwe

Re: Support request for Japanese without CJK

[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

[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

[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

[Jean-Marc Lasgouttes]

Uwe Stöhr [EMAIL PROTECTED] writes:

 Koji Yokota schrieb:

 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)?

 I applied your patches.

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

JMarc

Re: Support request for Japanese without CJK

[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

[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

[Jean-Marc Lasgouttes]

Uwe Stöhr <[EMAIL PROTECTED]> writes:

> Koji Yokota schrieb:
>
>> 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)?
>
> I applied your patches.

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

JMarc

Re: Support request for Japanese without CJK

[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

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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)?


I applied your patches.

Besides the problem that the platex encoding must be checked by configure.py, 
we are now ready, right?

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

thanks and regards
Uwe

Re: Support request for Japanese without CJK

[Uwe Stöhr]

Koji Yokota schrieb:


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.


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.


thanks in advance and regards
Uwe

Re: Support request for Japanese without CJK

[Uwe Stöhr]

Koji Yokota schrieb:

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)?


I applied your patches.

Besides the problem that the platex encoding must be checked by configure.py, 
we are now ready, right?

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

thanks and regards
Uwe

Re: Support request for Japanese without CJK

[Uwe Stöhr]

Koji Yokota schrieb:


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.


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.


thanks in advance and regards
Uwe

Re: Support request for Japanese without CJK

[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

[Jean-Marc Lasgouttes]

Koji Yokota [EMAIL PROTECTED] writes:

 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)?

What is the difference between platex and latex?

JMarc

Re: Support request for Japanese without CJK

[Alfredo Braunstein]

Jean-Marc Lasgouttes wrote:

 Koji Yokota [EMAIL PROTECTED]
 writes:
 
 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)?
 
 What is the difference between platex and latex?

p


*ducks*

Re: Support request for Japanese without CJK

[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

[Jean-Marc Lasgouttes]

Koji Yokota [EMAIL PROTECTED] writes:

 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:

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?

JMarc

Re: Support request for Japanese without CJK

[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

[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

[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

[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

[Jean-Marc Lasgouttes]

Koji Yokota <[EMAIL PROTECTED]> writes:

> 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)?

What is the difference between platex and latex?

JMarc

Re: Support request for Japanese without CJK

[Alfredo Braunstein]

Jean-Marc Lasgouttes wrote:

> Koji Yokota <[EMAIL PROTECTED]>
> writes:
> 
>> 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)?
> 
> What is the difference between platex and latex?

p


*ducks*

Re: Support request for Japanese without CJK

[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

[Jean-Marc Lasgouttes]

Koji Yokota <[EMAIL PROTECTED]> writes:

> 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:

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?

JMarc

Re: Support request for Japanese without CJK

[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

[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

[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

[Jean-Marc Lasgouttes]

Uwe Stöhr [EMAIL PROTECTED] writes:

 Koji Yokota schrieb:

 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?

 I did this now.

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

JMarc

Re: Support request for Japanese without CJK

[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

[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

[Jean-Marc Lasgouttes]

Uwe Stöhr <[EMAIL PROTECTED]> writes:

> Koji Yokota schrieb:
>
>>> 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?
>
> I did this now.

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

JMarc

Re: Support request for Japanese without CJK

[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

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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?


I did this now.

regards Uwe

Re: Support request for Japanese without CJK

[Uwe Stöhr]

Koji Yokota schrieb:

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?


I did this now.

regards Uwe

Re: Support request for Japanese without CJK

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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


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

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.


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

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

thanks and regards Uwe

Re: Support request for Japanese without CJK

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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.


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.


regards Uwe

Re: Support request for Japanese without CJK

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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


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

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.


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

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

thanks and regards Uwe

Re: Support request for Japanese without CJK

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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.


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.


regards Uwe

Re: Support request for Japanese without CJK

[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

[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

[Uwe Stöhr]

Koji Yokota schrieb:

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).


I've seen this too - my pTeX uses JIS as default encoding.

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 is indeed a must fix. Could you please report it at bugzilla.lyx.org?

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?


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?

regards Uwe

Re: Support request for Japanese without CJK

[Uwe Stöhr]

Koji Yokota schrieb:

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?


In principle yes, but this won't be easy. Could you also add this issue to the 
bugzilla database please?

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.


I don't understand, should I comment out this entry in the encodings file too?:

# For japanese
Encoding shift-jis-plain SJIS-plain SJIS variable none
End

regards Uwe