Re: Freeze for beta4

[Konrad Hofbauer]

Hi Bennett,

Bennett Helm wrote:

I'm getting a genuine problem on Mac when I try cross compiling for PPC. I'm
doing exactly what I did for 1.6 beta 3, but now I get this:

ranlib: archive member: .libs/liblyxsupport.a(LinkBack.o) cputype (7) does
not match previous archive members cputype (18) (all members must match)



Am I doing something wrong? (Note that I do make distclean before
configuring for cross compilation, so I'm not sure why I'm getting the
cputype does not match previous archive members cputype error ... whatever
that means.)


This error means that the (mac-specific) LinkBack stuff does not get 
re-compiled for PPC. The linker only finds the Intel stuff (even though 
you are compiling for PPC) and complains.


Could it be that distclean misses to delete the LinkBack stuff?
You could try to re-start from a fresh tar-ball after compiling Intel 
(instead of a make distclean) to see if that is the problem.


Do you send me the build script you use right now?

Unfortunately I will not have time to look into it this weekend though.

/Konrad

Re: Freeze for beta4

[Konrad Hofbauer]

Hi Bennett,

Bennett Helm wrote:

I'm getting a genuine problem on Mac when I try cross compiling for PPC. I'm
doing exactly what I did for 1.6 beta 3, but now I get this:

ranlib: archive member: .libs/liblyxsupport.a(LinkBack.o) cputype (7) does
not match previous archive members cputype (18) (all members must match)



Am I doing something wrong? (Note that I do make distclean before
configuring for cross compilation, so I'm not sure why I'm getting the
cputype does not match previous archive members cputype error ... whatever
that means.)


This error means that the (mac-specific) LinkBack stuff does not get 
re-compiled for PPC. The linker only finds the Intel stuff (even though 
you are compiling for PPC) and complains.


Could it be that distclean misses to delete the LinkBack stuff?
You could try to re-start from a fresh tar-ball after compiling Intel 
(instead of a make distclean) to see if that is the problem.


Do you send me the build script you use right now?

Unfortunately I will not have time to look into it this weekend though.

/Konrad

Re: Crash on quit

[Uwe Stöhr]

 Recently I've been getting occasional crashes on quit.

I see this here too on Windows. Could you please report this at bugzilla so that this won't be 
forgotten?


regards Uwe

Re: Crash on quit

[Pavel Sanda]

Bennett Helm wrote:
 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x6163697c
 std::_Rb_treestd::string, std::pairstd::string const, lyx::Messages,

iirc redblack trees were used in completion stuff, so maybe Stefan would
have some idea.

pavel

 std::lessstd::string, std::allocatorstd::pairstd::string const,
 lyx::Messages  ::lower_bound (this=0xb464, [EMAIL PROTECTED]) at
 LyX.cpp:2190
 2190{ return __lhs.compare(__rhs)  0; }
 
 
 (Note that I'm not sure if this output appears before or after I attempt to
 quit.)
 
 Here's the backtrace for the crash:
 
 
 #0  std::_Rb_treestd::string, std::pairstd::string const, lyx::Messages,
 std::_Select1ststd::pairstd::string const, lyx::Messages ,
 std::lessstd::string, std::allocatorstd::pairstd::string const,
 lyx::Messages  ::lower_bound (this=0xb464, [EMAIL PROTECTED]) at
 LyX.cpp:2190
 #1  0x00120d74 in std::mapstd::string, lyx::Messages,
 std::lessstd::string, std::allocatorstd::pairstd::string const,
 lyx::Messages  ::operator[] (this=0xb460, [EMAIL PROTECTED]) at
 LyX.cpp:2190
 #2  0x0010f1b4 in lyx::getGuiMessages () at LyX.cpp:2190
 warning: .o file
 /Users/bennett/lyx/lyx-devel/src/support/.libs/liblyxsupport.a(gettext.o)
 more recent than executable timestamp
 #3  0x00566cef in lyx::_ ([EMAIL PROTECTED]) at LyX.cpp:2190
 #4  0x0001592f in lyx::Buffer::~Buffer (this=0xefd148) at LyX.cpp:2190
 #5  0x916dffdc in __cxa_finalize ()
 #6  0x916dfed0 in exit ()
 #7  0x209f in start ()
 
 
 Bennett

