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

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

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

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

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

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

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

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

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

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)

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?

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

Re: Problem with PassThru?

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

Re: Problem with PassThru?

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 Mai

Re: Problem with PassThru?

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 >

Problem with PassThru?

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

Problem with PassThru?

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

Re: Re: [patch] default view format

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

Re: Re: [patch] default view format

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

An other bug in lyx2lyx

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

An other bug in lyx2lyx

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

Re: Index entries in lyx-1.6

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

Re: Index entries in lyx-1.6

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

Index entries in lyx-1.6

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

Index entries in lyx-1.6

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

UTF-8 bug in modules...

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

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

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

UTF-8 bug in modules...

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

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

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

Environments in rev. 27221

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

Environments in rev. 27221

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

Layout combobox and UTF-8 bug

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

Layout combobox and UTF-8 bug

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

Environments in lyx-1.6

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

Re: Environments in lyx-1.6

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}

Re: Environments in lyx-1.6

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

Re: Environments in lyx-1.6

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

Environments in lyx-1.6

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

Re: Environments in lyx-1.6

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

Re: Environments in lyx-1.6

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

Re: Environments in lyx-1.6

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

Re: lyx-1.6.0svn and layouts names

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

Re: lyx-1.6.0svn and layouts names

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

lyx-1.6.0svn and layouts names

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

Re: lyx-1.6.0svn and layouts names

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.

Re: lyx-1.6.0svn and layouts names

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

lyx-1.6.0svn and layouts names

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

Re: lyx-1.6.0svn and layouts names

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

Re: lyx-1.6.0svn and layouts names

rgheck a écrit : > Philippe Charpentier wrote: >> For example, the following CharStyle >> >> CharStyle Semi-Bold >> LatexType Command >> LatexName textsb >> Font >> Family Roman >

Re: UTF-8 and layouts - bugs

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

Re: UTF-8 and layouts - bugs

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

Re: UTF-8 and layouts - bugs

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

Re: UTF-8 and layouts - bugs

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

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

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

Re: UTF-8 and layouts - bugs

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

Re: UTF-8 and layouts - bugs

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

Re: UTF-8 and layouts - bugs

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

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

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

Re: [Patch] allow unicode in layout style name

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

Re: [Patch] allow unicode in layout style name

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

UTF-8 and layouts - bugs

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

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

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>

Re: [Patch] allow unicode in layout style name

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 docume

Re: [Patch] allow unicode in layout style name

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

UTF-8 and layouts - bugs

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

Re: Upgrade from 1.4 to 1.5

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

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

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

> 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

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

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

(and not all the layout appearing in the ui file)? Philippe Charpentier

amsart-plain.layout and a question

cument (and not all the layout appearing in the ui file)? Philippe Charpentier

Re: qt or lyx or FC5 bug ?

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

Re: qt or lyx or FC5 bug ?

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 &quo

Re: qt or lyx or FC5 bug ?

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

Re: qt or lyx or FC5 bug ?

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

qt or lyx or FC5 bug ?

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 ?

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

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

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

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

Re: Vertical spaces lyx-1.3 lyx-1.4

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

Vertical spaces lyx-1.3 lyx-1.4

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

Re: Vertical spaces lyx-1.3 lyx-1.4

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

Re: Strange...

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

Re: Strange...

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

Re: gtk frontend does not compile

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

Re: gtk frontend does not compile

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

Re: preview-latex

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)

Re: preview-latex

>> 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"),

Feature request

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

Feature request

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

Re: Lyx-1.2 and preamble

(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

Re: Lyx-1.2 and preamble

atex 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!). -- _ Ph

Lyx-1.2 and preamble

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

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

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

a small bug in lyx-1.2cvs

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

Re: LyX and RedHat 7.x

CPPFLAGS '' and setenv CFLAGS '' before running configure). I tried it without any success. Philippe Charpentier

Re: LyX and RedHat 7.x

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

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

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

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>

A major bug with tabular (lyx-1.1.6fix1)

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)

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

  1   2   >