Koji Yokota schrieb:
Japanese package is now on CTAN
(http://www.ctan.org/tex-archive/language/japanese/japanese/) and a
Japanese-aware latex, jtex is also available there
(http://www.ctan.org/tex-archive/language/japanese/jtex/).
Thanks that you contacted the authors of these packages to pu
Koji Yokota schrieb:
Is it possible to provide an option for Japanese language to use the
combination of jtex and japanese package in the next release? It means
that Japanese language should be available without CJK nor inputenc
package in Japanese encodings such as EUC-JP and JIS. It would be
Uwe Stöhr wrote:
Can you process LyX's current LaTeX code? For me it only works when I
omit the inputenc package.
Uwe,
No, you must omit the inputenc package, and the japanese package should
be loaded after babel declaration. To avoid inputenc, I had to tweak
current LyX to write Japanese wi
Koji Yokota schrieb:
No, you must omit the inputenc package, and the japanese package should
be loaded after babel declaration.
I built it in now:
http://www.lyx.org/trac/changeset/20861
LyX now produces this:
---
\documentclass[english]{article}
\usepackage[T1]{fontenc}
\usepackage{babel}
\
Uwe Stöhr wrote:
> But the word "Part" appears for me still in English and not in Japanese. But
> the japanese-package
> should have translated it. Does the translation work for you with your system
> and my example?
The file you attached worked fine except that I had to convert from the
DOS (C
Koji Yokota schrieb:
The file you attached worked fine except that I had to convert from the
DOS (CR/LF) format to UNIX (LF) format :P (BTW, isn't this problematic
to exchange documents between Windows and Unix? LyX on FreeBSD judges a
lyx document written on Windows as a wrong format, raises an
Hello Koji,
I just noticed that we currenly only have these encodings defined in LyX:
# For japanese
Encoding euc-jp EUC-JP EUC-JP variable CJK
End
and
# For japanese
Encoding jis JIS JIS variable CJK
End
What about adding this encoding?:
# For japanese
Encoding shift-jis SJIS SJIS variable
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> INFO: there are de-facto-standard Japanese-aware styles such as
>> jarticle, jreport, jbook, jsarticle and jsbook. As far as users use
>> these styles, the japanese package is not necessary. In other words,
>> when users use these styles, the call of japane
Hi, Mr. Yokota
About j(s)classes , they are to be desired that you go for advice
Mr. Okumura ?
cf. ptex http://oku.edu.mie-u.ac.jp/~okumura/texfaq/japanese/ptex.html
Now the License is the modified BSD license and any UTF-8 editions
exist. (They are based tetex3 , texlive and more. )
On Wed,
Jean-Marc Lasgouttes schrieb:
It can be handled by adding a line
Provides japanese
in the layout fiels and handling the "japanese" feature correctly in
LaTeXFeatures.cpp.
I don't know what you mean and how to implement this. Could you please build
this in?
regards Uwe
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> It can be handled by adding a line
>> Provides japanese
>> in the layout fiels and handling the "japanese" feature correctly in
>> LaTeXFeatures.cpp.
>
> I don't know what you mean and how to implement this. Could you
> please build this in?
It is almost
Jean-Marc Lasgouttes wrote:
if (!textclass.provides("japanese"))
os << "\\usepackage{japanese}\n";
Oh, great! That's the solution we need.
Koji
Keiichi Morisato wrote:
About j(s)classes , they are to be desired that you go for advice
Mr. Okumura ?
cf. ptex http://oku.edu.mie-u.ac.jp/~okumura/texfaq/japanese/ptex.html
Now the License is the modified BSD license and any UTF-8 editions
exist. (They are based tetex3 , texlive and more. )
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 vari
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
Japanes
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 -
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 w
Uwe Stöhr さんは書きました:
That means the LyX's configure.py should check what encoding is used
by the found LaTeX-system and then set the correct default encoding
for japanese-plain in LyX's encodings file?
I think we could try this, but how can we get the information what
encoding a LaTeX is built f
Uwe Stöhr wrote:
> 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*.
Exactly. This is also documented in the encodings file (it does not hurt to
look through the existing
Koji Yokota schrieb:
For pTeX, the output of 'ptex -version' (or 'platex -version') contains
a line:
> pTeX 3.141592-p3.1.9 (EUC) (Web2C 7.5.4)
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 forgo
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 p
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 f
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 jsarticl
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 o
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
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
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 wh
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
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 ca
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 b
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
>> m
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>> What is the difference between platex and latex?
>
> p
>
> *ducks*
Alfredo, always useful... So tell us more about this p :-p
JMarc
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
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 distri
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":
> $ pl
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
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 c
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 t
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
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)
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 Ja
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 t
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 desc
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
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
>
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
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
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
Uwe Stöhr wrote:
Thanks. Could you please post on the list when e.g. the Japanese
package is on CTAN?
I expect it would be too late to support this package before LyX 1.5.0
directly in LyX's menus, but I could then implement this for LyX 1.6.0.
thanks and regards
Uwe
Japanese package is now
Dear the developers of LyX,
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Juergen, Uwe,
...
> FYI, there are bugs related to CJK in bugzilla:
...
> Configuration and preview support by pLaTeX:
> http://bugzilla.lyx.org/show_bug.cgi?id=4290
...
> I've put Uwe and Koki Yokota who have done thing
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
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
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
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 thos
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
japan
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=2
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.
Te
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 rese
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 possibl
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 fo
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 noti
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.
> B
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 pLaTe
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 encod
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) docu
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
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 =
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 co
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
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 improvemen
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 op
71 matches
Mail list logo