Re: Crash on quit

[Pavel Sanda]

Pavel Sanda wrote:
 Bennett Helm wrote:
  Program received signal EXC_BAD_ACCESS, Could not access memory.
  Reason: KERN_INVALID_ADDRESS at address: 0x6163697c
  std::_Rb_treestd::string, std::pairstd::string const, lyx::Messages,
 
 iirc redblack trees were used in completion stuff, so maybe Stefan would
 have some idea.

no i was wrong, its part of lyx::getGuiMessages, nothing to do with
completion. Rb is just used for stl implementation, sorry for the noise.

 
 pavel
 

Re: Crash on quit

[Bennett Helm]

On Sat, Jul 12, 2008 at 6:33 AM, Uwe Stöhr [EMAIL PROTECTED] wrote:

  Recently I've been getting occasional crashes on quit.

 I see this here too on Windows. Could you please report this at bugzilla so
 that this won't be forgotten?

 regards Uwe


Done:

http://bugzilla.lyx.org/show_bug.cgi?id=5026

Bennett

Re: Freeze for beta4

[Pavel Sanda]

José Matos wrote:
 OK, I am now waiting for cygwin (or is it mingw? Enrico!) and windows, and 
 other linux distributions.
 
 If we have a nod from the first two I think that we can lift the freeze.

sorry i'm meddling here, but i found it quite unfortunate to hold
the freeze until all arch maintainers awaken from the winter sleep.

what about the solution taken in the antecedent releases with the addition,
that in case some brown paper bag issue happens you can always make branch
with on or two fixes commit, which will be later tagged and released?

(in my opinion, even the last dummy beta-1/2 are better, compared to the
situation all development stops wait until somebody goes to read dev-list one
day - we are clearly not organized enough to keep it this way.)

pavel

QClipboard::setData: Cannot set X11 selection owner for CLIPBOARD

[Jürgen Spitzmüller]

This is what I always get after closing LyX.

Jürgen

Re: Freeze for beta4

[Jean-Marc Lasgouttes]

Le 12 juil. 08 à 15:36, Pavel Sanda a écrit :
(in my opinion, even the last dummy beta-1/2 are better, compared  
to the
situation all development stops wait until somebody goes to read  
dev-list one

day - we are clearly not organized enough to keep it this way.)


Seriously, how much time has been lost like that? 1 dqy? 2? I do not  
think this is so critical...


JMarc

closing document in split view

[Abe Lau]

Hi,
I've observed that closing a document in a split view will close the same
document in all other split view.  Reported as bug #5020 (
http://bugzilla.lyx.org/show_bug.cgi?id=5020),

My feeling is that it would be more consistent if the open/close operation
only affect the current split view.  At present, opening a document opens it
in the current view, and closing a document close all of them in all split
view.  However, others have pointed out opening and closing is not symmetric
behavior.*  *I am curious to know what's other view towards this behavior.

Another thing is the Close tab group.  I found it quite confusing when
using it the first time because I was looking for something to close the new
split view (which consist of only one document, so no tab at all), so the
tab group didn't ring the bell for me at all.
Cheers.

Re: Acrobat Reader nonsense: bug, regression or feature?

[Enrico Forestieri]

