Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Philippe Charpentier]

Le 01/04/2011 19:32, Philippe Charpentier a écrit :

On 01/04/2011 12:36:34 Julien Rioux wrote:

refstyle is activated in Document Settings, on the first page.

OK (I did not see it...)

This shows that documents produced by previous versions of LyX *and a
nonstandard prettyref.sty* cannot be correctly compiled
by LyX 2.0.

and breaks ascending compatibility

The great goal, of course, is to have all previous documents translated
to the latest version of LyX and produces the same output.
So, for one, documents which were already using prettyref will keep on
using prettyref. New documents can use refstyle, which
means that also french documents can use formatted references. The move
to refstyle was in part because refstyle allows : in
labels even in french document. Could you please check if that indeed
works for you? (it does here) If it works we can worry
about how to convert your document to using refstyle, and perhaps even
do this automatically with some added code in the
lyx2lyx converter, although this depends on how many different modified
versions of prettyref.sty are out there.

Regards,
Julien

Of course refstyle works well (except for some translations) on my
system. But to get the output given by prettyref using refstyle the
document has to be modified: all the definitions \newref has to be
redefine using the definitions \newrefformat... (including those which
are in prettyref.sty)
for example:

\newrefformat{sec}{Section \ref{#1}}

(which is defined in prettyref.sty)

has to be define for refstyle by:

\newref{sec}{%
name = Section~,
refcmd = {\ref{#1}}}

(which is not the default in refstyle)

Certainly this is easy to do automatically with documents produced by
old lyx versions. But, people which was using prettyref with previous
lyx version (and writing in french) will be obliged to use refstyle and
the output will be really different than the one given by prettyref
(without speaking of the automatic translations of the prefix with
refstyle...) and then they will be obliged to learn refstyle and to
modify the preamble of the document...

PhC

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Philippe Charpentier]

Le 01/04/2011 19:32, Philippe Charpentier a écrit :

>On 01/04/2011 12:36:34 Julien Rioux wrote:

>refstyle is activated in Document Settings, on the first page.

OK (I did not see it...)

>This shows that documents produced by previous versions of LyX *and a
nonstandard prettyref.sty* cannot be correctly compiled
>by LyX 2.0.

and breaks ascending compatibility

>The great goal, of course, is to have all previous documents translated
to the latest version of LyX and produces the same output.
>So, for one, documents which were already using prettyref will keep on
using prettyref. New documents can use refstyle, which
>means that also french documents can use formatted references. The move
to refstyle was in part because refstyle allows ":" in
>labels >even in french document. Could you please check if that indeed
works for you? (it does here) If it works we can worry
>about how to convert your document to using refstyle, and perhaps even
do this automatically with some added code in the
>lyx2lyx converter, although this depends on how many different modified
versions of prettyref.sty are out there.

>Regards,
>Julien

Of course refstyle works well (except for some translations) on my
system. But to get the output given by prettyref using refstyle the
document has to be modified: all the definitions \newref has to be
redefine using the definitions \newrefformat... (including those which
are in prettyref.sty)
for example:

\newrefformat{sec}{Section \ref{#1}}

(which is defined in prettyref.sty)

has to be define for refstyle by:

\newref{sec}{%
name = Section~,
refcmd = {\ref{#1}}}

(which is not the default in refstyle)

Certainly this is easy to do automatically with documents produced by
old lyx versions. But, people which was using prettyref with previous
lyx version (and writing in french) will be obliged to use refstyle and
the output will be really different than the one given by prettyref
(without speaking of the automatic translations of the prefix with
refstyle...) and then they will be obliged to learn refstyle and to
modify the preamble of the document...

PhC

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Philippe Charpentier]

Le 01/04/2011 16:13, Richard Heck a écrit :
 On 04/01/2011 07:02 AM, Charpentier Philippe wrote:
 Le 08.03.2011 20:16, Richard Heck a écrit :
 On 03/08/2011 11:47 AM, Charpentier Philippe wrote:
 Le 08.03.2011 14:56, Richard Heck a écrit :
 On 03/08/2011 02:34 AM, Philippe Charpentier wrote:
 Hi
 the following bug is present in the revision 37872: if I choose
 formated ref for a cross reference, the package prettyref is
 loaded in
 the LaTeX preamble but the reference is traduced by \ref{...}
 instead of
 \prettyref{...}.

 I've just tried this with latest trunk, and I do not see this
 problem. Is the label itself in the form prefix:label? If not,
 then, we do just output \ref, so the thing will compile.

 Richard

 No: with the french language and babel loaded, the form
 prefix:label will not compile on my system. As I said in a very
 old discussion, the only way to compile on all systems, is to
 modify prettyref.sty (replacing : by |) and to use
 prefix|label. This was possible with all previous versions of lyx
 and that is what I did in my french documents. Thus they will not
 compile correctly with lyx-2.0 if nothing is changed.

 Ahh, OK, then I guess we should check for the | separator, too. I'll
 do that shortly.

 That said, wasn't the introduction of refstyle supposed to be the
 solution?


 Hi,
 as I saw in lyx-devel that you are close to the final 2.0.0 release,
 I tested yesterday the svn version and I did not see any change about
 this problem. May be I missed something? If not, lyx-2.0.0 is not
 compatible with the previous versions.

 Let me ask that last question again: Are you able to set formatted
 references by using refstyle instead of prettyref? I had thought that
 this would allow the use of : as separator. If not, then I
 understand what the bug is. If so, then using refstyle (the new
 default) is the solution to this problem.

 Richard

I don't really understand:
creating a new document with lyx-2.0, if I define a label as
prefix:label and refer to it using a formatted reference, then lyx
traduce it by \prettyref{prefix}{label} and the package prettyref.sty is
loaded (and this produce always an error on my system because I modify
the prettyref package, the original one producing an error with the
french language). If the label uses a different separator (or none) then
the translation is \ref{the-label} and prettyref.sty is not loaded. I
don't see any refstyle here. This show that some documents produced by
previous versions of lyx cannot be correctly compiled with lyx-2.0.0.
Now if refstyle becomes the default, how lyx will handle the documents
written with previous versions? Moreover, most of my french documents
don't use any standard latex class neither the amsthm package which may
be a problem with refstyle...

PhC

Re: Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Philippe Charpentier]

Le 01/04/2011 16:13, Richard Heck a écrit :
> On 04/01/2011 07:02 AM, Charpentier Philippe wrote:
>> Le 08.03.2011 20:16, Richard Heck a écrit :
>>> On 03/08/2011 11:47 AM, Charpentier Philippe wrote:
>>>> Le 08.03.2011 14:56, Richard Heck a écrit :
>>>>> On 03/08/2011 02:34 AM, Philippe Charpentier wrote:
>>>>>> Hi
>>>>>> the following bug is present in the revision 37872: if I choose
>>>>>> "formated ref" for a cross reference, the package prettyref is
>>>>>> loaded in
>>>>>> the LaTeX preamble but the reference is traduced by \ref{...}
>>>>>> instead of
>>>>>> \prettyref{...}.
>>>>>>
>>>>> I've just tried this with latest trunk, and I do not see this
>>>>> problem. Is the label itself in the form "prefix:label"? If not,
>>>>> then, we do just output \ref, so the thing will compile.
>>>>>
>>>>> Richard
>>>>>
>>>> No: with the french language and babel loaded, the form
>>>> "prefix:label" will not compile on my system. As I said in a very
>>>> old discussion, the only way to compile on all systems, is to
>>>> modify prettyref.sty (replacing ":" by "|") and to use
>>>> "prefix|label". This was possible with all previous versions of lyx
>>>> and that is what I did in my french documents. Thus they will not
>>>> compile correctly with lyx-2.0 if nothing is changed.
>>>>
>>> Ahh, OK, then I guess we should check for the | separator, too. I'll
>>> do that shortly.
>>>
>>> That said, wasn't the introduction of refstyle supposed to be the
>>> solution?
>>>
>>>
>> Hi,
>> as I saw in lyx-devel that you are close to the final 2.0.0 release,
>> I tested yesterday the svn version and I did not see any change about
>> this problem. May be I missed something? If not, lyx-2.0.0 is not
>> compatible with the previous versions.
>>
> Let me ask that last question again: Are you able to set formatted
> references by using refstyle instead of prettyref? I had thought that
> this would allow the use of ":" as separator. If not, then I
> understand what the bug is. If so, then using refstyle (the new
> default) is the solution to this problem.
>
> Richard
>
I don't really understand:
creating a new document with lyx-2.0, if I define a label as
"prefix:label" and refer to it using a "formatted reference", then lyx
traduce it by \prettyref{prefix}{label} and the package prettyref.sty is
loaded (and this produce always an error on my system because I modify
the prettyref package, the original one producing an error with the
french language). If the label uses a different separator (or none) then
the translation is \ref{the-label} and prettyref.sty is not loaded. I
don't see any refstyle here. This show that some documents produced by
previous versions of lyx cannot be correctly compiled with lyx-2.0.0.
Now if refstyle becomes the default, how lyx will handle the documents
written with previous versions? Moreover, most of my french documents
don't use any standard latex class neither the amsthm package which may
be a problem with refstyle...

PhC

Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Philippe Charpentier]

Hi
the following bug is present in the revision 37872: if I choose
formated ref for a cross reference, the package prettyref is loaded in
the LaTeX preamble but the reference is traduced by \ref{...} instead of
\prettyref{...}.
Philippe Charpentier

Bug with prettyref in lyx-2.0-rc1 (rev 37872)

[Philippe Charpentier]

Hi
the following bug is present in the revision 37872: if I choose
"formated ref" for a cross reference, the package prettyref is loaded in
the LaTeX preamble but the reference is traduced by \ref{...} instead of
\prettyref{...}.
Philippe Charpentier

Re: Problem with PassThru?

[Philippe Charpentier]

Le 08/12/2010 23:00, Richard Heck a écrit :
 On 12/08/2010 01:09 PM, Philippe Charpentier wrote:
 Hi,
 I update this morning the svn version of lyx, compile it and notice the
 following bug:

 using the class article(chess), the layout Mainline is not traduced to
 latex with the command mainline: the latex code produced with this
 layout is only: {what you type
 I suppose this is a bug with PassThru, because I have other layouts
 using it and producing the same error.

 Can you please post an example file? There were some changes to
 PassThru that might be causing this.

 Richard

As I said, the simplest example is using the lyx class article (Chess)
and the layout Mainline (and activate View Source): the latex code
should be
\mainline{what you type}
and it is
{what you type

If there where changes for the tag PassThru, can you tell me how a
layout using it must be written?

PhC

Re: Problem with PassThru?

[Philippe Charpentier]

Le 09/12/2010 09:48, Jean-Marc Lasgouttes a écrit :
 Le 9 déc. 2010 à 09:43, Philippe Charpentier a écrit :
 As I said, the simplest example is using the lyx class article (Chess)
 and the layout Mainline (and activate View Source): the latex code
 should be
 \mainline{what you type}
 and it is
 {what you type

 If there where changes for the tag PassThru, can you tell me how a
 layout using it must be written?
 Try to remove the ParbreakIsNewline line.

 JMarc
This does work

PhC

Re: Problem with PassThru?

[Philippe Charpentier]

Le 08/12/2010 23:00, Richard Heck a écrit :
> On 12/08/2010 01:09 PM, Philippe Charpentier wrote:
>> Hi,
>> I update this morning the svn version of lyx, compile it and notice the
>> following bug:
>>
>> using the class article(chess), the layout Mainline is not traduced to
>> latex with the command mainline: the latex code produced with this
>> layout is only: {what you type
>> I suppose this is a bug with PassThru, because I have other layouts
>> using it and producing the same error.
>>
> Can you please post an example file? There were some changes to
> PassThru that might be causing this.
>
> Richard
>
As I said, the simplest example is using the lyx class "article (Chess)"
and the layout Mainline (and activate "View Source"): the latex code
should be
\mainline{what you type}
and it is
{what you type

If there where changes for the tag PassThru, can you tell me how a
layout using it must be written?

PhC

Re: Problem with PassThru?

[Philippe Charpentier]

Le 09/12/2010 09:48, Jean-Marc Lasgouttes a écrit :
> Le 9 déc. 2010 à 09:43, Philippe Charpentier a écrit :
>> As I said, the simplest example is using the lyx class "article (Chess)"
>> and the layout Mainline (and activate "View Source"): the latex code
>> should be
>> \mainline{what you type}
>> and it is
>> {what you type
>>
>> If there where changes for the tag PassThru, can you tell me how a
>> layout using it must be written?
> Try to remove the ParbreakIsNewline line.
>
> JMarc
This does work

PhC

Problem with PassThru?

[Philippe Charpentier]

Hi,
I update this morning the svn version of lyx, compile it and notice the
following bug:

using the class article(chess), the layout Mainline is not traduced to
latex with the command mainline: the latex code produced with this
layout is only: {what you type
I suppose this is a bug with PassThru, because I have other layouts
using it and producing the same error.

Regards
PhC

Problem with PassThru?

[Philippe Charpentier]

Hi,
I update this morning the svn version of lyx, compile it and notice the
following bug:

using the class article(chess), the layout Mainline is not traduced to
latex with the command mainline: the latex code produced with this
layout is only: {what you type
I suppose this is a bug with PassThru, because I have other layouts
using it and producing the same error.

Regards
PhC

Re: Re: [patch] default view format

[Philippe Charpentier]

a écrit :

Jürgen Spitzmüller wrote:
  

AFAICS these are leftovers from the pre-converters era. Although GuiSendto
still considers custom_export_command, I doubt anyone is actually using
this (there is no GUI). And if so, we better use session for this.

OK to remove (see attached patch)?



Since nobody complained, I did it.

Jürgen
  
I did not follow this discussion but I hope that this patch does not 
suppress the
possibility to create its own format to be able to use its own compiler. 
I do it

and use it to compile many documents which cannot be compiled with lyx
compilers (for example using pst-pdf or compiling with vtex) Precisely, I do
it creating a new format and defining the compiler (converter) from 
LaTeX (standard)

to my format which is an external application.

Sorry if this has nothing to do with this discussion.

PhC

Re: Re: [patch] default view format

[Philippe Charpentier]

a écrit :

Jürgen Spitzmüller wrote:
  

AFAICS these are leftovers from the pre-converters era. Although GuiSendto
still considers custom_export_command, I doubt anyone is actually using
this (there is no GUI). And if so, we better use session for this.

OK to remove (see attached patch)?



Since nobody complained, I did it.

Jürgen
  
I did not follow this discussion but I hope that this patch does not 
suppress the
possibility to create its own format to be able to use its own compiler. 
I do it

and use it to compile many documents which cannot be compiled with lyx
compilers (for example using pst-pdf or compiling with vtex) Precisely, I do
it creating a new format and defining the compiler (converter) from 
LaTeX (standard)

to my format which is an external application.

Sorry if this has nothing to do with this discussion.

PhC

An other bug in lyx2lyx

[Philippe Charpentier]

Hi,
here is an other bug in lyx2lyx : suppose, with lyx-1.5 you define a
command \mytextrm to be \textrm
and type, in a math formula \mytextrm{équicontinu}. This is well
traduced in latex by lyx-1.5.
But if you open the file with lyx-1.6 then the latex output is (for
example):

$F\,\mytextrm{\acute{e}quicontinu}$

which is  invalid and gets a latex error.

(lyx-1.5 traduce it  to : $F\,\mytextrm{équicontinu}$ which is correct)

Here is, attached, an example


accents-in-math.lyx
Description: application/lyx

An other bug in lyx2lyx

[Philippe Charpentier]

Hi,
here is an other bug in lyx2lyx : suppose, with lyx-1.5 you define a
command \mytextrm to be \textrm
and type, in a math formula \mytextrm{équicontinu}. This is well
traduced in latex by lyx-1.5.
But if you open the file with lyx-1.6 then the latex output is (for
example):

$F\,\mytextrm{\acute{e}quicontinu}$

which is  invalid and gets a latex error.

(lyx-1.5 traduce it  to : $F\,\mytextrm{équicontinu}$ which is correct)

Here is, attached, an example


accents-in-math.lyx
Description: application/lyx

Re: Index entries in lyx-1.6

[Philippe Charpentier]

Jürgen Spitzmüller a écrit :
 Thanks.
 The attached patch fixes these cases for me. However, I'm not sure about side 
 effects.

 Some rationale:

 1.) we put everything into ERT that is in a command, notwithstanding if it is 
 possible in a command or not. In the testcase, a modifier letter was 
 inserted, 
 which breaks compilation. The patch just reverts such things to LaTeX 
 commands 
 inside put_cmd_in_ert(string):

 @@ -50,6 +50,8 @@
+ dst + '\n\\end_layout\n\\end_inset\n')
  
  def put_cmd_in_ert(string):
 +for rep in unicode_reps:
 +string = string.replace(rep[1], rep[0].replace('', '\\'))
  string = string.replace('\\', \\backslash\n)
  string = \\begin_inset ERT\nstatus collapsed\n\\begin_layout 
 Standard\n 
 \
+ string + \n\\end_layout\n\\end_inset


 2.) we need to transform \\ to \ in latex2lyx to avoid the duplicate slashes 
 mentioned by Philippe:

 @@ -280,8 +282,11 @@
  else:
  data = data.replace(rep[0], rep[1])
  
 -# Generic, \ - :
 +# Generic
 +# \ - :
  data = wrap_into_ert(data, r'\', '')
 +# \\ - \:
 +data = data.replace('', '\\')

 2.) the patch reveals a further problem: LaTeX accent characters can be 
 followed by blank. See the variant \' Equicontinue in the test file. Even 
 though \'Equicontinue or \'{E}quicontinue is the more usual form, the 
 former works as well and thus should be supported. So we should add these 
 variants to the unicode_reps:

 @@ -156,8 +158,11 @@
  # since it is done that way in the LyX file.
  if m.group(1) == \:
  command += \\
 +commandbl = command
  command += m.group(1) + m.group(2)
 +commandbl += m.group(1) + ' ' + m.group(2)
  spec_chars.append([command, unichr(eval(ucs4))])
 +spec_chars.append([commandbl, unichr(eval(ucs4))])
  fp.close()
  return spec_chars
  
 Does this make sense?

 Jürgen
   
I just test your patch and it seems to work for the problems I mention.
But there is still an other problem:

if you create an index entry after a word which is written in bold and
if this entry contain a latex command and
a math formula at the end then this is badly converted by lyx-1.6.
Here is, attached , an example.

PhC


math-in-index.lyx
Description: application/lyx

Re: Index entries in lyx-1.6

[Philippe Charpentier]

Jürgen Spitzmüller a écrit :
> Thanks.
> The attached patch fixes these cases for me. However, I'm not sure about side 
> effects.
>
> Some rationale:
>
> 1.) we put everything into ERT that is in a command, notwithstanding if it is 
> possible in a command or not. In the testcase, a modifier letter was 
> inserted, 
> which breaks compilation. The patch just reverts such things to LaTeX 
> commands 
> inside put_cmd_in_ert(string):
>
> @@ -50,6 +50,8 @@
>+ dst + '\n\\end_layout\n\\end_inset\n')
>  
>  def put_cmd_in_ert(string):
> +for rep in unicode_reps:
> +string = string.replace(rep[1], rep[0].replace('', '\\'))
>  string = string.replace('\\', "\\backslash\n")
>  string = "\\begin_inset ERT\nstatus collapsed\n\\begin_layout 
> Standard\n" 
> \
>+ string + "\n\\end_layout\n\\end_inset"
>
>
> 2.) we need to transform \\ to \ in latex2lyx to avoid the duplicate slashes 
> mentioned by Philippe:
>
> @@ -280,8 +282,11 @@
>  else:
>  data = data.replace(rep[0], rep[1])
>  
> -# Generic, \" -> ":
> +# Generic
> +# \" -> ":
>  data = wrap_into_ert(data, r'\"', '"')
> +# \\ -> \:
> +data = data.replace('', '\\')
>
> 2.) the patch reveals a further problem: LaTeX accent characters can be 
> followed by blank. See the variant "\' Equicontinue" in the test file. Even 
> though "\'Equicontinue" or "\'{E}quicontinue" is the more usual form, the 
> former works as well and thus should be supported. So we should add these 
> variants to the unicode_reps:
>
> @@ -156,8 +158,11 @@
>  # since it is done that way in the LyX file.
>  if m.group(1) == "\"":
>  command += "\\"
> +commandbl = command
>  command += m.group(1) + m.group(2)
> +commandbl += m.group(1) + ' ' + m.group(2)
>  spec_chars.append([command, unichr(eval(ucs4))])
> +spec_chars.append([commandbl, unichr(eval(ucs4))])
>  fp.close()
>  return spec_chars
>  
> Does this make sense?
>
> Jürgen
>   
I just test your patch and it seems to work for the problems I mention.
But there is still an other problem:

if you create an index entry after a word which is written in bold and
if this entry contain a latex command and
a math formula at the end then this is badly converted by lyx-1.6.
Here is, attached , an example.

PhC


math-in-index.lyx
Description: application/lyx

Index entries in lyx-1.6

[Philippe Charpentier]

Hi,
I recently noted that index entries of lyx-1.5 are badly read by
lyx-1.6, and I did not see something
like that in bugzilla or recently in the list:
For example the following index entry written with lyx-1.5

[EMAIL PROTECTED]@\textit{Italic} : \textbackslash
textit\{...\}

is converted in lyx-1.6 to

[EMAIL PROTECTED]@\\textit{Italic} : \\textbackslash
textit\\{...\\}

the part [EMAIL PROTECTED] : \\textbackslash
textit\\{...\\} being
in ERT

Moreover, it may happens that lyx-1.6 convert an index entry into
strange characters
and then it is no more able to export the file in latex and of course
cannot compile it!
For example the following entry (written with lyx-1.5)

[EMAIL PROTECTED]@\textit{\' Equicontinue}

is converted by lyx-1.6 to

[EMAIL PROTECTED]@\textit{́ Equicontinue}

the part \textit{́ Equicontinue} being in ERT, the white part between {
and E being two strange
characters so that it cannot export (or compile) it! The error in
command line is :

Error 84 returned from iconv when converting from UCS-4LE to
ISO-8859-15: Invalid or incomplete multibyte or wide character

followed by the converted and unconverted input

PhC

Index entries in lyx-1.6

[Philippe Charpentier]

Hi,
I recently noted that index entries of lyx-1.5 are badly read by
lyx-1.6, and I did not see something
like that in bugzilla or recently in the list:
For example the following index entry written with lyx-1.5

[EMAIL PROTECTED]@\textit{Italic} : \textbackslash
textit\{...\}

is converted in lyx-1.6 to

[EMAIL PROTECTED]@\\textit{Italic} : \\textbackslash
textit\\{...\\}

the part [EMAIL PROTECTED] : \\textbackslash
textit\\{...\\} being
in ERT

Moreover, it may happens that lyx-1.6 convert an index entry into
strange characters
and then it is no more able to export the file in latex and of course
cannot compile it!
For example the following entry (written with lyx-1.5)

[EMAIL PROTECTED]@\textit{\' Equicontinue}

is converted by lyx-1.6 to

[EMAIL PROTECTED]@\textit{́ Equicontinue}

the part \textit{́ Equicontinue} being in ERT, the white part between {
and E being two strange
characters so that it cannot export (or compile) it! The error in
command line is :

Error 84 returned from iconv when converting from UCS-4LE to
ISO-8859-15: Invalid or incomplete multibyte or wide character

followed by the converted and unconverted input

PhC

UTF-8 bug in modules...

[Philippe Charpentier]

Hi
I just tried rev. 27267 and there is still a UTF-8 problem in the name
of the module.
If I put a non ASCII character in it lyx crashed (when clicking on the
module) with
the following output:

lassert.cpp(21): ASSERTION static_castunsigned char(ascii[i])  0x80
VIOLATED IN docstring.cpp:50
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check false in file lassert.cpp:23

But it is now possible to put non ASCII characters in the description.

-

I have also an other question:
as I prefer that the theorems are numbered on sections I put in my layout

DefaultModule theorems-ams-fr
DefaultModule theorems-sec-fr

When I open a new document in that class the first module is loaded but
not the second because:

BufferParams.cpp(1595): Module theorems-sec-fr dropped because
requirements not met.

This is surprising because the requirements of the second are

theorems-fr or theorems-ams-fr

and theorems-ams-fr is loaded.

PhC

Re: UTF-8 Bug in modules of lyx-1.6 and a question

[Philippe Charpentier]

Richard Heck a écrit :
 rgheck wrote:
 Charpentier Philippe wrote:
 For the first question:
 if I put
 ExcludesModule theorems-ams
 in my class then changing from article (AMS) to article (AMS)
 Francais
 has the consequence that no module is loaded which is not very nice
 I think...

 OK. I'll look at this. The algorithm that figures out what to do when
 you load a new class, with new default modules that may conflict with
 already loaded modules, is complicated, and it could certainly use
 some tweaking.

 I think this should also be solved now, along with the other bug you
 reported. Please let me know if there are still problems.

 Thanks again. I'm glad someone is finding a use for this stuff already.

 rh

I just test rev. 27282:

- for UTF-8 I all seems OK

- for the question of excluding modules, it works now if the class
contain the tag ExcludesModule, that is:
if I create a new document with the class article (AMS) then the
module theorems-ams is loaded; if
I change to the class article (AMS) Français then only the module
theorems-ams-fr is loaded which is
correct; but of course if I revert to the class article (AMS) then the
module theorems-ams-fr is still
loaded and not theorems-ams. This is safe but may be considered as a
little problem by some users.
For me this comportment is correct.

- for the question of loading automatically two modules, one depending
on the other (my last question
today), the problem is still present.

Thanks

PhC

UTF-8 bug in modules...

[Philippe Charpentier]

Hi
I just tried rev. 27267 and there is still a UTF-8 problem in the name
of the module.
If I put a non ASCII character in it lyx crashed (when clicking on the
module) with
the following output:

lassert.cpp(21): ASSERTION static_cast(ascii[i]) < 0x80
VIOLATED IN docstring.cpp:50
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:23

But it is now possible to put non ASCII characters in the description.

-

I have also an other question:
as I prefer that the theorems are numbered on sections I put in my layout

DefaultModule theorems-ams-fr
DefaultModule theorems-sec-fr

When I open a new document in that class the first module is loaded but
not the second because:

BufferParams.cpp(1595): Module theorems-sec-fr dropped because
requirements not met.

This is surprising because the requirements of the second are

theorems-fr or theorems-ams-fr

and theorems-ams-fr is loaded.

PhC

Re: UTF-8 Bug in modules of lyx-1.6 and a question

[Philippe Charpentier]

Richard Heck a écrit :
> rgheck wrote:
>> Charpentier Philippe wrote:
>>> For the first question:
>>> if I put
>>> ExcludesModule theorems-ams
>>> in my class then changing from "article (AMS)" to "article (AMS)
>>> Francais"
>>> has the consequence that no module is loaded which is not very nice
>>> I think...
>>>
>> OK. I'll look at this. The algorithm that figures out what to do when
>> you load a new class, with new default modules that may conflict with
>> already loaded modules, is complicated, and it could certainly use
>> some tweaking.
>>
> I think this should also be solved now, along with the other bug you
> reported. Please let me know if there are still problems.
>
> Thanks again. I'm glad someone is finding a use for this stuff already.
>
> rh
>
I just test rev. 27282:

- for UTF-8 I all seems OK

- for the question of excluding modules, it works now if the class
contain the tag ExcludesModule, that is:
if I create a new document with the class "article (AMS)" then the
module "theorems-ams" is loaded; if
I change to the class "article (AMS) Français" then only the module
"theorems-ams-fr" is loaded which is
correct; but of course if I revert to the class "article (AMS)" then the
module "theorems-ams-fr" is still
loaded and not "theorems-ams". This is safe but may be considered as a
little problem by some users.
For me this comportment is correct.

- for the question of loading automatically two modules, one depending
on the other (my last question
today), the problem is still present.

Thanks

PhC

Environments in rev. 27221

[Philippe Charpentier]

Recent changes (in output_latex.cpp, I suppose) introduce a new bug:
with the following lines in a lyx file

\begin_layout Itemize
aaa
\end_layout

\begin_deeper
\begin_layout Standard
aaa
\end_layout

\begin_layout Enumerate
aaa
\end_layout

\end_deeper

the Enumerate environment does not appear in the latex output.

PhC

Environments in rev. 27221

[Philippe Charpentier]

Recent changes (in output_latex.cpp, I suppose) introduce a new bug:
with the following lines in a lyx file

\begin_layout Itemize
aaa
\end_layout

\begin_deeper
\begin_layout Standard
aaa
\end_layout

\begin_layout Enumerate
aaa
\end_layout

\end_deeper

the Enumerate environment does not appear in the latex output.

PhC

Layout combobox and UTF-8 bug

[Philippe Charpentier]

Hi,
I did not find this bug in bugzilla.lyx.org :
if you type a non ASCII character in the layout combobox (Layout List
Filtering) then
lyx-1.6 crashes with the following output:

lassert.cpp(21): ASSERTION static_castunsigned char(ascii[i])  0x80
VIOLATED IN docstring.cpp:50
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check false in file lassert.cpp:23

PhC

Layout combobox and UTF-8 bug

[Philippe Charpentier]

Hi,
I did not find this bug in bugzilla.lyx.org :
if you type a non ASCII character in the layout combobox (Layout List
Filtering) then
lyx-1.6 crashes with the following output:

lassert.cpp(21): ASSERTION static_cast(ascii[i]) < 0x80
VIOLATED IN docstring.cpp:50
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:23

PhC

Environments in lyx-1.6

[Philippe Charpentier]

Hi,
Yesterday, I tried the last SVN and found the following (I did not find
this in bugzilla.lyx.org)
Suppose you want to put only an enumerate environment in a theorem. You
click
on Theorem, then you insert a % in TeX mode, you hit Enter and you
choose
enumerate. In lyx-1.5 this is traduced by

\begin{thm}
%
\begin{enumerate}
\item aaa
\end{enumerate}
\end{thm}

which is OK
and in lyx-1.6 it is traduced by

\begin{thm}
%\begin{enumerate}
\item aaa
\end{enumerate}
\end{thm}

which gives of course an error of latex compilation.

PhC

Re: Environments in lyx-1.6

[Philippe Charpentier]

Uwe Stöhr a écrit :
 That is not correct. ERT is not needed for this, also not in LyX 1.3,
 1.4, and 1.5. The correct way is to nest the enumerate into the
 theorem, see the UserGuide how nesting is done.

 Nevertheless it is a regression that we now output

 \begin{thm}
 name\begin{enumerate}
 \item aaa
 \end{enumerate}
 \end{thm}


My question was not to obtain this but the following:

\begin{thm}
\begin{enumerate}
\item aaa
\end{enumerate}
\end{thm}

that is without the word name. How do you do it in lyx?

PhC

Re: Environments in lyx-1.6

[Philippe Charpentier]

Uwe Stöhr a écrit :
  My question was not to obtain this but the following:
 
  \begin{thm}
  \begin{enumerate}
  \item aaa
  \end{enumerate}
  \end{thm}
 
  that is without the word name. How do you do it in lyx?

 See attached.

 regards Uwe

If I open your file in lyx-1.5 and put the cursor on the line of the
enumerate environment the theorem environment disappear immediately!
I don't understand how you can edit this file.

PhC

Re: Environments in lyx-1.6

[Philippe Charpentier]

Vincent van Ravesteijn a écrit :
 See attached.
 

 Which version of LyX do you have Uwe. In mine, the theorem disappears
 when moving the cursor (DEPM in action).

 That's why I proposed to adjust the DEPM not to merge paragraphs with
 different text classes.

 You can circumvent this however by:
 - shift-arrow-down
 - arrow-right
   
I think this not acceptable, as clicking  in the enumerate environment
after having
write something else using this trick makes the theorem environment
disappear an other time.
If I remember well this is related to a very old discussion of how to
nest an environment
into an empty one in lyx.

Environments in lyx-1.6

[Philippe Charpentier]

Hi,
Yesterday, I tried the last SVN and found the following (I did not find
this in bugzilla.lyx.org)
Suppose you want to put only an enumerate environment in a theorem. You
click
on "Theorem", then you insert a % in TeX mode, you hit "Enter" and you
choose
"enumerate". In lyx-1.5 this is traduced by

\begin{thm}
%
\begin{enumerate}
\item aaa
\end{enumerate}
\end{thm}

which is OK
and in lyx-1.6 it is traduced by

\begin{thm}
%\begin{enumerate}
\item aaa
\end{enumerate}
\end{thm}

which gives of course an error of latex compilation.

PhC

Re: Environments in lyx-1.6

[Philippe Charpentier]

Uwe Stöhr a écrit :
> That is not correct. ERT is not needed for this, also not in LyX 1.3,
> 1.4, and 1.5. The correct way is to nest the enumerate into the
> theorem, see the UserGuide how nesting is done.
>
> Nevertheless it is a regression that we now output
>
> \begin{thm}
> name\begin{enumerate}
> \item aaa
> \end{enumerate}
> \end{thm}
>

My question was not to obtain this but the following:

\begin{thm}
\begin{enumerate}
\item aaa
\end{enumerate}
\end{thm}

that is without the word "name". How do you do it in lyx?

PhC

Re: Environments in lyx-1.6

[Philippe Charpentier]

Uwe Stöhr a écrit :
> > My question was not to obtain this but the following:
> >
> > \begin{thm}
> > \begin{enumerate}
> > \item aaa
> > \end{enumerate}
> > \end{thm}
> >
> > that is without the word "name". How do you do it in lyx?
>
> See attached.
>
> regards Uwe

If I open your file in lyx-1.5 and put the cursor on the line of the
enumerate environment the theorem environment disappear immediately!
I don't understand how you can edit this file.

PhC

Re: Environments in lyx-1.6

[Philippe Charpentier]

Vincent van Ravesteijn a écrit :
>> See attached.
>> 
>
> Which version of LyX do you have Uwe. In mine, the theorem disappears
> when moving the cursor (DEPM in action).
>
> That's why I proposed to adjust the DEPM not to merge paragraphs with
> different text classes.
>
> You can circumvent this however by:
> - shift-arrow-down
> - arrow-right
>   
I think this not acceptable, as clicking  in the enumerate environment
after having
write something else using this trick makes the theorem environment
disappear an other time.
If I remember well this is related to a very old discussion of how to
nest an environment
into an empty one in lyx.

Re: lyx-1.6.0svn and layouts names

[Philippe Charpentier]

Philippe Charpentier a écrit :
 Hi
 if I try to use a layout whose name contains non ASCII characters
 lyx-1.6.0svn crashes:

 lassert.cpp(21): ASSERTION static_castunsigned char(ascii[i])  0x80
 VIOLATED IN docstring.cpp:50
 Assertion triggered in void lyx::doAssert(const char*, const char*, long
 int) by failing check false in file lassert.cpp:23

 About CharStyle
 I have a lot of CharStyle written for lyx-1.5.x. They don't work with
 lyx-1.6. How I have to modify them to use
 in lyx-1.6?

 PhC
   
I test the last SVN after the corrections of these problems. Now the
name of the layout
can contains UTF-8 characters and the CharStyle seems to work on a
written text,
but new bugs appear :
- if I try to insert TeX code in the document
- if I try to use a CharStyle before writing the text
then lyx crashes with the following error :

lassert.cpp(21): ASSERTION !name.empty() VIOLATED IN TextClass.cpp:882
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check false in file lassert.cpp:23

PhC

Re: lyx-1.6.0svn and layouts names

[Philippe Charpentier]

Philippe Charpentier a écrit :
> Hi
> if I try to use a layout whose name contains non ASCII characters
> lyx-1.6.0svn crashes:
>
> lassert.cpp(21): ASSERTION static_cast(ascii[i]) < 0x80
> VIOLATED IN docstring.cpp:50
> Assertion triggered in void lyx::doAssert(const char*, const char*, long
> int) by failing check "false" in file lassert.cpp:23
>
> About CharStyle
> I have a lot of CharStyle written for lyx-1.5.x. They don't work with
> lyx-1.6. How I have to modify them to use
> in lyx-1.6?
>
> PhC
>   
I test the last SVN after the corrections of these problems. Now the
name of the layout
can contains UTF-8 characters and the CharStyle seems to work on a
written text,
but new bugs appear :
- if I try to insert TeX code in the document
- if I try to use a CharStyle before writing the text
then lyx crashes with the following error :

lassert.cpp(21): ASSERTION !name.empty() VIOLATED IN TextClass.cpp:882
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:23

PhC

lyx-1.6.0svn and layouts names

[Philippe Charpentier]

Hi
if I try to use a layout whose name contains non ASCII characters
lyx-1.6.0svn crashes:

lassert.cpp(21): ASSERTION static_castunsigned char(ascii[i])  0x80
VIOLATED IN docstring.cpp:50
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check false in file lassert.cpp:23

About CharStyle
I have a lot of CharStyle written for lyx-1.5.x. They don't work with
lyx-1.6. How I have to modify them to use
in lyx-1.6?

PhC

Re: lyx-1.6.0svn and layouts names

[Philippe Charpentier]

Martin Vermeer a écrit :
 On Sat, Oct 25, 2008 at 01:58:59PM +0200, Uwe Stöhr wrote:
   
 I have a lot of CharStyle written for lyx-1.5.x. They don't work with
 lyx-1.6. How I have to modify them to use
 in lyx-1.6?
   
 They should work. Please report this bug at http://bugzilla.lyx.org. REport 
 the crash you get in a separate bug.

 thanks and regards
 Uwe
 

 Actually layout2layout handles this, under format == 4, lines 246 etc.
 Shouldn't LyX do this transparently? Please post a test CharStyle that
 fails.

 - Martin

   
For  example, the following CharStyle

CharStyle Semi-Bold
LatexType Command
LatexName textsb
Font
  Family  Roman
  Series  Bold
EndFont
LabelFont
  Family  Roman
  Size  tiny
  Color   blue
EndFont
Preamble
\usepackage{sbdefault}
EndPreamble
End

which is working in lyx-1.5 does not work in lyx-1.6 :
It appears in the list of CharStyles (in the menu Edit),
the command \usepackage{sbdefault} is put in the preamble
but the command \textsb{} is not written in the latex source

PhC

Re: lyx-1.6.0svn and layouts names

[Philippe Charpentier]

rgheck a écrit :
 Philippe Charpentier wrote:
 For  example, the following CharStyle

 CharStyle Semi-Bold
 LatexType Command
 LatexName textsb
 Font
   Family  Roman
   Series  Bold
 EndFont
 LabelFont
   Family  Roman
   Size  tiny
   Color   blue
 EndFont
 Preamble
 \usepackage{sbdefault}
 EndPreamble
 End

 which is working in lyx-1.5 does not work in lyx-1.6 :
 It appears in the list of CharStyles (in the menu Edit),
 the command \usepackage{sbdefault} is put in the preamble
 but the command \textsb{} is not written in the latex source

   
 The problem is that it had to be command, lower case. I've fixed this.

 rh

OK, but it seems that Command does not work *only* for CharStyles...!

PhC

lyx-1.6.0svn and layouts names

[Philippe Charpentier]

Hi
if I try to use a layout whose name contains non ASCII characters
lyx-1.6.0svn crashes:

lassert.cpp(21): ASSERTION static_cast(ascii[i]) < 0x80
VIOLATED IN docstring.cpp:50
Assertion triggered in void lyx::doAssert(const char*, const char*, long
int) by failing check "false" in file lassert.cpp:23

About CharStyle
I have a lot of CharStyle written for lyx-1.5.x. They don't work with
lyx-1.6. How I have to modify them to use
in lyx-1.6?

PhC

Re: lyx-1.6.0svn and layouts names

[Philippe Charpentier]

Martin Vermeer a écrit :
> On Sat, Oct 25, 2008 at 01:58:59PM +0200, Uwe Stöhr wrote:
>   
>>> I have a lot of CharStyle written for lyx-1.5.x. They don't work with
>>> lyx-1.6. How I have to modify them to use
>>> in lyx-1.6?
>>>   
>> They should work. Please report this bug at http://bugzilla.lyx.org. REport 
>> the crash you get in a separate bug.
>>
>> thanks and regards
>> Uwe
>> 
>
> Actually layout2layout handles this, under format == 4, lines 246 etc.
> Shouldn't LyX do this transparently? Please post a test CharStyle that
> fails.
>
> - Martin
>
>   
For  example, the following CharStyle

CharStyle Semi-Bold
LatexType Command
LatexName textsb
Font
  Family  Roman
  Series  Bold
EndFont
LabelFont
  Family  Roman
  Size  tiny
  Color   blue
EndFont
Preamble
\usepackage{sbdefault}
EndPreamble
End

which is working in lyx-1.5 does not work in lyx-1.6 :
It appears in the list of CharStyles (in the menu "Edit"),
the command \usepackage{sbdefault} is put in the preamble
but the command \textsb{} is not written in the latex source

PhC

Re: lyx-1.6.0svn and layouts names

[Philippe Charpentier]

rgheck a écrit :
> Philippe Charpentier wrote:
>> For  example, the following CharStyle
>>
>> CharStyle Semi-Bold
>> LatexType Command
>> LatexName textsb
>> Font
>>   Family  Roman
>>   Series  Bold
>> EndFont
>> LabelFont
>>   Family  Roman
>>   Size  tiny
>>   Color   blue
>> EndFont
>> Preamble
>> \usepackage{sbdefault}
>> EndPreamble
>> End
>>
>> which is working in lyx-1.5 does not work in lyx-1.6 :
>> It appears in the list of CharStyles (in the menu "Edit"),
>> the command \usepackage{sbdefault} is put in the preamble
>> but the command \textsb{} is not written in the latex source
>>
>>   
> The problem is that it had to be "command", lower case. I've fixed this.
>
> rh
>
OK, but it seems that "Command" does not work *only* for CharStyles...!

PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Abdelrazak Younes a écrit :

Philippe Charpentier wrote:

During my tests I found the three bugs below, I did not found in 
bugzilla:


* About layouts: the tag DependsOn does not works when it calls a 
Style whose name contains
 special characters. I cannot test everything, but I suspect that it 
does not works when the name of

 called Style contains an underscore ( _ )


What does that mean does not work? Is it a crash? Or just the LateX 
that does not compile?


Abdel.
The Preamble of the Style called by the tag is not put in the Preamble 
of the document and LaTeX

does not compile.

PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Jürgen Spitzmüller a écrit :

Philippe Charpentier wrote:
  

The Preamble of the Style called by the tag is not put in the Preamble
of the document and LaTeX
does not compile.



So bug 3521?
http://bugzilla.lyx.org/show_bug.cgi?id=3521

Jürgen
  
I don't think so. If I understand well, bug 3521 is related to non ascii 
characters in layouts which is solved now.
I will try to get time to create simple Styles with the same problem and 
I will post the result in the list.


PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Philippe Charpentier a écrit :

Jürgen Spitzmüller a écrit :

Philippe Charpentier wrote:
 

The Preamble of the Style called by the tag is not put in the Preamble
of the document and LaTeX
does not compile.



So bug 3521?
http://bugzilla.lyx.org/show_bug.cgi?id=3521

Jürgen
  
I don't think so. If I understand well, bug 3521 is related to non 
ascii characters in layouts which is solved now.
I will try to get time to create simple Styles with the same problem 
and I will post the result in the list.


PhC


I made the test and my first impression was wright:
Create the following Styles:

Style Test_A
 Margin  Static
 LatexType Command
 LatexName TestA
 ParIndentMM
 ParSkip 0.4
 Align Block
 AlignPossible Block, Left, Right, Center
 LabelType No_Label
 Preamble
\def\TestA#1{\textcolor{blue}{#1}}
 EndPreamble
End

Style TestA
 CopyStyleTest_A
 DependsOnTest_A
 Preamble
 EndPreamble
End

Style TestB
 Margin  Static
 LatexType Command
 LatexName TestB
 ParIndentMM
 ParSkip 0.4
 Align Block
 AlignPossible Block, Left, Right, Center
 LabelType No_Label
 Preamble
\def\TestB#1{\textcolor{red}{#1}}
 EndPreamble
End

Style Test_B
 CopyStyleTestB
 DependsOnTestB
 Preamble
 EndPreamble
End

Then:

Test_B works : the Preamble of TestB is put in the Preamble of the document
TestA does not works : the Preamble of Test_A is not put in the Preamble 
of the document


PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

Philippe == Philippe Charpentier [EMAIL PROTECTED] writes:



Philippe I made the test and my first impression was wright: 


Does the following patch help?

JMarc

  

I just test it on the latest svn : it works fine

PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

Philippe == Philippe Charpentier [EMAIL PROTECTED] writes:



Philippe I just test it on the latest svn : it works fine

OK, put it in. This issue existed also with 1.3.x and 1.4.x, right?

JMarc
  

Yes

PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Abdelrazak Younes a écrit :

During my tests I found the three bugs below, I did not found in 
bugzilla:


* About layouts: the tag "DependsOn" does not works when it calls a 
Style whose name contains
 special characters. I cannot test everything, but I suspect that it 
does not works when the name of

 called Style contains an underscore ( _ )


What does that mean "does not work"? Is it a crash? Or just the LateX 
that does not compile?


Abdel.
The Preamble of the Style called by the tag is not put in the Preamble 
of the document and LaTeX

does not compile.

PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Jürgen Spitzmüller a écrit :

Philippe Charpentier wrote:
  

The Preamble of the Style called by the tag is not put in the Preamble
of the document and LaTeX
does not compile.



So bug 3521?
http://bugzilla.lyx.org/show_bug.cgi?id=3521

Jürgen
  
I don't think so. If I understand well, bug 3521 is related to non ascii 
characters in layouts which is solved now.
I will try to get time to create simple Styles with the same problem and 
I will post the result in the list.


PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Philippe Charpentier a écrit :

Jürgen Spitzmüller a écrit :

Philippe Charpentier wrote:
 

The Preamble of the Style called by the tag is not put in the Preamble
of the document and LaTeX
does not compile.



So bug 3521?
http://bugzilla.lyx.org/show_bug.cgi?id=3521

Jürgen
  
I don't think so. If I understand well, bug 3521 is related to non 
ascii characters in layouts which is solved now.
I will try to get time to create simple Styles with the same problem 
and I will post the result in the list.


PhC


I made the test and my first impression was wright:
Create the following Styles:

Style Test_A
 Margin  Static
 LatexType Command
 LatexName TestA
 ParIndentMM
 ParSkip 0.4
 Align Block
 AlignPossible Block, Left, Right, Center
 LabelType No_Label
 Preamble
\def\TestA#1{\textcolor{blue}{#1}}
 EndPreamble
End

Style TestA
 CopyStyleTest_A
 DependsOnTest_A
 Preamble
 EndPreamble
End

Style TestB
 Margin  Static
 LatexType Command
 LatexName TestB
 ParIndentMM
 ParSkip 0.4
 Align Block
 AlignPossible Block, Left, Right, Center
 LabelType No_Label
 Preamble
\def\TestB#1{\textcolor{red}{#1}}
 EndPreamble
End

Style Test_B
 CopyStyleTestB
 DependsOnTestB
 Preamble
 EndPreamble
End

Then:

Test_B works : the Preamble of TestB is put in the Preamble of the document
TestA does not works : the Preamble of Test_A is not put in the Preamble 
of the document


PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

"Philippe" == Philippe Charpentier <[EMAIL PROTECTED]> writes:



Philippe> I made the test and my first impression was wright: 


Does the following patch help?

JMarc

  

I just test it on the latest svn : it works fine

PhC

Re: UTF-8 and layouts - bugs

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

"Philippe" == Philippe Charpentier <[EMAIL PROTECTED]> writes:



Philippe> I just test it on the latest svn : it works fine

OK, put it in. This issue existed also with 1.3.x and 1.4.x, right?

JMarc
  

Yes

PhC

Re: Re: [Patch] allow unicode in layout style name

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:



  

Why not? It is easier to use has a file with coherent encoding that
one that uses a mixed encoding.
  


Abdelrazak I agree with Jose. I cannot see a reason why mixed
Abdelrazak encoding would be preferred.

I am not sure we are discussing the same thing. Assume one has a file
in 1.4 file format with contents in latin1 and some layout names in
latin1 too. What do you propose to do?

I see two solutions.

1/ first convert the latin1 file to utf8 in one sweep and hope that
lyx2lyx will not butcher it when translating to 1.5 file format

2/ first convert to 1.5 file format. Then only the layout names should
be converted in a second step. I do not think that iconv would
appreciate to see UTF8 characters in a file which is supposed to be
latin1.

JMarc
  

Hi,
I just had time to test Abdel patch layout_name_is_unicode.patch with 
the latest svn:

After a quick test I think it works perfectly!
All my layouts (converted in UTF-8) are recognized and lyx accept to 
open every files created with previous versions
(in fact almost: there is still a problem with old files using the tag 
\language frenchb and perhaps others...?)

as they are (i.e. without any conversion).
Thus, for me, this is probably the best solution!

Thank you very much

PhC

Re: [Patch] allow unicode in layout style name

[Philippe Charpentier]

José Abilio a écrit :

On Tuesday 10 July 2007 15:13:49 Philippe Charpentier wrote:
  

(in fact almost: there is still a problem with old files using the tag
\language frenchb and perhaps others...?)
as they are (i.e. without any conversion).



  lyx2lyx converts those documents coming from 1.3.x or before. Isn't that 
working?

When I open some old files I obtain the following error:

Traceback (most recent call last):
 File /usr/local/lyx-1.5-UTF-8/share/lyx/./lyx2lyx/lyx2lyx, line 101, 
in module

   sys.exit(main(sys.argv))
 File /usr/local/lyx-1.5-UTF-8/share/lyx/./lyx2lyx/lyx2lyx, line 92, 
in main
   file = LyX.File(end_format, input, output, error, debug, try_hard, 
cjk_encoding)
 File /usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py, line 556, in 
__init__

   self.read()
 File /usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py, line 242, in 
read
   self.encoding = get_encoding(self.language, self.inputencoding, 
self.format, self.cjk_encoding)
 File /usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py, line 128, in 
get_encoding

   return lang[language][3]
KeyError: 'frenchb'
Error: Échec du script de conversion

but, if I manually replace \language frenchb by \language french in 
the file, lyx2lyx

converts it successfully...

PhC

Re: [Patch] allow unicode in layout style name

[Philippe Charpentier]

José Abilio à écrit:


   lyx2lyx converts those documents coming from 1.3.x or before. Isn't
 that working?

When I open some old files I obtain the following error:



How old are those files? What is the file format number for those files?


The format number of the file I tested is 221 and it was created in 2003 (I 
think)

PhC

UTF-8 and layouts - bugs

[Philippe Charpentier]

Hi,
yesterday I test Abdel's patch layout_name_is_unicode.patch with the 
latest svn. I send a message
to lyx-devel, but as I don't see it on mail-archive.com 
http://www.mail-archive.com/lyx-devel@lists.lyx.org/ I send an other 
one and add some bugs I found.


Abdel's patch works perfectly with all my layouts and all my old lyx 
files (with the exceptions below):

the only thing I did was to convert my layouts in UTF-8.
Thus, for me, this patch is a perfect solution for the upgrade from 1.4 
to 1.5!


During my tests I found the three bugs below, I did not found in bugzilla:

* About layouts: the tag DependsOn does not works when it calls a 
Style whose name contains
 special characters. I cannot test everything, but I suspect that it 
does not works when the name of

 called Style contains an underscore ( _ )

*About lyx2lyx: it fails to convert an old lyx file containing the 
command \language frenchb


* In a new document write: a word
 Then change the size of the two words to small; then change the color 
of a (to red for example).
 Then lyx traduce it as : \textcolor{red}{\small a}{\small  word} and 
the space between a and

 word disappear.

PhC

Re: Re: [Patch] allow unicode in layout style name

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:



  

Why not? It is easier to use has a file with coherent encoding that
one that uses a mixed encoding.
  


Abdelrazak> I agree with Jose. I cannot see a reason why mixed
Abdelrazak> encoding would be preferred.

I am not sure we are discussing the same thing. Assume one has a file
in 1.4 file format with contents in latin1 and some layout names in
latin1 too. What do you propose to do?

I see two solutions.

1/ first convert the latin1 file to utf8 in one sweep and hope that
lyx2lyx will not butcher it when translating to 1.5 file format

2/ first convert to 1.5 file format. Then only the layout names should
be converted in a second step. I do not think that iconv would
appreciate to see UTF8 characters in a file which is supposed to be
latin1.

JMarc
  

Hi,
I just had time to test Abdel patch "layout_name_is_unicode.patch" with 
the latest svn:

After a quick test I think it works perfectly!
All my layouts (converted in UTF-8) are recognized and lyx accept to 
open every files created with previous versions
(in fact almost: there is still a problem with old files using the tag 
"\language frenchb" and perhaps others...?)

as they are (i.e. without any conversion).
Thus, for me, this is probably the best solution!

Thank you very much

PhC

Re: [Patch] allow unicode in layout style name

[Philippe Charpentier]

José Abilio a écrit :

On Tuesday 10 July 2007 15:13:49 Philippe Charpentier wrote:
  

(in fact almost: there is still a problem with old files using the tag
"\language frenchb" and perhaps others...?)
as they are (i.e. without any conversion).



  lyx2lyx converts those documents coming from 1.3.x or before. Isn't that 
working?

When I open some old files I obtain the following error:

Traceback (most recent call last):
 File "/usr/local/lyx-1.5-UTF-8/share/lyx/./lyx2lyx/lyx2lyx", line 101, 
in 

   sys.exit(main(sys.argv))
 File "/usr/local/lyx-1.5-UTF-8/share/lyx/./lyx2lyx/lyx2lyx", line 92, 
in main
   file = LyX.File(end_format, input, output, error, debug, try_hard, 
cjk_encoding)
 File "/usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py", line 556, in 
__init__

   self.read()
 File "/usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py", line 242, in 
read
   self.encoding = get_encoding(self.language, self.inputencoding, 
self.format, self.cjk_encoding)
 File "/usr/local/lyx-1.5-UTF-8/share/lyx/lyx2lyx/LyX.py", line 128, in 
get_encoding

   return lang[language][3]
KeyError: 'frenchb'
Error: Échec du script de conversion

but, if I manually replace "\language frenchb" by "\language french" in 
the file, lyx2lyx

converts it successfully...

PhC

Re: [Patch] allow unicode in layout style name

[Philippe Charpentier]

José Abilio à écrit:


>   lyx2lyx converts those documents coming from 1.3.x or before. Isn't
> that working?

When I open some old files I obtain the following error:



How old are those files? What is the file format number for those files?


The format number of the file I tested is 221 and it was created in 2003 (I 
think)

PhC

UTF-8 and layouts - bugs

[Philippe Charpentier]

Hi,
yesterday I test Abdel's patch "layout_name_is_unicode.patch" with the 
latest svn. I send a message
to lyx-devel, but as I don't see it on mail-archive.com 
 I send an other 
one and add some bugs I found.


Abdel's patch works perfectly with all my layouts and all my old lyx 
files (with the exceptions below):

the only thing I did was to convert my layouts in UTF-8.
Thus, for me, this patch is a perfect solution for the upgrade from 1.4 
to 1.5!


During my tests I found the three bugs below, I did not found in bugzilla:

* About layouts: the tag "DependsOn" does not works when it calls a 
Style whose name contains
 special characters. I cannot test everything, but I suspect that it 
does not works when the name of

 called Style contains an underscore ( _ )

*About lyx2lyx: it fails to convert an old lyx file containing the 
command "\language frenchb"


* In a new document write: a word
 Then change the size of the two words to small; then change the color 
of "a" (to red for example).
 Then lyx traduce it as : \textcolor{red}{\small a}{\small  word} and 
the space between "a" and

 "word" disappear.

PhC

Re: Upgrade from 1.4 to 1.5

[Philippe Charpentier]

 1) provide a python script that converts the layout as good as
possible:
  Théorème  - Theoreme
 Liste_à_puce - Liste_a_puce

This seems difficult:
first such a script may give the same name to two different Styles
second this conversion has to be done also in the documents

 2) Accept the layout field as is and do not try to translate them.

Of course, accept Style names with non ASCII characters (like in the
previous versions of lyx) would be the simplest way for me. But in that case
if the layout in UTF-8 probably the document has to be in the same
encoding (if its possible?) which means that lyx have to convert it 
automatically.

 Do you really have a lot of these? I guess you've written them by hand
 so it should be easy enough to correct them by hand, shouldn't it?

All my documents where written with my layouts and as I use lyx since
the 1.2 version I have a lot! (94 different files for the layouts
a lot of mathematical papers, mathematical books teaching documents,
letters etc...).

Traduce my layout to be accepted by the actual lyx-1.5 is not really
a problem, but traduce all my actual documents to be read by lyx-1.5 with the
new Style names is for me probably almost impossible!

PhC

[Updated PATCH] accept utf8 in layout files (was Re: Upgrade from 1.4 to 1.5)

[Philippe Charpentier]

I would like to test your patch, but I don't understand how to apply it

Can you tell me?

Thanks

PhC

Re: Upgrade from 1.4 to 1.5

[Philippe Charpentier]

> 1) provide a python script that converts the layout as good as
possible:
>  Théorème  -> Theoreme
> Liste_à_puce -> Liste_a_puce

This seems difficult:
first such a script may give the same name to two different Styles
second this conversion has to be done also in the documents

> 2) Accept the layout field as is and do not try to translate them.

Of course, accept Style names with non ASCII characters (like in the
previous versions of lyx) would be the simplest way for me. But in that case
if the layout in UTF-8 probably the document has to be in the same
encoding (if its possible?) which means that lyx have to convert it 
automatically.

> Do you really have a lot of these? I guess you've written them by hand
> so it should be easy enough to correct them by hand, shouldn't it?

All my documents where written with my layouts and as I use lyx since
the 1.2 version I have a lot! (94 different files for the layouts
a lot of mathematical papers, mathematical books teaching documents,
letters etc...).

Traduce my layout to be accepted by the actual lyx-1.5 is not really
a problem, but traduce all my actual documents to be read by lyx-1.5 with the
new Style names is for me probably almost impossible!

PhC

[Updated PATCH] accept utf8 in layout files (was Re: Upgrade from 1.4 to 1.5)

[Philippe Charpentier]

I would like to test your patch, but I don't understand how to apply it

Can you tell me?

Thanks

PhC

amsart-plain.layout and a question

[Philippe Charpentier]

Hi,
I notice the following small bug in amsart-plain.layout:

Input amsart.layout - Input amsdef.inc - Input ammsmath.inc

Input amsmaths-plain.inc

Thus both Theorem and Theorem* appear in the layout combobox, which is not
useful, and if you choose both you get a LaTeX error as they define the 
same newtheorem*.


Now my question. As I don't like very much the layout combobox, I wrote 
my own
ui files containing all the layouts of the five main classes I generally 
use. Does
there is a way to have active in the menus only the layouts which are in 
the class

used by the document (and not all the layout appearing in the ui file)?

Philippe Charpentier

amsart-plain.layout and a question

[Philippe Charpentier]

Hi,
I notice the following small bug in amsart-plain.layout:

Input amsart.layout -> Input amsdef.inc -> Input ammsmath.inc

Input amsmaths-plain.inc

Thus both Theorem and Theorem* appear in the layout combobox, which is not
useful, and if you choose both you get a LaTeX error as they define the 
same newtheorem*.


Now my question. As I don't like very much the layout combobox, I wrote 
my own
ui files containing all the layouts of the five main classes I generally 
use. Does
there is a way to have active in the menus only the layouts which are in 
the class

used by the document (and not all the layout appearing in the ui file)?

Philippe Charpentier

Re: qt or lyx or FC5 bug ?

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

Philippe == Philippe Charpentier [EMAIL PROTECTED] writes:



Philippe No (it does not depend on fr, but on the fact that the LANG
Philippe variable is not en_EN). 


I would say it depends on whether the locale uses , for numbers.

It looks like Qt sets the LC_CTYPE locale. Would that be possible?

What Qt version comes with fc5?

JMarc

  

After some tests, I found the following (for the qt frontend):
in a terminal if I type:
export LANG=fr_FR (or whatever different of en_...)
export LC_NUMERIC=C
lyx
then all seems to work fine!
Is this a lyx bug?

PhC

Re: qt or lyx or FC5 bug ?

[Philippe Charpentier]

Jean-Marc Lasgouttes a écrit :

"Philippe" == Philippe Charpentier <[EMAIL PROTECTED]> writes:



Philippe> No (it does not depend on fr, but on the fact that the LANG
Philippe> variable is not en_EN). 


I would say it depends on whether the locale uses "," for numbers.

It looks like Qt sets the LC_CTYPE locale. Would that be possible?

What Qt version comes with fc5?

JMarc

  

After some tests, I found the following (for the qt frontend):
in a terminal if I type:
export LANG=fr_FR (or whatever different of en_...)
export LC_NUMERIC=C
lyx
then all seems to work fine!
Is this a lyx bug?

PhC

Re: qt or lyx or FC5 bug ?

[Philippe Charpentier]

Martin Vermeer a écrit :

On Wed, 2006-04-12 at 00:18 +0200, Philippe Charpentier wrote:
  

Hi,
Under my Fedora Core 5 box, I encounter the following surprising bug 
with the qt frontend : if your LANG shell is not English (en_EN for 
example) you cannot enter a decimal number in a dialog box!!

Here is two examples:
suppose your LANG shell is fr_FR (the same occurs with de_DE, es_ES, 
it_IT...); open lyx (1.4.0 or 1.4.1) and create a new document.
- Try to change the top margin to 2.5 cm; close the dialog box clicking 
the OK button and reopen it: the top margin is 2 cm!!
- Insert a vertical space of 1.5 cm and click OK or Apply : you obtain a 
1 cm vertical space!!


If the LANG is set to en_EN this bug does not appear!!

I also notice that this bug does not exist with the xforms frontend.

Is it a qt bug, a lyx bug or a FC5 bug? It does not exist in Fedora Core 
3 or Mandrake 10.1.



Is it a bug at all? Doesn't French use a decimal comma?
  
No (it does not depend on fr, but on the fact that the LANG variable is 
not en_EN). For example, in the lyx file the top margin is written

\topmargin 2.5cm
but if you edit the file in lyx and open the document properties and 
click OK, then the corresponding line is automatically change into

\topmargin 2cm
and the same occur with vertical spaces.
I test it changing my LANG variable, and the only one which does not 
produce the bug is the english one. That is I am obliged to force the 
LANG variable to be en_EN to be able to use lyx.

It seems this behaviour is that of lexical_cast (boost). It should work
OK in all locales
But this is not the case... and it is related to the qt frontend under 
FC5 (as I said this bug does not happen with the xform frontend  in FC5 
neither with the qt frontend in FC3 or Mandrake 10.1).


PhC

Re: qt or lyx or FC5 bug ?

[Philippe Charpentier]

Martin Vermeer a écrit :

On Wed, 2006-04-12 at 00:18 +0200, Philippe Charpentier wrote:
  

Hi,
Under my Fedora Core 5 box, I encounter the following surprising bug 
with the qt frontend : if your LANG shell is not English (en_EN for 
example) you cannot enter a decimal number in a dialog box!!

Here is two examples:
suppose your LANG shell is fr_FR (the same occurs with de_DE, es_ES, 
it_IT...); open lyx (1.4.0 or 1.4.1) and create a new document.
- Try to change the top margin to 2.5 cm; close the dialog box clicking 
the OK button and reopen it: the top margin is 2 cm!!
- Insert a vertical space of 1.5 cm and click OK or Apply : you obtain a 
1 cm vertical space!!


If the LANG is set to en_EN this bug does not appear!!

I also notice that this bug does not exist with the xforms frontend.

Is it a qt bug, a lyx bug or a FC5 bug? It does not exist in Fedora Core 
3 or Mandrake 10.1.



Is it a bug at all? Doesn't French use a decimal comma?
  
No (it does not depend on fr, but on the fact that the LANG variable is 
not en_EN). For example, in the lyx file the top margin is written

\topmargin 2.5cm
but if you edit the file in lyx and open the document properties and 
click OK, then the corresponding line is automatically change into

\topmargin 2cm
and the same occur with vertical spaces.
I test it changing my LANG variable, and the only one which does not 
produce the bug is the english one. That is I am obliged to force the 
LANG variable to be en_EN to be able to use lyx.

It seems this behaviour is that of lexical_cast (boost). It should work
OK in all locales
But this is not the case... and it is related to the qt frontend under 
FC5 (as I said this bug does not happen with the xform frontend  in FC5 
neither with the qt frontend in FC3 or Mandrake 10.1).


PhC

qt or lyx or FC5 bug ?

[Philippe Charpentier]

Hi,
Under my Fedora Core 5 box, I encounter the following surprising bug 
with the qt frontend : if your LANG shell is not English (en_EN for 
example) you cannot enter a decimal number in a dialog box!!

Here is two examples:
suppose your LANG shell is fr_FR (the same occurs with de_DE, es_ES, 
it_IT...); open lyx (1.4.0 or 1.4.1) and create a new document.
- Try to change the top margin to 2.5 cm; close the dialog box clicking 
the OK button and reopen it: the top margin is 2 cm!!
- Insert a vertical space of 1.5 cm and click OK or Apply : you obtain a 
1 cm vertical space!!


If the LANG is set to en_EN this bug does not appear!!

I also notice that this bug does not exist with the xforms frontend.

Is it a qt bug, a lyx bug or a FC5 bug? It does not exist in Fedora Core 
3 or Mandrake 10.1.


Philippe Charpentier

qt or lyx or FC5 bug ?

[Philippe Charpentier]

Hi,
Under my Fedora Core 5 box, I encounter the following surprising bug 
with the qt frontend : if your LANG shell is not English (en_EN for 
example) you cannot enter a decimal number in a dialog box!!

Here is two examples:
suppose your LANG shell is fr_FR (the same occurs with de_DE, es_ES, 
it_IT...); open lyx (1.4.0 or 1.4.1) and create a new document.
- Try to change the top margin to 2.5 cm; close the dialog box clicking 
the OK button and reopen it: the top margin is 2 cm!!
- Insert a vertical space of 1.5 cm and click OK or Apply : you obtain a 
1 cm vertical space!!


If the LANG is set to en_EN this bug does not appear!!

I also notice that this bug does not exist with the xforms frontend.

Is it a qt bug, a lyx bug or a FC5 bug? It does not exist in Fedora Core 
3 or Mandrake 10.1.


Philippe Charpentier

lyx-1.4.0 FC5

[Philippe Charpentier]

Hi,
on Fedora Core 5, it seems that it is impossible to enter a number with 
a point (like 1.5) in the margin dialog of the document. On FC3 there is 
not such problem.


Philippe Charpentier

lyx-1.4.0 FC5

[Philippe Charpentier]

Hi,
on Fedora Core 5, it seems that it is impossible to enter a number with 
a point (like 1.5) in the margin dialog of the document. On FC3 there is 
not such problem.


Philippe Charpentier

Vertical spaces lyx-1.3 lyx-1.4

[Philippe Charpentier]

Hi,
I made some test with lyx-1.4.0pre6 and notice the following problem: 
when lyx-1.4.0pre6 reads a file, written with lyx-1.3, if the file 
contain a environment with vertical spaces inside, then the environment 
is broken into peaces. I don't know if this is a known problem or if I 
am missing something... As you plan to release lyx-1.4.0 soon, I post it.

Here is an example with a proof environment:

#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass amsart
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize a3paper
\paperpackage a4
\use_geometry 1
\use_amsmath 1
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\leftmargin 1.5cm
\topmargin 2.5cm
\rightmargin 1.5cm
\bottommargin 2cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language french
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default

\layout Proof
\added_space_bottom bigskip
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\layout Proof

Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\the_end

If I read this file with lyx-1.4.0pre6 and save it, I obtain:

#LyX 1.4.0pre6 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass amsart
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry true
\use_amsmath 2
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\leftmargin 1.5cm
\topmargin 2.5cm
\rightmargin 1.5cm
\bottommargin 2cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language french
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes true
\end_header

\begin_body

\begin_layout Proof
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\end_layout

\begin_layout Standard
\begin_inset VSpace bigskip
\end_inset


\end_layout

\begin_layout Proof
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\end_layout

\end_body
\end_document

As you can see, the proof environment is broken into two proof 
environments. I test this with the enumere environment with the same 
result, if the space is inserted at the first level. If this appears 
many times in a large document and for several environments it can 
become a real problem...
An other small thing which can be seen on this example is: by default I 
use A4 papersize, but the file uses A3 paper. This is forget by 
lyx-1.4.0pre6 which always uses the default papersize when it reads a 
lyx-1.3 file.


PhC

Re: Vertical spaces lyx-1.3 lyx-1.4

[Philippe Charpentier]

Lars Gullik Bjønnes writes:


As you can see, the proof environment is broken into two proof
environments. I test this with the enumere environment with the same
result, if the space is inserted at the first level. If this appears
many times in a large document and for several environments it can
become a real problem...


It is a deliberate change.


I understand. But, for example, if you have a proof environment containing some 
lemmas
with their proofs, and if you have some vertical spaces in the lemmas (why 
not?) and
in the proofs, the file read by lyx-1.4.0pre6 looks very strange!

PhC

Vertical spaces lyx-1.3 lyx-1.4

[Philippe Charpentier]

Hi,
I made some test with lyx-1.4.0pre6 and notice the following problem: 
when lyx-1.4.0pre6 reads a file, written with lyx-1.3, if the file 
contain a environment with vertical spaces inside, then the environment 
is broken into peaces. I don't know if this is a known problem or if I 
am missing something... As you plan to release lyx-1.4.0 soon, I post it.

Here is an example with a proof environment:

#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 221
\textclass amsart
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize a3paper
\paperpackage a4
\use_geometry 1
\use_amsmath 1
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\leftmargin 1.5cm
\topmargin 2.5cm
\rightmargin 1.5cm
\bottommargin 2cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language french
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default

\layout Proof
\added_space_bottom bigskip
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\layout Proof

Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\the_end

If I read this file with lyx-1.4.0pre6 and save it, I obtain:

#LyX 1.4.0pre6 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass amsart
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry true
\use_amsmath 2
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\leftmargin 1.5cm
\topmargin 2.5cm
\rightmargin 1.5cm
\bottommargin 2cm
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language french
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes true
\end_header

\begin_body

\begin_layout Proof
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\end_layout

\begin_layout Standard
\begin_inset VSpace bigskip
\end_inset


\end_layout

\begin_layout Proof
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...
Proof...

\end_layout

\end_body
\end_document

As you can see, the proof environment is broken into two proof 
environments. I test this with the enumere environment with the same 
result, if the space is inserted at the first level. If this appears 
many times in a large document and for several environments it can 
become a real problem...
An other small thing which can be seen on this example is: by default I 
use A4 papersize, but the file uses A3 paper. This is forget by 
lyx-1.4.0pre6 which always uses the default papersize when it reads a 
lyx-1.3 file.


PhC

Re: Vertical spaces lyx-1.3 lyx-1.4

[Philippe Charpentier]

Lars Gullik Bjønnes writes:


As you can see, the proof environment is broken into two proof
environments. I test this with the enumere environment with the same
result, if the space is inserted at the first level. If this appears
many times in a large document and for several environments it can
become a real problem...


It is a deliberate change.


I understand. But, for example, if you have a proof environment containing some 
lemmas
with their proofs, and if you have some vertical spaces in the lemmas (why 
not?) and
in the proofs, the file read by lyx-1.4.0pre6 looks very strange!

PhC

Re: Strange...

[Philippe Charpentier]

   OK. Then, as this can occur for many packages names, a simple solution
   would be that lyx compile tmp_filename.tex instead of filename.tex,
   because the error message of the compiler is not very explicit.
 


LyX should give a warning if kpsewhich filename.tex  has a result.


This is also a very god idea


   lyx team have the intention to implement the compilation of a file
   which uses this package? That is, if a file using pst-pdf (in the
   preamble) is compiled using Vsualize-pdflatex then then the
   compilation would be done with latex (+ bibtex, makeindex if needed),
   dvips(...), ps2pdf(...) and pdflatex. I recall, as I already told in
 



 you can do it by yourself, create a new format pdf4, for which you 
run the skript ps4pdf 
 
http://www.ctan.org/tex-archive/graphics/pstricks/contrib/pst-pdf/scripts/


I know, but this is not the same thing.

http://www.ctan.org/tex-archive/graphics/pstricks/contrib/pst-pdf/scripts/

   this list that the vtex compiler cannot be used within lyx, using the
   converters (any compilation error crashes lyx).
 



 Why not? There is no difference in running pdflatex or vlatex. Create 
also a format pdfV.


I don't know, but it's like that: if you define a converter using 
vlatex, then, any error in
the document crashes lyx (I post this in the list some years ago). I 
solved that problem differently.


PhC

Re: Strange...

[Philippe Charpentier]

   OK. Then, as this can occur for many packages names, a simple solution
   would be that lyx compile tmp_filename.tex instead of filename.tex,
   because the error message of the compiler is not very explicit.
 


LyX should give a warning if kpsewhich filename.tex  has a result.


This is also a very god idea


   lyx team have the intention to implement the compilation of a file
   which uses this package? That is, if a file using pst-pdf (in the
   preamble) is compiled using Vsualize->pdflatex then then the
   compilation would be done with latex (+ bibtex, makeindex if needed),
   dvips(...), ps2pdf(...) and pdflatex. I recall, as I already told in
 



> you can do it by yourself, create a new format pdf4, for which you 
run the skript ps4pdf 
> 
http://www.ctan.org/tex-archive/graphics/pstricks/contrib/pst-pdf/scripts/


I know, but this is not the same thing.



   this list that the vtex compiler cannot be used within lyx, using the
   converters (any compilation error crashes lyx).
 



> Why not? There is no difference in running pdflatex or vlatex. Create 
also a format pdfV.


I don't know, but it's like that: if you define a converter using 
vlatex, then, any error in
the document crashes lyx (I post this in the list some years ago). I 
solved that problem differently.


PhC

Re: gtk frontend does not compile

[Philippe Charpentier]

On Sat, 28 Jan 2006 11:24:15 +
John Spray [EMAIL PROTECTED] wrote:

 
 Fixed:
 
 clear_items() appears to be a very recent addition to the API.  I've
 reverted it to the to-be-deprecated clear() in CVS.

I should see about setting up a build environment with some older libs
(or possibly fix the gtkmm docs so that they tell me these things...)
 

Hi,
with the latest changes I cannot any more compile the gtk frontend.
It would be be very nice if the compilation of the gtk frontend was
possible with gtkmm24-2.4.x which is the latest I can install on my fc3
box. This is not the case right now: for example `PixbufRotation' is
not a member of `Gdk' in all 2.4.x versions.

PhC

Re: gtk frontend does not compile

[Philippe Charpentier]

On Sat, 28 Jan 2006 11:24:15 +
John Spray <[EMAIL PROTECTED]> wrote:

> 
> Fixed:
> 
> clear_items() appears to be a very recent addition to the API.  I've
> reverted it to the to-be-deprecated clear() in CVS.
>
>I should see about setting up a build environment with some older libs
>(or possibly fix the gtkmm docs so that they tell me these things...)
> 

Hi,
with the latest changes I cannot any more compile the gtk frontend.
It would be be very nice if the compilation of the gtk frontend was
possible with gtkmm24-2.4.x which is the latest I can install on my fc3
box. This is not the case right now: for example `PixbufRotation' is
not a member of `Gdk' in all 2.4.x versions.

PhC

Re: preview-latex

[Philippe Charpentier]

 AttributeError: getenv
 Traceback (innermost last):
   File /usr/local/lyx135/share/lyx/scripts/lyxpreview2ppm.py, line 396, in ?
 main(sys.argv)
   File /usr/local/lyx135/share/lyx/scripts/lyxpreview2ppm.py, line 337, in main
 path = string.split(os.getenv(PATH), os.pathsep)
 AttributeError: getenv

 Goto to this line and replace
os.getenv(PATH)
by
os.environ['HOME']
 Does it works now?
No, the error is then simply: 

Unable to add font path.
Unable to find executable from 'pplatex latex2e latex'
Ph. Charpentier

Re: preview-latex

[Philippe Charpentier]

>> AttributeError: getenv
>> Traceback (innermost last):
>>   File "/usr/local/lyx135/share/lyx/scripts/lyxpreview2ppm.py", line 396, in ?
>> main(sys.argv)
>>   File "/usr/local/lyx135/share/lyx/scripts/lyxpreview2ppm.py", line 337, in main
>> path = string.split(os.getenv("PATH"), os.pathsep)
>> AttributeError: getenv

 Goto to this line and replace
os.getenv("PATH")
by
os.environ['HOME']
 Does it works now?
No, the error is then simply: 

Unable to add font path.
Unable to find executable from 'pplatex latex2e latex'
Ph. Charpentier

Feature request

[Philippe Charpentier]

Because I frequently use at least three different document class which
are verry different, I would be really interessed in the possibility to
automaticly use different ui files when I use different document class.
Precisely it would be nice if it was possible to attach a ui file to a
document class (and, of course, the specific ui file would be
automaticly applied when a change of document class is applied to a
document - at least of course for a new document - without changing the
default ui file). Do you think that this is possible?
-- 
_

Philippe Charpentier

[EMAIL PROTECTED]
[EMAIL PROTECTED]

Feature request

[Philippe Charpentier]

Because I frequently use at least three different document class which
are verry different, I would be really interessed in the possibility to
automaticly use different ui files when I use different document class.
Precisely it would be nice if it was possible to attach a ui file to a
document class (and, of course, the specific ui file would be
automaticly applied when a change of document class is applied to a
document - at least of course for a new document - without changing the
default ui file). Do you think that this is possible?
-- 
_

Philippe Charpentier

[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Lyx-1.2 and preamble

[Philippe Charpentier]

Le mar 11/06/2002 à 16:41, Jean-Marc Lasgouttes a écrit :
 
 This is solved in ams layouts by defining some of the stuff in the
 main preamble:
 
 Preamble
   \theoremstyle{plain}
   \newtheorem{thm}{Theorem}[section]
   \numberwithin{equation}{section} %% Comment out for sequentially-numbered
   \numberwithin{figure}{section} %% Comment out for sequentially-numbered
 EndPreamble
 
 THis is of course not optimal, but it _works_.
 
The simplest example of such problem I have is of course with theorem
environments. I want to have the possibility to choose differents
counters for theorems and propositions, and, in that case I want that
the corollaries are numbred with only one number (and the same thing
with the lemmas which can be lemmas of propositions but also lemmas of
corollaries). Then for the case of proposition, corollaries and lemmas,
I wrote three layouts which contains respectively the following
preambles:

For propositions:
  Preamble
\theoremstyle{plain}
\newtheorem{spprop}{Proposition}[section]
  EndPreamble
For corollaries of such propositions:
 Preamble
\theoremstyle{plain}
\newcounter{ConSP}[spprop]   
\newtheorem{ccorsp}[ConSP]{Corollaire}
  EndPreamble
For lemmas of such corollaries:
 Preamble
\theoremstyle{plain}
\newcounter{LonConSP}[ConSP]
\newtheorem{spllemc}[LonConSP]{Lemme}
  EndPreamble

I think it is the simplest way, but if the second Preamble is write in
the latex preamble before the first one I get an error (of course the
second layout cannot be used before the first one!)
If I understand well the situation, the only solution for me now is to
define, à priori, the counters SP and ConSP in the basic layout (even if
they are not used!).
-- 
_

Philippe Charpentier

[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Lyx-1.2 and preamble

[Philippe Charpentier]

Le mar 11/06/2002 à 16:41, Jean-Marc Lasgouttes a écrit :
 
> This is solved in ams layouts by defining some of the stuff in the
> main preamble:
> 
> Preamble
>   \theoremstyle{plain}
>   \newtheorem{thm}{Theorem}[section]
>   \numberwithin{equation}{section} %% Comment out for sequentially-numbered
>   \numberwithin{figure}{section} %% Comment out for sequentially-numbered
> EndPreamble
> 
> THis is of course not optimal, but it _works_.
> 
The simplest example of such problem I have is of course with theorem
environments. I want to have the possibility to choose differents
counters for theorems and propositions, and, in that case I want that
the corollaries are numbred with only one number (and the same thing
with the lemmas which can be lemmas of propositions but also lemmas of
corollaries). Then for the case of proposition, corollaries and lemmas,
I wrote three layouts which contains respectively the following
preambles:

For propositions:
  Preamble
\theoremstyle{plain}
\newtheorem{spprop}{Proposition}[section]
  EndPreamble
For corollaries of such propositions:
 Preamble
\theoremstyle{plain}
\newcounter{ConSP}[spprop]   
\newtheorem{ccorsp}[ConSP]{Corollaire}
  EndPreamble
For lemmas of such corollaries:
 Preamble
\theoremstyle{plain}
\newcounter{LonConSP}[ConSP]
\newtheorem{spllemc}[LonConSP]{Lemme}
  EndPreamble

I think it is the simplest way, but if the second Preamble is write in
the latex preamble before the first one I get an error (of course the
second layout cannot be used before the first one!)
If I understand well the situation, the only solution for me now is to
define, à priori, the counters SP and ConSP in the basic layout (even if
they are not used!).
-- 
_

Philippe Charpentier

[EMAIL PROTECTED]
[EMAIL PROTECTED]

Lyx-1.2 and preamble

[Philippe Charpentier]

I recently test the new version 1.2 of LyX. The work done by the
developers is impresive. But I encountred the following problem.
I wrote some document class for LyX containing many layouts with
preambles. In the previous version of LyX those preambles where send to
the TeX file in the order they appear in the document. In this last
version they appear in the alphabetical order of the names of the
layouts. For me this gets a unsolvable (without important modifications)
TeX problem : in those layouts I have some counters which are not
defined indpendently: for example I have a counter B (defined in layout
(B)) which is defined on a counter A (defined in layout (A)), but the
name of the layout (A) comes, alphabetically, after the name of the
layout (B) (of course the layout (B) have no sense if the layout (A) is
not used before in the document, and it is not necessary to define a
priori the counter B if it is not used...): with lyx-1.1.6 all was OK,
but with lyx-1.2, I get of course a tex error (counter A is not defined)
when I use the layout (B) (even, of course, if layout (A) is used
before). This can only be solved by modifing my tex macros and my
layouts.
If this change is definitive, I will be obliged to do those
modifications in my macros.
Thanks you
-- 
_

Philippe Charpentier

[EMAIL PROTECTED]
[EMAIL PROTECTED]

Lyx-1.2 and preamble

[Philippe Charpentier]

I recently test the new version 1.2 of LyX. The work done by the
developers is impresive. But I encountred the following problem.
I wrote some document class for LyX containing many layouts with
preambles. In the previous version of LyX those preambles where send to
the TeX file in the order they appear in the document. In this last
version they appear in the alphabetical order of the names of the
layouts. For me this gets a unsolvable (without important modifications)
TeX problem : in those layouts I have some counters which are not
defined indpendently: for example I have a counter B (defined in layout
(B)) which is defined on a counter A (defined in layout (A)), but the
name of the layout (A) comes, alphabetically, after the name of the
layout (B) (of course the layout (B) have no sense if the layout (A) is
not used before in the document, and it is not necessary to define a
priori the counter B if it is not used...): with lyx-1.1.6 all was OK,
but with lyx-1.2, I get of course a tex error (counter A is not defined)
when I use the layout (B) (even, of course, if layout (A) is used
before). This can only be solved by modifing my tex macros and my
layouts.
If this change is definitive, I will be obliged to do those
modifications in my macros.
Thanks you
-- 
_

Philippe Charpentier

[EMAIL PROTECTED]
[EMAIL PROTECTED]

a small bug in lyx-1.2cvs

[Philippe Charpentier]

I found a small bug in the tree last versions of lyx-1.2cvs which where
in the Sylvan's ftp site. Maybee it's allready fixed...
In a new lyx file, you write the following math formula:
\underset{a}{\underbrace{a\cdots a}}
then you save the lyx file and edit it.
You can read the line:
\begin_inset Formula $\underset{a}{\underbrace{a\cdots a}}$
Then you reopen the lyx file (with lyx): the braces have disappeared. If
you save another time, close lyx, and reedit the lyx file, you have the
line:
\begin_inset Formula $\underset a\underbrace{a\cdots a}$
PhC

a small bug in lyx-1.2cvs

[Philippe Charpentier]

I found a small bug in the tree last versions of lyx-1.2cvs which where
in the Sylvan's ftp site. Maybee it's allready fixed...
In a new lyx file, you write the following math formula:
\underset{a}{\underbrace{a\cdots a}}
then you save the lyx file and edit it.
You can read the line:
\begin_inset Formula $\underset{a}{\underbrace{a\cdots a}}$
Then you reopen the lyx file (with lyx): the braces have disappeared. If
you save another time, close lyx, and reedit the lyx file, you have the
line:
\begin_inset Formula $\underset a\underbrace{a\cdots a}$
PhC

Re: LyX and RedHat 7.x

[Philippe Charpentier]

Dekel Tsur wrote:

The problem is probably due to the compiler in Redhat

Get the latest updates for the compiler.

I have gcc-2.96-81. The last RedHat update is gcc-2.96-85; do you think I have a chance
to see any difference with it?

 You can also try to compile without
optimizations (do setenv CPPFLAGS '' and  setenv CFLAGS '' before running
configure).

I tried it without any success.
Philippe Charpentier

Re: LyX and RedHat 7.x

[Philippe Charpentier]

Dekel Tsur wrote:

>The problem is probably due to the compiler in Redhat
>
>Get the latest updates for the compiler.
>
I have gcc-2.96-81. The last RedHat update is gcc-2.96-85; do you think I have a chance
to see any difference with it?

> You can also try to compile without
>optimizations (do setenv CPPFLAGS '' and  setenv CFLAGS '' before running
>configure).
>
I tried it without any success.
Philippe Charpentier

Re: A major bug with tabular (lyx-1.1.6fix1)

[Philippe Charpentier]

Juergen Vigna a crit :

 On 07-Feb-2001 Jean-Marc Lasgouttes wrote:

  Philippe Hi, here is a major bug with new tabular in
  Philippe lyx-1.1.6fix1 : you do a big tabular of 50 rows and 50
  Philippe lines; in the first cell of that tabular you insert an other
  Philippe tabular of 50 rows and 50 lines. Then you try to write a

 What do you mean be rows and lines, probably rows and columns #:O)

 
  More details: you already get a good memory consumption with just one
  50x50 tabular. Once it is inserted, resident memory goes to 26M.
  Insert one character in one cell, and you go to 32M; subsequent
  characters in the same cell do not see to change a lot. However,
  inserting a character in a second cell brings you to 42M!

 Just one word: Undo!

 That's the problem. The undo mechanism right now is only able to work
 in the outermost paragraph so if you change something inside a tabular
 inset the outermost paragraph has to be duplicated for Undo.

 Unless this scheme is not changed we'll have to stay with that or disable
 Undo inside the tabular insets.

   Jrgen

 --
 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

 Dr. Jrgen VignaE-Mail:  [EMAIL PROTECTED]
 Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
 I-39100 Bozen   Web: http://www.sad.it/~jug

 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

 The better part of valor is discretion.
 -- William Shakespeare, "Henry IV"

OK. But the concrete implication of this situation is that longtabular can't
be really used with LyX!
For example, I tried to type a quite small document containing a longtabular
related to results of some
examens and it was completely impossible with LyX: I had been obliged to
reboot my computer.
Ph. C.

Re: A major bug with tabular (lyx-1.1.6fix1)

[Philippe Charpentier]

Juergen Vigna a écrit :

> On 07-Feb-2001 Jean-Marc Lasgouttes wrote:
>
> > Philippe> Hi, here is a major bug with new tabular in
> > Philippe> lyx-1.1.6fix1 : you do a big tabular of 50 rows and 50
> > Philippe> lines; in the first cell of that tabular you insert an other
> > Philippe> tabular of 50 rows and 50 lines. Then you try to write a
>
> What do you mean be rows and lines, probably rows and columns #:O)
>
> >
> > More details: you already get a good memory consumption with just one
> > 50x50 tabular. Once it is inserted, resident memory goes to 26M.
> > Insert one character in one cell, and you go to 32M; subsequent
> > characters in the same cell do not see to change a lot. However,
> > inserting a character in a second cell brings you to 42M!
>
> Just one word: Undo!
>
> That's the problem. The undo mechanism right now is only able to work
> in the outermost paragraph so if you change something inside a tabular
> inset the outermost paragraph has to be duplicated for Undo.
>
> Unless this scheme is not changed we'll have to stay with that or disable
> Undo inside the tabular insets.
>
>   Jürgen
>
> --
> -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
>
> Dr. Jürgen VignaE-Mail:  [EMAIL PROTECTED]
> Italienallee 13/N   Tel/Fax: +39-0471-450260 / +39-0471-450253
> I-39100 Bozen   Web: http://www.sad.it/~jug
>
> -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
>
> The better part of valor is discretion.
> -- William Shakespeare, "Henry IV"

OK. But the concrete implication of this situation is that longtabular can't
be really used with LyX!
For example, I tried to type a quite small document containing a longtabular
related to results of some
examens and it was completely impossible with LyX: I had been obliged to
reboot my computer.
Ph. C.

A major bug with tabular (lyx-1.1.6fix1)

[Philippe Charpentier]

Hi,
here is a major bug with new tabular in lyx-1.1.6fix1 : you do a big
tabular of 50 rows and 50 lines; in the first cell
of that tabular you insert an other tabular of 50 rows and 50 lines.
Then you try to write a letter on the first cells
of the second tabular. At the same time you look at the memory used by
LyX. When you arrive to the 10th cell
the memory used by LyX will be around to 100Mo! Each time you write a
new cell the memory used by LyX
increase verry verry fast untill... you have no more memory!
Philippe Charpentier

A major bug with tabular (lyx-1.1.6fix1)

[Philippe Charpentier]

Hi,
here is a major bug with new tabular in lyx-1.1.6fix1 : you do a big
tabular of 50 rows and 50 lines; in the first cell
of that tabular you insert an other tabular of 50 rows and 50 lines.
Then you try to write a letter on the first cells
of the second tabular. At the same time you look at the memory used by
LyX. When you arrive to the 10th cell
the memory used by LyX will be around to 100Mo! Each time you write a
new cell the memory used by LyX
increase verry verry fast untill... you have no more memory!
Philippe Charpentier