On Fri, Jul 11, 2008 at 05:55:31PM -0400, Paul A. Rubin wrote:

 This came up on the user list.  I'm not sure if it needs to go into 
 bugzilla, so I'm looking for opinions.  (I didn't find this in either 
 bugzilla or the wiki.)
 
 On Windows, user specifies PDF (pdflatex) viewer as acrord32.exe.  View 
 - PDF (pdflatex) runs pdflatex, but no Acrobat Reader window opens. 
 Task Manager shows a copy of AR running (and eating a lot of CPU cycles) 
 but without a window.  You have to kill it.  Turns out the problem is 
 that LyX is passing the path to the file as C:/whatever, nicely 
 wrapped in quotes to preserve spaces but with Unix-style (maybe I should 
 say real-world style) path separators.  If you intercept the path and 
 reverse the separators, things work ok.
 
 The easiest workaround, assuming the user wants AR to be their PDF 
 viewer, is to put it on the system path and use 'auto' as the viewer. 
 Maybe the best solution is to put that on the wiki?  I'm a bit leery 
 about things that innocently can create windowless CPU-gulping children, 
 though.
 
 Thoughts?

This one seems to be another Windows idiosyncrasy. I had already
observed a strange behavior with permissions. For example, ttf
fonts are ignored if they don't have the executable bit set.

In this case, it seems there is some other strange problem with permissions,
rather than the use of '\' or '/' as path separator. I did the following
test. Started lyx and previewed a new file through View-PDF (pdflatex).
The file was shown in AcroRd32. Then, without quitting lyx, I tried to
view the very same file through the command

$ AcroRd32.exe C:/tmp/lyx_tmpdir848a00800/lyx_tmpbuf0/newfile1.pdf

AcroRd32 ran and was consuming cpu cycles, but nothing showed up. I killed it.
Now I did:

$ mv C:/tmp/lyx_tmpdir848a00800/lyx_tmpbuf0/newfile1.pdf 
C:/tmp/lyx_tmpdir848a00800/newfile1.pdf
$ AcroRd32.exe C:/tmp/lyx_tmpdir848a00800/newfile1.pdf

and AcroRd32 hung again. However, after

$ mv C:/tmp/lyx_tmpdir848a00800/newfile1.pdf C:/tmp/newfile1.pdf
$ AcroRd32.exe C:/tmp/newfile1.pdf

AcroRd32 came up showing the file.

So, there's something in the permissions of the lyx tempdir preventing
AcroRd32 from showing the file when using '/' as a separator.
Instead, why it indeed works when using '\' really escapes me.
I had already stopped trying to find rational explanations about Windows
behavior long ago.

-- 
Enrico

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: Freeze for beta4

[Konrad Hofbauer]

Hi Bennett,

Bennett Helm wrote:

I'm getting a genuine problem on Mac when I try cross compiling for PPC. I'm
doing exactly what I did for 1.6 beta 3, but now I get this:

ranlib: archive member: .libs/liblyxsupport.a(LinkBack.o) cputype (7) does
not match previous archive members cputype (18) (all members must match)

>

Am I doing something wrong? (Note that I do make distclean before
configuring for cross compilation, so I'm not sure why I'm getting the
"cputype does not match previous archive members cputype" error ... whatever
that means.)


This error means that the (mac-specific) LinkBack stuff does not get 
re-compiled for PPC. The linker only finds the Intel stuff (even though 
you are compiling for PPC) and complains.


Could it be that distclean misses to delete the LinkBack stuff?
You could try to re-start from a fresh tar-ball after compiling Intel 
(instead of a make distclean) to see if that is the problem.


Do you send me the build script you use right now?

Unfortunately I will not have time to look into it this weekend though.

/Konrad

Re: Freeze for beta4

[Konrad Hofbauer]

Hi Bennett,

Bennett Helm wrote:

I'm getting a genuine problem on Mac when I try cross compiling for PPC. I'm
doing exactly what I did for 1.6 beta 3, but now I get this:

ranlib: archive member: .libs/liblyxsupport.a(LinkBack.o) cputype (7) does
not match previous archive members cputype (18) (all members must match)

>

Am I doing something wrong? (Note that I do make distclean before
configuring for cross compilation, so I'm not sure why I'm getting the
"cputype does not match previous archive members cputype" error ... whatever
that means.)


This error means that the (mac-specific) LinkBack stuff does not get 
re-compiled for PPC. The linker only finds the Intel stuff (even though 
you are compiling for PPC) and complains.


Could it be that distclean misses to delete the LinkBack stuff?
You could try to re-start from a fresh tar-ball after compiling Intel 
(instead of a make distclean) to see if that is the problem.


Do you send me the build script you use right now?

Unfortunately I will not have time to look into it this weekend though.

/Konrad

Re: Crash on quit

[Uwe Stöhr]

> Recently I've been getting occasional crashes on quit.

I see this here too on Windows. Could you please report this at bugzilla so that this won't be 
forgotten?


regards Uwe

Re: Crash on quit

[Pavel Sanda]

Bennett Helm wrote:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x6163697c
> std::_Rb_tree std::less, std::allocator > >::lower_bound (this=0xb464, [EMAIL PROTECTED]) at
> LyX.cpp:2190
> 2190{ return __lhs.compare(__rhs) < 0; }
> 
> 
> (Note that I'm not sure if this output appears before or after I attempt to
> quit.)
> 
> Here's the backtrace for the crash:
> 
> 
> #0  std::_Rb_tree std::_Select1st,
> std::less, std::allocator > >::lower_bound (this=0xb464, [EMAIL PROTECTED]) at
> LyX.cpp:2190
> #1  0x00120d74 in std::map std::less, std::allocator > >::operator[] (this=0xb460, [EMAIL PROTECTED]) at
> LyX.cpp:2190
> #2  0x0010f1b4 in lyx::getGuiMessages () at LyX.cpp:2190
> warning: .o file
> "/Users/bennett/lyx/lyx-devel/src/support/.libs/liblyxsupport.a(gettext.o)"
> more recent than executable timestamp
> #3  0x00566cef in lyx::_ ([EMAIL PROTECTED]) at LyX.cpp:2190
> #4  0x0001592f in lyx::Buffer::~Buffer (this=0xefd148) at LyX.cpp:2190
> #5  0x916dffdc in __cxa_finalize ()
> #6  0x916dfed0 in exit ()
> #7  0x209f in start ()
> 
> 
> Bennett

Re: Crash on quit

[Pavel Sanda]

Pavel Sanda wrote:
> Bennett Helm wrote:
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > Reason: KERN_INVALID_ADDRESS at address: 0x6163697c
> > std::_Rb_tree 
> iirc redblack trees were used in completion stuff, so maybe Stefan would
> have some idea.

no i was wrong, its part of lyx::getGuiMessages, nothing to do with
completion. Rb is just used for stl implementation, sorry for the noise.

> 
> pavel
> 

Re: Crash on quit

[Bennett Helm]

On Sat, Jul 12, 2008 at 6:33 AM, Uwe Stöhr <[EMAIL PROTECTED]> wrote:

> > Recently I've been getting occasional crashes on quit.
>
> I see this here too on Windows. Could you please report this at bugzilla so
> that this won't be forgotten?
>
> regards Uwe
>

Done:

http://bugzilla.lyx.org/show_bug.cgi?id=5026

Bennett

Re: Freeze for beta4

[Pavel Sanda]

José Matos wrote:
> OK, I am now waiting for cygwin (or is it mingw? Enrico!) and windows, and 
> other linux distributions.
> 
> If we have a nod from the first two I think that we can lift the freeze.

sorry i'm meddling here, but i found it quite unfortunate to hold
the freeze until all arch maintainers awaken from the winter sleep.

what about the solution taken in the antecedent releases with the addition,
that in case some brown paper bag issue happens you can always make branch
with on or two fixes commit, which will be later tagged and released?

(in my opinion, even the last dummy beta-1/2 are better, compared to the
situation all development stops wait until somebody goes to read dev-list one
day - we are clearly not organized enough to keep it this way.)

pavel

QClipboard::setData: Cannot set X11 selection owner for CLIPBOARD

[Jürgen Spitzmüller]

This is what I always get after closing LyX.

Jürgen

Re: Freeze for beta4

[Jean-Marc Lasgouttes]

Le 12 juil. 08 à 15:36, Pavel Sanda a écrit :
(in my opinion, even the last dummy beta-1/2 are better, compared  
to the
situation all development stops wait until somebody goes to read  
dev-list one

day - we are clearly not organized enough to keep it this way.)


Seriously, how much time has been lost like that? 1 dqy? 2? I do not  
think this is so critical...


JMarc

closing document in split view

[Abe Lau]

Hi,
I've observed that closing a document in a split view will close the same
document in all other split view.  Reported as bug #5020 (
http://bugzilla.lyx.org/show_bug.cgi?id=5020),

My feeling is that it would be more consistent if the open/close operation
only affect the current split view.  At present, opening a document opens it
in the current view, and closing a document close all of them in all split
view.  However, others have pointed out opening and closing is not symmetric
behavior.*  *I am curious to know what's other view towards this behavior.

Another thing is the "Close tab group".  I found it quite confusing when
using it the first time because I was looking for something to close the new
split view (which consist of only one document, so no tab at all), so the
"tab group" didn't ring the bell for me at all.
Cheers.

Re: Acrobat Reader nonsense: bug, regression or feature?

[Enrico Forestieri]

On Fri, Jul 11, 2008 at 05:55:31PM -0400, Paul A. Rubin wrote:

> This came up on the user list.  I'm not sure if it needs to go into 
> bugzilla, so I'm looking for opinions.  (I didn't find this in either 
> bugzilla or the wiki.)
> 
> On Windows, user specifies PDF (pdflatex) viewer as acrord32.exe.  View 
> -> PDF (pdflatex) runs pdflatex, but no Acrobat Reader window opens. 
> Task Manager shows a copy of AR running (and eating a lot of CPU cycles) 
> but without a window.  You have to kill it.  Turns out the problem is 
> that LyX is passing the path to the file as "C:/whatever", nicely 
> wrapped in quotes to preserve spaces but with Unix-style (maybe I should 
> say real-world style) path separators.  If you intercept the path and 
> reverse the separators, things work ok.
> 
> The easiest workaround, assuming the user wants AR to be their PDF 
> viewer, is to put it on the system path and use 'auto' as the viewer. 
> Maybe the best solution is to put that on the wiki?  I'm a bit leery 
> about things that innocently can create windowless CPU-gulping children, 
> though.
> 
> Thoughts?

This one seems to be another Windows idiosyncrasy. I had already
observed a strange behavior with permissions. For example, ttf
fonts are ignored if they don't have the executable bit set.

In this case, it seems there is some other strange problem with permissions,
rather than the use of '\' or '/' as path separator. I did the following
test. Started lyx and previewed a new file through "View->PDF (pdflatex)".
The file was shown in AcroRd32. Then, without quitting lyx, I tried to
view the very same file through the command

$ AcroRd32.exe "C:/tmp/lyx_tmpdir848a00800/lyx_tmpbuf0/newfile1.pdf"

AcroRd32 ran and was consuming cpu cycles, but nothing showed up. I killed it.
Now I did:

$ mv "C:/tmp/lyx_tmpdir848a00800/lyx_tmpbuf0/newfile1.pdf" 
"C:/tmp/lyx_tmpdir848a00800/newfile1.pdf"
$ AcroRd32.exe "C:/tmp/lyx_tmpdir848a00800/newfile1.pdf"

and AcroRd32 hung again. However, after

$ mv "C:/tmp/lyx_tmpdir848a00800/newfile1.pdf" "C:/tmp/newfile1.pdf"
$ AcroRd32.exe "C:/tmp/newfile1.pdf"

AcroRd32 came up showing the file.

So, there's something in the permissions of the lyx tempdir preventing
AcroRd32 from showing the file when using '/' as a separator.
Instead, why it indeed works when using '\' really escapes me.
I had already stopped trying to find rational explanations about Windows
behavior long ago.

-- 
Enrico

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