Re: Aspell failure w/pre1.3.6-16 install on windows

2005-06-24 Thread Jean-Pierre Chrétien
Angus Leeming <[EMAIL PROTECTED]> writes:

> 
> Jean-Pierre Chrétien wrote:
[...]
> > What am I doing wrong ?
> 
> The aspell library is compiled into lyx as a static lib. That's rather
> unfortunate, because it means that the configuration data that's
> compiled into lyx's aspell lib may or may not match the locations of
> data and dict on yours.
> 
> I'd expect (from memory) that you should have 
> C:\Aspell\dict
> C:\Aspell\data
> directories and that these should be populated.

Right here.

> 
> You could also use an environment variable ASPELL_CONF to point to a
> configuration file containing the equivalent output to
> $ aspell dump config
> That way, I believe that the static lib within LyX will also use this
> configuration file.
[...]
> Does this help any?

I ran in a dos console
>C:\Aspell\bin\aspell.exe dump config >C:\aspell-config
and set ASPELL_CONF to conf C:\aspell-config without success.

Aspell *does* work for Stephen Harris (from a private post), I'm checking
with him and I'll keep devel-list posted.

BTW, on Solaris  I can control what are the files opened when I call the
spellchecker with
->truss -f -t open lyx

Any similar tool on Windows ?

-- 
Jean-Pierre










Re: Aspell failure w/pre1.3.6-16 install on windows

2005-06-27 Thread Jean-Pierre Chrétien
Stephen Harris <[EMAIL PROTECTED]> writes:

> 
> Re: Aspell failure w/pre1.3.6-16 install on windows
> Paul A. Rubin
> Fri, 24 Jun 2005 08:39:07 -0700
> 
> Jean-Pierre Chrétien wrote
> 
> "I ran in a dos console
> >C:\Aspell\bin\aspell.exe dump config >C:\aspell-config
> and set ASPELL_CONF to conf C:\aspell-config without success.
> 
> Aspell *does* work for Stephen Harris (from a private post), I'm checking
> with him and I'll keep devel-list posted."
> 
> Paul responded:
> 
> "Works for me with 1.3.6pre17. What happens if you open a DOS console,
> cd to C:\Aspell and do the following:
> 
> >bin\aspell -c readme
> 
> (assuming that the Aspell readme file is in C:\Aspell)?
> Does it start start checking, or does it offer up an error message? "
> 

Did not try this, instead I followed Stephen's suggestion to check other
installs of aspell or lyx,  so I came back to an entirely\
fresh lyx install on XP:
 - check other aspell installations : none
 - check other lyx installatons: yes (Ruurds 1.3.5 in C:\Proggies), deleted
 - check personal lyx dirs: yes, deleted
 - uninstal/reinstall lyx-1.3.6-17: spellchecker works as expected :-)

A similar test on 2000 gave the same result: I'm not quite sure about
the need to delete Ruurd's 1.3.5 port, but clearly uninstall is needed
(I guess because the original 1.3.6 installs were done without Aspell
installed).

As install over previous versions seemed to work, I have been lazy :-( sorry,
but maybe a requirement to uninstall first would be welcome 
in the installer ? It takes a few seconds to perform.

Thnks for the suggestions.

Regards

-- 
Jean-Pierre





tex2lyx: round trip on a beamer presentation

2005-06-29 Thread Jean-Pierre Chrétien
Hello developers,

I use lyx for technical reports for several years (with great success
and pleasure, thanks to you), but currently I still use Xemacs/pdflatex
for beamer presentations.

Here a few remarks after a round trip when trying to turn a foo.tex
file written in beamer class into foo.lyx:
 one is about the optional arg to the \frame command
\frame[plain]{\titlepage} -> \frame{[}plain{]}{titlepage}
 The others all happen when closing a frame:
 \end{itemize}   \end{columns}} % end frame 
\end{columns}  ->  
} % end frame\end{itemize}

\column{0.45\textwidth}
\end{columns}  ->   \column{0.45\textwidth\end{columns}}}
}

In fact, the \column command (and the } closing the frame)
belong to the preceding environment in the lyx code, e.g. layout Itemize
remains open as no layout Standard appears before the ERT inset.
layout Itemize
[...]
\begin_inset ERT
status Collapsed

\layout Standard

\backslash 
end{columns}
\end_inset 

It seems located inside the ERT, where it has no effect I guess.

Sorry if this has been reported, is bugzilla appropriate for tex2lyx ?
I can downsize this to a minimal two-slide example if needed.

HTH

-- 
Jean-Pierre





Re: tex2lyx: round trip on a beamer presentation

2005-06-30 Thread Jean-Pierre Chrétien
Georg Baum <[EMAIL PROTECTED]> writes:

> 
> Jean-Pierre Chrétien wrote:
> 
> >  one is about the optional arg to the \frame command
> > \frame[plain]{\titlepage} -> \frame{[}plain{]}{titlepage}
> 
> You can fix this sort of errors easily yourself: Add
> 
> \frame[]{}> 
> to lib/reLyX/syntax.default (and then send a patch  ).

This works, but I get all frames in ERT, not exactly what expected.
In will test your patch on tex2lyx later.

[..]
> > I can downsize this to a minimal two-slide example if needed.
> 
> Please do this, since I don't understand what happens apart from the \frame
> bug.

Done on bugzilla, bug# 1910

With the short example, \author{...} is lost in the lyx preamble, I guess
it deserves a different bug report (sorry, I'm a freshman with bugzilla usage).

-- 
Jean-Pierre



Re: tex2lyx: round trip on a beamer presentation

2005-06-30 Thread Jean-Pierre Chrétien

> This works, but I get all frames in ERT, not exactly what expected.
> In will test your patch on tex2lyx later.

Works fine, thanks.

-- 
Jean-Pierre




Re: tex2lyx: round trip on a beamer presentation

2005-06-30 Thread Jean-Pierre Chrétien

> 
> Because I used the translate argument.

OK, I understood also that I could copy the patch
in a local syntax.personal file and call it
with tex2lyx -s syntax.personal foo.tex >foo.lyx

I know that the goal of tex2lyx is to produce error-free
lyx code, but would this local syntax file allow to tell
tex2lyx to translate e.g.
\frame[plain]{
by
\layout BeginPlainFrame
and
}\frame{
by 
layout BeginFrame

As this would be documentclass dependent, I guess not...

-- 
Jean-Pierre







Re: tex2lyx: round trip on a beamer presentation

2005-07-01 Thread Jean-Pierre Chrétien
G. Milde <[EMAIL PROTECTED]> writes:

> 
> On 30.06.05, Jean-Pierre Chrétien wrote:
> > Georg Baum  ...> writes:
> > 
> > > 
> > > Jean-Pierre Chrétien wrote:

> > This works, but I get all frames in ERT, not exactly what expected.
> 
> This is because beamer layout file doesnot have a Style with latexname
> "frame". 
> 
> Instead, it introduces the \lyxframe and \lyxframeend commands as an
> substitution for nesting stuff inside a frame.

Georg patch translates 
\frame{ ... } 
as 
\frame{...}
which is all right from the point of view of tex2lyx current goal.
 
My previous follow-up raised the question of directly translating in the
required layout by associating a latex construct to the corresponding
layout equivalent, and using a (possibly user written) syntax file
to define these equivalences.

Postfiltering the lyx file is of course possible, replacing
current ERTs with the layout commands in LyX code, so this
is a really aesthetic question from the point of view of tex2lyx.

-- 
Jean-Pierre









Language change within Flex inset exports wrong babel construct

2011-06-02 Thread Jean-Pierre Chrétien

Hello,

I checked the pdf export of the French version of the Custolization manual, and 
I discovered a number of extra spaces after constructs where a word remained in 
English inside a Flex inset, e.g.:


\begin_inset Flex Code
status collapsed

\begin_layout Plain Layout

\lang english
word
\end_layout

\end_inset

This exports as

\code{\selectlanguage{english}%
word\selectlanguage{french}
}

If I turn the word in English outside the Flex inset, the exported code is

 \foreignlanguage{english}{\code{word}}

and the extra space disappears.

So a correct export in the first case would be

\code{\foreignlanguage{english}{word}}

Attached is a simple example.

I checked with other Flex insets (emphasize and such), same behaviour.

Does this deserve a ticket ?

Note that if I reverse languages (main language English, foreign language 
French), I get also an extra space *before* the word, even with the corrected 
version, but the latter is anyway better than the former. This seems an issue 
with babel itself, so LyX should not try to correct it, but IMHO LyX must export 
the best latex construct, and \selectlanguage does not seem appropriate inside a 
sentence (does not work well on a single word outside a Flex inset).


--
Jean-Pierre


test_foreign_in_Flex.lyx
Description: application/lyx


Re: Language change within Flex inset exports wrong babel construct

2011-06-03 Thread Jean-Pierre Chrétien
Enrico Forestieri  lyx.org> writes:

> 
> See attached patch.
> 

Tested with trunk, as it belongs to it, and it solves the problem both in
Customization.lyx and in my simple test example.

I created a ticket
http://www.lyx.org/trac/ticket/7607

-- 
Jean-Pierre




Re: Language change within Flex inset exports wrong babel construct

2011-06-09 Thread Jean-Pierre Chrétien
Guenter Milde  users.berlios.de> writes:

> 
> > This exports as
> 
> > \code{\selectlanguage{english}%
> > word\selectlanguage{french}
> > }
> 
> There correct LaTeX code is:
> 
>  \code{\selectlanguage{english}%
> - word\selectlanguage{french}
> + word\selectlanguage{french}%
>  }
> 
> The comment sign (%) suppresses the spurious whitespace introduced by
> the line break.

Sure, output_export.cpp seems wrong there. Shouln't all "}\n" strings
be replaced by "}%\n" strings there ?

Currently, with branch, with your patch applied (by svn up), I still get the
spurious space that you mention, but the previous big one disppeared.

-- 
Jean-Pierre




Re: Language change within Flex inset exports wrong babel construct

2011-06-09 Thread Jean-Pierre Chrétien
Guenter Milde  users.berlios.de> writes:

> > Sure, output_export.cpp seems wrong there. Shouln't all "}\n" strings
> > be replaced by "}%\n" strings there ?
> 
> There are many examples where the line-break does not need to be
> escaped (end of environments, say).
> (It took me some time to find out it's called output_latex.cpp.)

Oops, sorry for the misleading name :-(

> 
> > Currently, with branch, with your patch applied (by svn up), I still get the
> > spurious space that you mention, but the previous big one disppeared.
> 
> Looking at the LaTeX source of an example seems the easiest way to find
> the culprit.
> 
> (Did you also apply the fix to "languages"?)

Sure, as it is in in branch and trunk, svn up downloads it in my local copy.

I added an exemple in my test file in bugzilla to show the spaces
added in various situations:
http://www.lyx.org/trac/attachment/ticket/7607/test_foreign_in_Flex1.lyx

You may open it both with lyx-2.0.0 and the current svn lyx-2.0.1 version to see
what I mean.

So to come back to the previous thread, if Enrico's patch is not applied, which
one of the "}\n" strings in output_latex.cpp should be modified ?

-- 
Jean-Pierre





Re: Language change within Flex inset exports wrong babel construct

2011-06-10 Thread Jean-Pierre Chrétien
Jürgen Spitzmüller  lyx.org> writes:

> 
> Jean-Pierre Chrétien wrote:
> > So to come back to the previous thread, if Enrico's patch is not applied,
> > which one of the "}\n" strings in output_latex.cpp should be modified ?
> 
> See attachment.
> 
> The new bool is introduced because pending_newline is used multiple times.

Works fine, both on my test file and on the French version of the Customization
manual.

Thanks a lot, I won't have to search and correct all the ocurrences of English
words in Flex:code I left there.

Once this patch is committed, I will close ticket #7607.

-- 
Jean-Pierre




epstopdf fails with 2.0.1svn

2011-06-10 Thread Jean-Pierre Chrétien
Hello,

While viewing the PDF of the UserGuide in lyx-2.0.1svn, I get this kind of
errors for every .eps file to be converted to pdf:


Systemcall.cpp(238): Systemcall: 'epstopdf --outfile="32_usr_local_share_lyx-\
2_0_1svn_doc_clipart_mobius.pdf" "32_usr_local_share_lyx-\
2_0_1svn_doc_clipart_mobius.eps"' did not start!
Systemcall.cpp(239): error The process failed to start.\
Either the invoked program is missing, or you may have\
insufficient permissions to invoke the program.
Error: Cannot convert file


This did not heppen with 2.0.0.
Setting the absolute path in the Preferences does not work either.

Debian lenny, lyx-2.0.1svn at rev. 38988, TeXLive 2009/2010

-- 
Jean-Pierre




Re: epstopdf fails with 2.0.1svn

2011-06-10 Thread Jean-Pierre Chrétien
Kornel  lyx.org> writes:

> 
> I also had this. Cured after changing the converter
>   EPS->PDF(ps2pdf)
> from "epstopdf --outfile=$$o $$i" to "ps2pdf $$o $$i".
> 

I replaced in my lyxrc.example 
epstopdf--outfile=$$o $$i
by the absolute path
/ext/local/texlive/2010/bin/i386-linux/epstopdf --outfile=$$o $$i
with no success.

However with:
perl /ext/local/texlive/2010/bin/i386-linux/epstopdf --outfile=$$o $$i
the errors disppears.

Looks like an acess to perl problem then.

But now, coming back to any of the two other converters, the errors do not
appear anymore

-- 
Jean-Pierre




Re: epstopdf fails with 2.0.1svn

2011-06-12 Thread Jean-Pierre Chrétien
Julien Rioux  physics.utoronto.ca> writes:


> >
> 
> Could it be related to the missing a #! line in the epstopdf script?
> 

I don't think so, eval is a shell command there, and the line was incorrect,
a lot of scripts in the binary directory of the TexLive distribution
would be wrong...

But this rises a question: which shell does LyX open to run commands in the
converter section ?

Btw, I've removed ~/.lyx-2.0.1svn and the errors are back. I will perform
further tests with the debugger later.

-- 
Jean-Pierre






Re: epstopdf fails with 2.0.1svn

2011-06-13 Thread Jean-Pierre Chrétien
Richard Heck  comcast.net> writes:

> >
> Untested patch attached. But I think something like this is what needs 
> doing. Anyone who wishes should feel free to play with it and commit it 
> if it seems to work.

Does not work here (Qt 4.4.3).
I'm not fluent enough in C++ to try to improve it, sorry.

-- 
Jean-Pierre




Re: epstopdf fails with 2.0.1svn

2011-06-13 Thread Jean-Pierre Chrétien
Richard Heck  comcast.net> writes:


> >
> Untested patch attached. But I think something like this is what needs 
> doing. Anyone who wishes should feel free to play with it and commit it 
> if it seems to work.

As the bug appears in 2.0.1 due to changeset 38746, you might revert this one
and solve the problem in trunk (where the problem exists as well).
You might backport the TEXINPUTS stuff, once solved in trunk, later for 2.0.2, I
guess we can't remain in string freeze too long.

-- 
Jean-Pierre





Re: epstopdf fails with 2.0.1svn

2011-06-13 Thread Jean-Pierre Chrétien
Enrico Forestieri  lyx.org> writes:

> This seems to be a stupid Qt bug, so let's try without relying on Qt.
> Does the attached patch work for you?
> 

I can now compile the UserGuide flawlessly.

-- 
Jean-Pierre





Re: epstopdf fails with 2.0.1svn

2011-06-14 Thread Jean-Pierre Chrétien
Stephan Witt  gmx.net> writes:

>
> That's why it's crucial to have a so-called "shebang" at start of a script.
> If it's missing the script gets executed by the login shell. For scripts
> installed and used system-wide this is not good.
> 
> I have the #! line at start of all of my own scripts.

Sure, you can do this as you know where the binaries are.
I did the same for years for a system-wide installation
that I had full control on.

AFAIR, the first line in epstopdf (and in all the perl scripts in the
latex distribution binaries directory) tries to avoid errors when the perl
binary is not in the standard place (/usr/bin/perl) but e.g. in the local
directories (/usr/local/bin/perl).

The shell command in the first line has a syntax which sould be interpreted
 correctly by any flavour of the shell spawned to execute the calling command.

-- 
Jean-Pierre




Recursive repaint detected

2011-06-14 Thread Jean-Pierre Chrétien

Hello,

I have quite often a crash with lyx-2.0.0 and this kind of errors:

QPaintEngine::setSystemClip: Should not be changed while engine is active
QPaintEngine::setSystemClip: Should not be changed while engine is active
QWidgetPrivate::beginSharedPainter: Painter is already active
QWidget::repaint: Recursive repaint detected
QPainter::begin: Widget painting can only begin as a result of a paintEvent
QWidgetPrivate::endSharedPainter: Attempting to end a null painter
QPaintEngine::setSystemClip: Should not be changed while engine is active
QPaintEngine::setSystemClip: Should not be changed while engine is active
QWidgetPrivate::beginSharedPainter: Painter is already active
QWidget::repaint: Recursive repaint detected
QPainter::begin: Widget painting can only begin as a result of a paintEvent
QWidgetPrivate::endSharedPainter: Attempting to end a null painter

Am I alone to get this ?
I do not have a debuggable binary, but I can do it if needed.

--
Jean-Pierre



Re: Recursive repaint detected

2011-06-14 Thread Jean-Pierre Chrétien

Vincent van Ravesteijn a écrit :

On 14-6-2011 9:43, Jean-Pierre Chrétien wrote:

Hello,

I have quite often a crash with lyx-2.0.0 and this kind of errors:

QPaintEngine::setSystemClip: Should not be changed while engine is active
QPaintEngine::setSystemClip: Should not be changed while engine is active
QWidgetPrivate::beginSharedPainter: Painter is already active
QWidget::repaint: Recursive repaint detected

[...]




Which Platform ? Which QT-Version ?


Debian Lenny, and from the configuration log:

  Host type:i686-pc-linux-gnu
  Special build flags:  build=development warnings assertions
stdlib-debug concept-checks use-aspell
  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:   -Wextra -Wall   -g -O
  C++ Compiler: g++ (4.3.2)
  C++ Compiler LyX flags:
  C++ Compiler flags:   -Wextra -Wall   -g -O
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.4.3
  Packaging:posix

I'm thinking to go to squeeze, if I am too late in the Qt development.
Don't want to waste your time with problems coming from oldstable Debian 
version.

Anyway I get an emergency file, LyX tells me that I did not recover correctly, 
but apparently all is right and I can restart from it - and I make frequent saves.


This happens often when I open two LyX windows with several files in each to 
review the docs (typically, the French file, the differences between English 
files in 1.6.10 and 2.0.0, and the 2.0.0 English file to check when the 
differences are hard to read).


--
Jean-Pierre




Re: epstopdf fails with 2.0.1svn

2011-06-14 Thread Jean-Pierre Chrétien
Kornel  lyx.org> writes:

> But it is. The script starts here with
>   eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$  "}' && eval 
> 'exec perl
-S $0 $argv:q'
> if 0;
> 
> This is not a problem, if started through the OS, say
>   #epstopdf --hep
> but started witch csh directly the output is:
>   #csh /usr/local/texlive/2009/bin/x86_64-linux/epstopdf --help
>   if: Empty if.
>   Exit 1
> Starting with
>   #sh /usr/local/texlive/2009/bin/x86_64-linux/epstopdf --help
> it is OK.

You're right, seems that csh and tcsh cough on the 
eval (exit $?0)
part of the line.

However
{t}csh -c /usr/local/texlive/2009/bin/x86_64-linux/epstopdf --help
works fine.

-- 
Jean-Pierre





Duplicate Dissolve Inset in context menu

2011-06-23 Thread Jean-Pierre Chrétien

Hello,

With LyX-2.0.1svn, if I open the context menu on a phantom (e.g.),
the  Dissolve Inset item appears twice. This triggers a shortcut conflict...

--
Jean-Pierre


Re: Duplicate Dissolve Inset in context menu

2011-06-23 Thread Jean-Pierre Chrétien
Kornel  lyx.org> writes:


> I would remove it from InsetPhantom context menu in stdcontext.inc:194-195.
> Since the phantom inset is also collapsable, this item appears also in
InsetCollapsable context menu.

I'm afraid this breaks the string freeze, unless suppressing a message (which is
anyway translated because the same string appears in another place) is allowed.

-- 
Jean-Pierre





Re: Duplicate Dissolve Inset in context menu

2011-06-23 Thread Jean-Pierre Chrétien

Le 23/06/2011 11:34, Jean-Pierre Chrétien a écrit :

Hello,

With LyX-2.0.1svn, if I open the context menu on a phantom (e.g.),
the Dissolve Inset item appears twice. This triggers a shortcut conflict...


Here is patch.

--
Jean-Pierre

--- lib/ui/stdcontext.inc.orig	2011-06-23 17:11:29.0 +0200
+++ lib/ui/stdcontext.inc	2011-06-23 22:40:21.0 +0200
@@ -192,7 +192,6 @@
 		Item "Horizontal Phantom|H" "inset-modify phantom Phantom HPhantom"
 		Item "Vertical Phantom|V" "inset-modify phantom Phantom VPhantom"
 		Separator
-		Item "Dissolve Inset|D" "inset-dissolve"
 	End
 
 #


Informative diff between po files versions

2011-06-24 Thread Jean-Pierre Chrétien

Hello,

I wanted to find what were the recent changes I submitted to a po file.

Alas, the diff is not informative because the true changes are masked by
a lot of noise (modified comment lines, identical message lines rewritten 
differently, etc.).


Is there a tool which makes a real diff by filtering this noise ?

--
Jean-Pierre


Re: Informative diff between po files versions

2011-06-25 Thread Jean-Pierre Chrétien
Kornel  lyx.org> writes:

> > 
> > Is there a tool which makes a real diff by filtering this noise ?
> 
> I have a perl script using for this case, maybe you want to try it?

I was about to hack pocheck.pl to do it, but if you have a script, yes,
I'll try it.

Received it by separate mail, works fine, thanks a lot.

What about adding it in trac, together with pocheck.pl ?

-- 
Jean-Pierre





Re: Fwd: Additional manual

2011-07-19 Thread Jean-Pierre Chrétien

Le 17/07/2011 12:02, Pavel Sanda a écrit :

Uwe Stöhr wrote:

section 7.2.1: sentence

"Before you begin to use the version control features in LyX, you should
be
familiar with RCS/CVS/SVN usage before start using it under LyX."


Indeed. I removed this now.


the wording maybe wrong in terms of style but this information should be there.
VCS support is not robust at all, so the moment something goes wrong user
must be capable to fix it by himself without help of lyx. without being familiar
of RCS/CVS/SVN this is impossible and we should warn about this.


I wanted to stress the fact that the phrase was redundant, i.e, supressing 
"before start using it under LyX" was OK.


--
Jean-Pierre


Where are the shortcuts translated ?

2011-08-29 Thread Jean-Pierre Chrétien

Hello,

If I open Tools>Preferences>Editing>Shortcuts with LyX French localization, and 
search for 'break-paragraph' shortcuts, I find that 'Return' is translated as 
'Retour'.


This is bad because it is translated in the docs by 'Entrée', which is better 
IMHO. Where are these strings translated? I can't find anything in the po files, 
nor in the whole tree of the LyX sources.


--
Jean-Pierre


Re: Where are the shortcuts translated ?

2011-09-01 Thread Jean-Pierre Chrétien

Le 29/08/2011 23:00, Richard Heck a écrit :

On 08/29/2011 10:40 AM, Jean-Pierre Chrétien wrote:




This is bad because it is translated in the docs by 'Entrée', which is
better IMHO. Where are these strings translated? I can't find anything
in the po files, nor in the whole tree of the LyX sources.


Perhaps it is coming from Qt?


Ok, so I should see there to update this bad translation (I checked in
a computer retail shop, I did not find a single occurrence of 'Retour'
written on the return key).

Another option: can LyX code avoid delegation of shortcut translations to Qt?

--
Jean-Pierre




Re: LyX 2.0.1 Sources Available

2011-09-01 Thread Jean-Pierre Chrétien
Richard Heck  comcast.net> writes:

> http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz
>
http://frege.brown.edu/lyx/lyx-2.0.1.tar.xz.sighttp://frege.brown.edu/lyx/lyx-2.0.1.tar.xz.sig
> for testing. Please let me know if you have any trouble building it.

Builds flawlessly here (Debian Squeeze):

Configuration
  Host type:i686-pc-linux-gnu
  Special build flags:  build=release use-aspell
  C   Compiler: gcc 
  C   Compiler LyX flags:
  C   Compiler flags:-O2
  C++ Compiler: g++ (4.4.5)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags: 
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.6.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.0.1

The new verbosity of the makefiles is fine.

Compilation of French versions of UserGuide and EmbeddedObjects fail for a
similar reason: bad language change location in a sectioning heading. I guess
this can wait for 2.0.2, in the meanwhile a correct pdf can be committed in the
wiki.


> Also, a question. What do people think about releasing patch files? Does
> anyone use them? They are not that difficult to create, I would suppose,
> but they do take time.

I never use it, full distribution upload time is quite short compared to
compilation time.

-- 
Jean-Pierre




Language changes within index entries (was: LyX 2.0.1 Sources Available)

2011-09-05 Thread Jean-Pierre Chrétien

Le 01/09/2011 16:15, Uwe Stöhr a écrit :

Am 01.09.2011 10:55, schrieb Jean-Pierre Chrétien:


Compilation of French versions of UserGuide and EmbeddedObjects fail
for a
similar reason: bad language change location in a sectioning heading.


Where? For me all documentation files for all languages compile.


On Linux/TexLive I get the following errors.

In UserGuide:


Overfull \hbox (10.96574pt too wide) in paragraph at lines 103--104
[]\T1/lmr/bx/n/12 Environnements de Pa-ra-graphe, [][]18[][]--
 []

! Extra }, or forgotten \endgroup.
l.125 \subitem Details}
   \selectlanguage  {english} , \hyperpage{77}
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.


After investigation, this error is due to the fact that the word 'Flottants' is 
in French in the index inset within title of section 4.6.3. The exported latex 
construct


\subsection{More Information\index{Flottants@\selectlanguage{french}%
Flottants\foreignlanguage{english}{!Details@Details}\selectlanguage{english}
}}

creates the abovementioned error, as texindy creates line

   \subitem Details}\selectlanguage{english} , \hyperpage{79}

in UserGuide.ind.

This will be corrected when the section will be translated, but does this
deserve a ticket ? I wonder whether this is a LyX bug in the exported LaTeX
syntax or a index generator bug, which should not export 
'}\selectlanguage{english}'.


In EmbeddedObjects:


Chapter 6.
Runaway argument?
! Paragraph ended before \def was complete.

   \par
l.5632 ...anguage{french}{Flottants d'enrobage

I suspect you've forgotten a `}', causing me to apply this
control sequence to too much text. How can we recover?
My plan is to forget the whole thing and hope for the best.


and a set of errors triggered by the first one.

Change of language in a header title again, the offending code reads in LaTeX:

\section{Flottant d'enrobage\label{sec:Flottant-d'enrobage}
\index{Flottants!Flottants d'enrobage}\foreignlanguage{english}
{\index{Surrounded by text!Flottants d'enrobage@\foreignlanguage{french}
{Flottants d'enrobage

on one single line.

Again the error is due to an incompletely translated index entry, but this time 
the error occurs at the first pdflatex pass. The recursive \foreignlanguage 
construct in an index entry seems there incorrect in LaTeX (no more errors if I 
remove the external \foreignlanguage{english}{...} command).


I wonder why you do not see these errors ? In the first case, this may be due to 
the indexing engine, but in the second one, this seems a native TeX error.


--
Jean-Pierre




Discrimination of "New" in po files

2011-10-06 Thread Jean-Pierre Chrétien

Hello,

The string "New" appears in po files both for branches and indexes.
In French, the gender of the translation differs, so I need à [[...]] marker to 
be able to distinguish the two occurrences of the string.


Here is a patch implementing this (not tested).
Could you commit and regenerate the po files ?

TIA
Jean-Pierre
--- src/frontends/qt4/ui/BranchesUi.ui.orig	2011-10-06 09:39:56.0 +0200
+++ src/frontends/qt4/ui/BranchesUi.ui	2011-10-06 09:41:23.0 +0200
@@ -22,7 +22,7 @@

 
  
-  New:
+  New:[[branch]]
  
  
   newBranchLE
--- src/frontends/qt4/ui_IndicesUi.h.orig	2011-10-06 09:40:13.0 +0200
+++ src/frontends/qt4/ui_IndicesUi.h	2011-10-06 09:43:18.0 +0200
@@ -202,7 +202,7 @@
 multipleIndicesCB->setToolTip(lyx::qt_("Check if you need multiple indexes (e.g., an Index of Names)", 0));
 #endif // QT_NO_TOOLTIP
 multipleIndicesCB->setText(lyx::qt_(" multiple indexes", 0));
-newIndexLA->setText(lyx::qt_(":", 0));
+newIndexLA->setText(lyx::qt_(":[[index]]", 0));
 #ifndef QT_NO_TOOLTIP
 newIndexLE->setToolTip(lyx::qt_("Enter the name of the desired index (e.g. \"Index of Names\") and hit \"Add\"", 0));
 #endif // QT_NO_TOOLTIP


Re: Discrimination of "New" in po files

2011-10-07 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

>
> Here is a patch implementing this (not tested).
> Could you commit and regenerate the po files ?

I forgot to mention that the patch is for branch.

-- 
Jean-Pïerre



Re: LyX 2.0.2 Source Packages Ready Again

2011-11-27 Thread Jean-Pierre Chrétien
Richard Heck  comcast.net> writes:

> 
> 
> The LyX 2.0.2 source package has been updated a bit in response to
> earlier issues and is again available here:
> http://frege.brown.edu/lyx/
> Please let me know when binaries have been built. Let's try to do the
> official release by midweek.

Compiles fine here on Debian Squueze, just warnings in the shell window when
writing a short document:

Undo.cpp(296): There is no group open (creating one)

Jean-Pierre

Configuration
  Host type:i686-pc-linux-gnu
  Special build flags:  build=release use-aspell
  C   Compiler: gcc 
  C   Compiler LyX flags:
  C   Compiler flags:-O2
  C++ Compiler: g++ (4.4.5)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags: 
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.6.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.0.2





Re: LyX 2.0.2 Source Packages Ready Again

2011-11-28 Thread Jean-Pierre Chrétien
Jean-Marc Lasgouttes  lyx.org> writes:

> 
> It would be nice to have a short recipe to reproduce it.

Try this:
 - create a short file with plain text into it;
 - open lyx-2.0.2;
 - open a new file
 - perform Insert>File>Plain text... 
You should get it...

BTW, it was already present with 2.0.0. Should I file a ticket ?

-- 
Jean-Pierre







Memory leak ?

2012-01-21 Thread Jean-Pierre Chrétien

Hello,

A French user tells me privately that he finds a big memeory leak in LyX-2.0.2 
on an Archlinux LyX distribution (about 1.5Mo/mn).


On my Debian Squeeze and a simple document, I find about 1.7ko/mn.

Testing with the Userguide, I find around 19ko/mn with the following recipe:
 - open LyX-2.0.2 (English locale)
 - open the UserGuide
 - minimize the window
 - activate a crontab every minute with command ps -o rss= -p 

I find no leak with Lyx-1.6.10, and an much smaller one (identical for each) of 
0.28ko/mn with Lyx-2.0.2 and 2.0.1.


Is this a real leak, a misleading procedure, or a new behaviour with 2.0 (hidden 
tasks like auto-update or something) ?


Jean-Pierre

On ArchLinux:
% lyx --version
LyX 2.0.2 (2011-11-26)
Built on Dec 31 2011, 06:13:09
Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=release use-aspell use-enchant
use-hunspell
  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:-march=x86-64 -mtune=generic -O2
-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2
  C++ Compiler: g++ (4.6.2)
  C++ Compiler LyX flags:
  C++ Compiler flags:-march=x86-64 -mtune=generic -O2
-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2
-fpermissive
  Linker flags:
  Linker user flags:
-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu
  Qt 4 Frontend:
  Qt 4 version: 4.8.0
  Packaging:posix
  LyX binary dir:   /usr/bin
  LyX files dir:/usr/share/lyx

On Debian Squeeze:
$ lyx-2.0.2 --version
LyX 2.0.2 (2011-11-25)
Built on Nov 26 2011, 17:09:16
Configuration
  Host type:i686-pc-linux-gnu
  Special build flags:  build=release use-aspell
  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:-O2
  C++ Compiler: g++ (4.4.5)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.6.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.0.2





Re: Memory leak ?

2012-01-21 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

> I find no leak with Lyx-1.6.10, and an much smaller one (identical for each) 
> of  0.28ko/mn with Lyx-2.0.2 and 2.0.1.

I meant  Lyx-2.0.0 and 2.0.1, sorry.

-- 
Jean-Pierre





Re: String Freeze for 2.0.3

2012-02-01 Thread Jean-Pierre Chrétien

Le 31/01/2012 16:45, Richard Heck a écrit :


Translators, please prepare for 2.0.3. I am tentatively planning to
prepare the release on 16 February, so if you could have your new po
files in by 15 February, I'd appreciate it.


For testing against shortcuts conflicts, I compliled 2.0.3svn, I noticed these
warnings:

Lexer.cpp: In member function ‘void lyx::Lexer::Pimpl::verifyTable()’:
Lexer.cpp:197: warning: ‘’ may be used uninitialized in this function
lyxfind.cpp:571: warning: ‘size_t lyxfind_matching_brace(const 
std::string&, size_t)’ defined but not used


In addition, I get this:
/usr/bin/install: impossible d'évaluer « ./nl.gmo »: Aucun fichier ou dossier de 
ce type

(i.e. : impossible to evaluate « ./nl.gmo »: no such file or directory)

--
Jean-Pierre



Sweave manual pdf compilation fails

2012-02-01 Thread Jean-Pierre Chrétien

Hello,

I took a look to the new specific manual describing sweave with the latest 
2.0.3svn. The pdf export fails on an Rscript error:



Running: Rscript --verbose --no-save --no-restore 
"/usr/local/share/lyx-2.0.3svn/scripts/lyxsweave.R" 
"/tmp/lyx_tmpdir.T21839/lyx_tmpbuf2/""sweave.Rnw" 
"/tmp/lyx_tmpdir.T21839/lyx_tmpbuf2/""sweave.tex" ISO-8859-15 
"/usr/local/share/lyx-2.0.3svn/examples/"

running
  '/usr/lib/R/bin/R --slave --no-restore --no-save --no-restore 
--file=/usr/local/share/lyx-2.0.3svn/scripts/lyxsweave.R --args 
/tmp/lyx_tmpdir.T21839/lyx_tmpbuf2/sweave.Rnw 
/tmp/lyx_tmpdir.T21839/lyx_tmpbuf2/sweave.tex ISO-8859-15'


[1] FALSE
Writing to file /tmp/lyx_tmpdir.T21839/lyx_tmpbuf2/sweave.tex
Processing code chunks ...
 1 : term verbatim
 2 : echo (label=sweave-sty)
 3 : echo keep.source term verbatim (label=setup)
 4 : echo keep.source (label=sweave-manual)
 5 : echo keep.source term verbatim (label=print-integers)
 6 : echo term hide (label=hide-results)
 7 : echo term verbatim (label=calculator)
 8 : echo term verbatim (label=rnorm)
 9 : echo term verbatim (label=iris-summary)
10 : term tex (label=xtable-demo)
Loading required package: xtable
11 : echo term verbatim eps pdf (label=iris-pairs)

Erreur :  chunk 11 (label=iris-pairs)
Error in function (file = ifelse(onefile, "Rplots.pdf", "Rplot%03d.pdf"),  :
  impossible de démarrer le périphérique pdf
De plus : Messages d'avis :
1: In library(package, lib.loc = lib.loc, character.only = TRUE, logical.return 
= TRUE,  :

  there is no package called 'xtable'
2: In function (file = ifelse(onefile, "Rplots.pdf", "Rplot%03d.pdf"),  :
  impossible d'ouvrir le fichier en argument de 'pdf' 'Rplots.pdf'
Exécution arrêtée
Systemcall.cpp(270): Systemcall: 'Rscript --verbose --no-save --no-restore 
"/usr/local/share/lyx-2.0.3svn/scripts/lyxsweave.R" 
"/tmp/lyx_tmpdir.T21839/lyx_tmpbuf2/""sweave.Rnw" 
"/tmp/lyx_tmpdir.T21839/lyx_tmpbuf2/""sweave.tex" ISO-8859-15 
"/usr/local/share/lyx-2.0.3svn/examples/"' finished with exit code 1

Error: Conversion du fichier impossible


I installed R and related packages on my Debian box (Squeeze, R version 2.11). 
While updating fr.po for 2.0.3, I saw something about a requirement for R 
version >=2.14.

Is that the reason of failure ?

--
Jean-Pierre



Re: String Freeze for 2.0.3

2012-02-01 Thread Jean-Pierre Chrétien

Le 01/02/2012 16:22, Xu Wang a écrit :



What compiler are you using Jean-Pierre?


Here you are:

$ lyx-2.0.3svn -version
LyX 2.0.3svn (not released yet)
Built on Jan 31 2012, 18:39:32
Configuration
  Host type:i686-pc-linux-gnu
  Special build flags:  build=development warnings assertions 
stdlib-debug concept-checks use-aspell

  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:   -Wextra -Wall   -g -O
  C++ Compiler: g++ (4.4.5)
  C++ Compiler LyX flags:
  C++ Compiler flags:   -Wextra -Wall   -g -O
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.6.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.0.3svn

--
Jean-Pierre




Re: Sweave manual pdf compilation fails

2012-02-01 Thread Jean-Pierre Chrétien

Le 01/02/2012 17:15, Yihui Xie a écrit :

I guess you compiled the document under
/usr/local/share/lyx-2.0.3svn/examples/, right?

I believe the problem is that R has no write privilege to that
directory, so the default pdf() device cannot be started there. You
can copy sweave.lyx to a directory where you have write privilege, and
see if it compiles correctly.


Oops, stupid of me, sorry.

--
Jean-Pierre


Re: Sweave manual pdf compilation fails

2012-02-01 Thread Jean-Pierre Chrétien

Le 01/02/2012 17:15, Yihui Xie a écrit :

I guess you compiled the document under
/usr/local/share/lyx-2.0.3svn/examples/, right?

I believe the problem is that R has no write privilege to that
directory, so the default pdf() device cannot be started there. You
can copy sweave.lyx to a directory where you have write privilege, and
see if it compiles correctly.


So I opened the example file in the compilation tree (which is under my personal 
account) and the error is gone, but now it does not find Sweave.sty.


The doc itself says it should, but unfortunately the Debian package puts the 
file in

/usr/share/R/texmf

instead of the documented

/usr/share/R/texmf/tex/latex

So I copied the file as

/usr/local/texlive/texmf-local/tex/latex/sweave/Sweave.sty

and ran texhash, and I get the pdf all right.

Seems thus that the manual does not compile out of the box on Debian Squeeze,
due to the path problem.

--
Jean-Pierre


Re: Sweave manual pdf compilation fails

2012-02-01 Thread Jean-Pierre Chrétien

Le 01/02/2012 18:20, Yihui Xie a écrit :


If possible, I strongly recommend you update R to the latest 2.14.1
(it is pretty easy to update if you set a CRAN mirror; see
instructions at http://cran.r-project.org/bin/linux/debian/). There
have been many changes in Sweave since 2.11.


Sure, I can make a local install of R as I do for TeXLive and LyX, but will I 
get dependency problems with Debian packages ?


--
Jean-Pierre


Re: Sweave manual pdf compilation fails

2012-02-02 Thread Jean-Pierre Chrétien

Le 01/02/2012 20:16, Yihui Xie a écrit :

The patch is pretty simple: http://www.lyx.org/trac/ticket/8019


I removed Sweave.sty from texmf-local, so that LyX cannot find it that way, 
applied the patch, and the Sweave manual compiles now fine from the Help menu.
No failure because of write permission needed to access the LyX tree, nor 
because Sweave.sty is not found in /usr/share/R/texmf/


--
Jean-Pierre


Re: LyX 2.0.3 Sources Available

2012-02-19 Thread Jean-Pierre Chrétien
Richard Heck  comcast.net> writes:

> 
> 
> LyX 2.0.3 source tarballs are available from:
>  http://frege.brown.edu/lyx/
> Please let me know if there are any difficulties. I'll plan to release 
> late this week (Friday or Saturday) if there are not.

LyX compiles and installs fine on Debian Squeeze with this configuration:

LyX 2.0.3 (2012-02-19)
Built on Feb 19 2012, 18:07:24
Configuration
  Host type:i686-pc-linux-gnu
  Special build flags:  build=release use-aspell
  C   Compiler: gcc 
  C   Compiler LyX flags:
  C   Compiler flags:-O2
  C++ Compiler: g++ (4.4.5)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags: 
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.6.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.0.3


-- 
Jean-Pierre




Update Roadmap page

2012-02-24 Thread Jean-Pierre Chrétien
Hello,

While updating the French translation of

http://www.lyx.org/RoadMap/

I see that the table describing the stable version still points on 2.0.1, I
guess this can be corrected in a single step when 2.0.3 is out.

-- 
Jean-Pierre




Wiki page editing

2012-03-21 Thread Jean-Pierre Chrétien
Hello,

I'm willing to edit the web pages after 2.0.3 is out, but now when I try to
login nothing happens.
Has the password been changed ?

-- 
Jean-Pierre




Re: Wiki page editing

2012-03-21 Thread Jean-Pierre Chrétien
Pavel Sanda  lyx.org> writes:


> 
> No, its broken. Christian is slowly trying to recover. Pavel
> 

Ok, I will wait then. Does he need help ? I'm running pmwikis for my personal
needs (after seeing lyx wiki features :-)

-- 
Jean-Pierre




Re: Wiki page editing

2012-03-22 Thread Jean-Pierre Chrétien

Le 21/03/2012 17:40, Richard Heck a écrit :

On 03/21/2012 11:09 AM, Jean-Pierre Chrétien wrote:

Pavel Sanda<sanda lyx.org> writes:



No, its broken. Christian is slowly trying to recover. Pavel


Ok, I will wait then. Does he need help ? I'm running pmwikis for my
personal
needs (after seeing lyx wiki features :-)


Apparently, the problem is that the version of pmwiki we have doesn't
like the version of PHP we have. So the former needs to be upgraded. I
think Christian was hoping to get to it this weekend.


I had this one once, if the problem is that you have php5, I remember setting 
the name of the index.php file to index.php5 solved the problem... But as the 
site works, I guess that it is not so simple...


--
Jean-Pierre


Unicode issues when porting from Windows to Linux

2012-03-26 Thread Jean-Pierre Chrétien
Hello,

A French user sent me a document typed in with LyX on Windows. 
I get two kind of problems on Debian Squeeze, apparently both due to the
encoding of the apostrophe.
This encoding is â\200\231 in the original document, 
and the apostrophe appears correctly as such in the LyX window, 
the shell window if I cat the LyX file, and
in the present post: here it is ’

The first error happens when there are apostrophes in the file name :

Error 84 returned from iconv when converting from UCS-4LE to ISO-8859-15

The second one is a warning that happens when an apostrophe is detected in an
Index entry :

LyX's automatic index sorting algorithm faced
problems with the entry 'Discours de l’institution'.
Please specify the sorting of this entry manually, as
explained in the User Guide.
Warning: Index sorting failed

It is easy to replace the typographic apostrophes by character ',
but it took mea while to figure out the first one (and its is a bore
to rename all figure file paths). 
The second one is just boring, the first one kills the exportation to latex,
and thus the compilation.

Dores this deserve a ticket ?

-- 
Jean-Pierre






Use Insert>File>Child Document>Program Listing with Unicode encoded file

2014-04-08 Thread Jean-Pierre Chrétien

Hello,

A thread on lyx-fr was raised on the suject: multi-byte characters are not 
supported in this situation.
Among several workarounds, one is to convert the file to latin9 with iconv: I 
wonder if it could be possible for LyX to perform the iconv conversion on line.
There is no problem with Insert>Source code because the characters are exported 
to LaTeX in the document encoding,.


I have a second suggestion about the Insert>File>Child Document>Program Listing 
menu: could the relative width of the two columns be customizable ? The room 
left to display the authorized arguments is a bit narrow. Should I post an 
enhancement on bugzilla?


--
Jean-Pierre



Can't locate magic.h on Debian Squeezy

2014-06-16 Thread Jean-Pierre Chrétien
Hello,

I get this when I compile 2.1.x :


=== The following minor problems have been detected by configure.
=== Please check the messages below before running 'make'.
=== (see the section 'Problems' in the INSTALL file)

== cannot find magic.h. Please check that the libmagic library
   is correctly installed on your system.
   Falling back to builtin file format detection.


I have packages libmagic ans libmagic1 installed, but magic.h lies in

/usr/include/linux/magic.h

Should I make links in /usr/include, or should I instruct the makefiles to
find it there ?

-- 
Jean-Pierre





Underlined letter shortcuts management

2014-08-26 Thread Jean-Pierre Chrétien
Hello,

While translating the Beamer manual in French, I get a lot of new shortcut
conflicts due to the dynamical menus feature. The new menu items clash with
shortcuts which have been valid with a "common" use of LyX.

I see that a lot of underlined letter shortcuts coexist with "top level
shortcuts". Would it be safe to simply remove all these redundant letter
shortcuts, to free new letters. This could be done in the English po file as
well, in order to remove mismatches when using pocheck.pl.

BTW, where are the top level shortcuts defined ?

-- 
Jean-Pierre




Re: Underlined letter shortcuts management

2014-08-26 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

> 
> BTW, where are the top level shortcuts defined ?
> 

Stupid of me ! In the bind files, I guess.

-- 
Jean-Pierre






Re: FTP server now setup for the LyX server

2014-08-26 Thread Jean-Pierre Chrétien
Christian Ridderström  gmail.com> writes:

> 
> 
> Hi,
> 
> 
> A long time ago (2012) I tried setting up an FTP server but couldn't get
it to work in a fashion I felt was secure enough. But now during my vacation
I've had time to try again in peace and quiet. And it seems I've got it working.

Great that you could find some time to improve the wiki.
If you have still some time available, could you have a look at the lyx web
site as well ?
There has been at some time a regression which I find awkward: when you were
in the site on some English page e.g., when you clicked on one of the
language flags, you went in the same page in the new language. Now you get
at the home page insread. It's not very boring if the page is in the left
sidebar, more if the pag is somewhere in the tree.

-- 
Jean-Pierre




Re: Underlined letter shortcuts management

2014-08-27 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

> I see that a lot of underlined letter shortcuts coexist with "top level
> shortcuts". Would it be safe to simply remove all these redundant letter
> shortcuts, to free new letters?

No way, in French top level shortcuts like Alt+A 1 do not work with French
UI because in the menubar, "View" is translated by "Affichage", so Alt+A
opens the View menu and the next argument "1" is ineffective.

The discussion in Bug #9227 states that this is a Qt bug, which appeared
with 2.1. Here it is already present with 2.0.8.1, which seems normal I as
both versions are compiled with Qt 4.8.2, which is the version coming with
Debian Wheezy.

What about deconnecting completely top level bindings from underlined letter
bindings by replacing all Alt+letter by Alt+noletter in bind files ?
I know that this will be a great change for those who are accustomed to top
level bindings, it could maybe done in 2.2 ?

Anyway, as far as 2.1 is concerned, I can safely assume that top level
bindings work, so again, why not suppress menu bindings when a top level
binding is present ?

-- 
Jean-Pierre




Re: 2.1.2 Tarballs Now Available

2014-09-23 Thread Jean-Pierre Chrétien
Richard Heck  lyx.org> writes:

> 
> 
> You can find tarballs for 2.1.2 at
>       http://frege.brown.edu/lyx/
>   Please prepare binaries ASAP. I'd like to release at the end of
>   the week, if possible.

Compiles fine with Debian Wheezy, but the fresh examples/fr/beamer.lyx and
examples/fr/beamer-article.lyx files does not seem to be in the tarballs, in
spite of the fact that you committed them 13 days ago.

-- 
Jean-Pierre




Re: Source Tarballs for 2.1.3

2015-02-06 Thread Jean-Pierre Chrétien
Richard Heck  lyx.org> writes:

> 
> 
> Source tarballs for 2.1.3 can be found here:
>  ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/2.1.3/
> Please prepare binaries by Monday. I'd like to do the release on Tuesday.

Compiles and runs fine on Debian Wheezy/TexLive 2014 :

Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=release use-hunspell
  C++ Compiler: g++ (4.7)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags: 
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.8.2
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.1.3> 

I seldom read the splash file, but I see a reference to 

View>View->View [PDF (pdflatex)]

which is no more true, it should read 

Document->View [PDF (pdflatex)]

-- 
Jean-Pierre


Re: French Math manual fails to export with LuaTeX and system fonts

2015-04-06 Thread Jean-Pierre Chrétien
Scott Kostyshak  lyx.org> writes:

> 
> To reproduce, open fr/Math.lyx, click "Use non-TeX fonts", and choose
> e.g. "FreeSans" for the three fonts. Then view as PDF (LuaTeX).
> 

At the first call, I get the following errors (without even selecting "Use
non-TeX fonts") :


 (./Math.aux
! String contains an invalid utf-8 sequence.
l.32 ...el{tab:Unit=E9s-disponibles}{{1}{3}{Unit
  �s disponibles}{table.1}{}}
A funny symbol that I can't read has just been (re)read.
Just continue, I'll change it to 0xFFFD.

! Undefined control sequence.
 r@tab:
  Unit=E9s-disponibles
l.32 ...bles}{{1}{3}{Unit�s disponibles}{table.1}{}}
 
! Undefined control sequence.
 r@sub:
  Fractions
l.35 ...ctions\index {Fractions}}{subsection.3.2}{}}

! Undefined control sequence.
 r@sub:
  Garnitures
l.41 ...see{Symboles chimiques}}}{subsection.3.7}{}}

! Undefined control sequence.
 r@sub:
  Points-de-suspension
l.44 ...x {Points de suspension}}{subsection.3.9}{}}

! Undefined control sequence.
 r@sec:
  Matrices
l.46 ...10}{Matrices\index {Matrices}}{section.4}{}}

! String contains an invalid utf-8 sequence.
l.50 ...8ses-manuelle}{{5.1.1}{12}{Taille de parenth
  �se manuelle\index {Taille...

! Undefined control sequence.
 r@sub:
  Taille-parenth=E8ses-manuelle
l.50 ...renth�ses!manuelle}}{subsubsection.5.1.1}{}}

and a lot of similat erroors


All these errors appear when the .aux file is read, in the lines used to
build the table of contents or tables. Each error appears twice.

There are more than 100 errors, so compilation stops and no output is produced.

I'm quite puzzled, because after closing and reopening the file, I get no
more errors and the pdf document opens up.

I must say that in the meanwhile, I tried to export to LaTeX (LuaTeX), but I
could not compile from the command window because of errors about the
unability to copy pdf icon files from temporary to
/usr/local/share/lyx-2.2.0dev/images (where I have no write privileges). I
wonder why because the png's are there all right and the pdfs should not be
needed I guess.

> 
> Further, if the above is done with es/Math.lyx the document is
> compiled without problems. And strangely the preambles are almost
> identical. So I am curious which difference causes the failing in
> compile for the French version.
> 
> Any ideas?


About the latter, the only one I can have is a difference between
frenchb.def and other .def files.

Can you close and reopen Math.lyx and confirm the bug ?

-- 
Jean-Pierre


Re: svgz conversions to pdf fail because of images directory permissions (was: F rench Math manual fails to export with LuaTeX and system fonts)

2015-04-09 Thread Jean-Pierre Chrétien
Kornel Benko  lyx.org> writes:

> Yes, the png are there, but there are also .svgz files. They are
preferably used and converted to pdf.

You mean, converted on the fly each time they are needed ? I correctly see
the inskape commands appearb in the buffer line when I view PDF, but the
error happens when I want to export to pdflatex.

> You are not the first one having objections about copying them to
installed path.
> (If you would use in-build-lyx, the copies will go to the lyx source dir)

I don't understand, why not decompress these files and copy them to the
proper directory when I run "sudo make install", if they must be static
files like the pngs ? With the sudo command, no permission problems will
arise. And if they are copied to the 
/usr/local/share/lyx-2.2.0dev/images
directory (if I run a proper "sudo chmod" command on this dir), they *will*
become static.

I'm not sure I have understood the svgz stuff in fact :-(

-- 
Jean-Pierre




Re: French Math manual fails to export with LuaTeX and system fonts

2015-04-11 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

> 
> Scott Kostyshak  lyx.org> writes:
> 
> > 
> > To reproduce, open fr/Math.lyx, click "Use non-TeX fonts", and choose
> > e.g. "FreeSans" for the three fonts. Then view as PDF (LuaTeX).
> > 
> 
> At the first call, I get the following errors (without even selecting "Use
> non-TeX fonts") :
> 
> 
>  (./Math.aux
> ! String contains an invalid utf-8 sequence.
> l.32 ...el{tab:Unit=E9s-disponibles}{{1}{3}{Unit
>   �s disponibles}{table.1}{}}

[snip]

Testing on branch, I get exactly the same behavior as with master :
 * first time I select Document->View->PDF (LuaTeX), I get more than 100
errors when latex explores the .aux file;
 * second time I select Document->View->PDF (LuaTeX), all works fine.

However I see these errors in the buffer line at each latex run :


error: ...ive/2014/texmf-dist/tex/generic/babel-french/frenchb.lua:63:
attempt to index a nil value
error: ...ive/2014/texmf-dist/tex/generic/babel-french/frenchb.lua:63:
attempt to index a nil value
error: ...ive/2014/texmf-dist/tex/generic/babel-french/frenchb.lua:63:
attempt to index a nil value


So differences between Spanish and French may happen rather in .lua files
than .def files.

-- 
Jean-Pierre




Re: French Math manual fails to export with LuaTeX and system fonts

2015-04-12 Thread Jean-Pierre Chrétien
Scott Kostyshak  lyx.org> writes:

> 
> On Sat, Apr 11, 2015 at 2:44 AM, Jean-Pierre Chrétien
>  free.fr> wrote:

> > So differences between Spanish and French may happen rather in .lua files
> > than .def files.
> 
> Interesting. Thanks for looking into this Jean-Pierre. I wonder if
> this would be worth following up on. Maybe we should wait until TeX
> Live 2015 (pretest should start in a day or so I think) and if it's
> not fixed report it somewhere?

Yes, the nil value seems to have been corrected on Sept 18, 2014 :

https://www.tug.org/svn/texlive/trunk/Master/texmf-dist/tex/\
generic/babel-french/frenchb.lua?r1=34367=35192

-- 
Jean-Pierre


biblatex-module

2015-04-14 Thread Jean-Pierre Chrétien
Hello,

Following a thread on the French mailing list, is there a reason not to
include the biblatex module in the LyX distribution ?
I can of course easily download it from the wiki to my lyx personal layout
directory, but it would be appear in the po files and would thus be
translated in the module window.

-- 
Jean-Pierre




Pointer toward LyX in the R Wikipedia page

2013-01-05 Thread Jean-Pierre Chrétien

Dera developers,

Happy new year to all of you, keep the good work going.

I have added a pointer in the French Wikipedia page about R, see section 3 in

http://fr.wikipedia.org/wiki/R_%28langage_de_programmation_et_environnement_statistique%29

I hope this is appropriate (Jean-Marc ?).

If so, maybe a similar pointer could be added in section 6.2 of the 
corresponding English page.


--
Jean-Pierre


GuiDocument.cpp

2013-01-20 Thread Jean-Pierre Chrétien

Hello,

While updating fr.po for trunk, I found a typo in an original message.
Corrected in the attached patch.

--
Jean-Pierre
--- ./src/frontends/qt4/GuiDocument.cpp.orig	2013-01-20 15:05:48.0 +0100
+++ ./src/frontends/qt4/GuiDocument.cpp	2013-01-20 15:06:18.0 +0100
@@ -1287,7 +1287,7 @@
 			docstring const output_type = (tc.outputType() == lyx::DOCBOOK) ? _("DocBook") : _("LaTeX");
 			tooltip += '\n' + toqstr(wrap(bformat(_("Class not found by LyX. "
 			   "Please check if you have the matching %1$s class "
-			   "and all requires packages (%2$s) installed."),
+			   "and all required packages (%2$s) installed."),
 			 output_type, from_utf8(tc.prerequisites(", ");
 		}
 		latexModule->classCO->addItemSort(toqstr(tc.name()),


LyX.cpp

2013-01-20 Thread Jean-Pierre Chrétien


Hello again,

While updating fr.po for trunk, I found changes in the message implementing
lyx --help, and I think I found a typo (not in the new stuff, however).

I think that pointing to

Tools->Preferences->File Handling->File Formats->Short Name

is not correct because the exported file type is shown in

Tools->Preferences->File Handling->File Formats->Format

The attached patch corrects this.

--
Jean-Pierre

--- ./src/LyX.cpp.orig	2013-01-20 18:17:39.0 +0100
+++ ./src/LyX.cpp	2013-01-20 18:22:54.0 +0100
@@ -1025,7 +1025,7 @@
 		  "  where command is a lyx command.\n"
 		  "\t-e [--export] fmt\n"
 		  "  where fmt is the export format of choice. Look in\n"
-		  "  Tools->Preferences->File Handling->File Formats->Short Name\n"
+		  "  Tools->Preferences->File Handling->File Formats->Format\n"
 		  "  to get an idea which parameters should be passed.\n"
 		  "  Note that the order of -e and -x switches matters.\n"
 		  "\t-E [--export-to] fmt filename\n"


Re: LyX.cpp

2013-01-21 Thread Jean-Pierre Chrétien

Le 20/01/2013 19:12, Scott Kostyshak a écrit :


The exported file type is shown where you suggest, but I think the
Short Name is what LyX understands and needs. You can test this out.
If you want to export to PDF (pdflatex), the following does not work:
$ lyx -e "PDF (pdflatex)" example.lyx
The following does:
$ lyx -e pdf2 example.lyx

Maybe the message needs clarification? You could say something like
<>


You're right of course, I use frequentley export -e pdf myself, I should have 
remembered.


What do you think of
\t-e [--export] fmt\n
  where fmt is the export format of choice. Look in\n
  Tools->Preferences->File Handling->File Formats->Short Name\n
  to see which parameter (which differs from the format name\n
  in the File->Export menu) should be passed.\n
  Note that the order of -e and -x switches matters.\n

--
Jean-Pierre


Re: LyX.cpp

2013-01-22 Thread Jean-Pierre Chrétien

Le 22/01/2013 09:30, Scott Kostyshak a écrit :

On Mon, Jan 21, 2013 at 3:07 AM, Jean-Pierre Chrétien




   to see which parameter (which differs from the format
name\n




Sounds good to me. I also like your replacement of "to get an idea"
with "to see" and "parameters" with "parameter". The only thing that
bugs me is the two "which"es so close together, but that's better than
anything I can think of and I have to control my level pickyness :)


What about
 to see which parameter (different from the format

--
Jean-Pierre


Modifications of English messages in the pot file

2013-01-27 Thread Jean-Pierre Chrétien

Hello,

After updating fr.po for trunk, I suggest these few changes in the sources.

One message is unclear IMHO :
In PrefPrinterUI.ui, replace
'Setting causes printer command to print to file and then use this actually to 
print.'

with
'Command transmitted to the system to actually print the postscript file.'
The first attached patch does this.

These strings differ in the text and in the tooltip:
  - in some of the theorems*.inc files
'Alternative Theorem String'
  - in the svcommon.inc file
'Longest Description Label'
The second attached patch corrects this.

--
Jean-Pierre



--- src/frontends/qt4/ui/PrefPrinterUi.ui.orig	2013-01-27 15:10:37.0 +0100
+++ src/frontends/qt4/ui/PrefPrinterUi.ui	2013-01-27 15:38:49.0 +0100
@@ -127,7 +127,7 @@
   

 
- Setting causes printer command to print to file and then use this actually to print.
+ Command transmitted to the system to actually print the postscript file.
 
 
  
--- lib/layouts/theorems-ams-bytype.inc.orig	2013-01-27 15:21:58.0 +0100
+++ lib/layouts/theorems-ams-bytype.inc	2013-01-27 15:26:20.0 +0100
@@ -55,7 +55,7 @@
 	NextNoIndent  1
 	Argument 1
 		LabelString   "Alternative Theorem String"
-		Tooltip   "Alternative theorem string"
+		Tooltip   "Alternative Theorem String"
 	EndArgument
 	LabelSep  xx
 	ParIndent MMM
--- lib/layouts/theorems-ams.inc.orig	2013-01-27 15:22:13.0 +0100
+++ lib/layouts/theorems-ams.inc	2013-01-27 15:25:59.0 +0100
@@ -29,7 +29,7 @@
 	NextNoIndent  1
 	Argument 1
 		LabelString   "Alternative Theorem String"
-		Tooltip   "Alternative theorem string"
+		Tooltip   "Alternative Theorem String"
 	EndArgument
 	LabelSep  xx
 	ParIndent MMM
--- lib/layouts/theorems-bytype.inc.orig	2013-01-27 15:22:25.0 +0100
+++ lib/layouts/theorems-bytype.inc	2013-01-27 15:25:12.0 +0100
@@ -31,7 +31,7 @@
 	NextNoIndent  1
 	Argument 1
 		LabelString   "Alternative Theorem String"
-		Tooltip   "Alternative theorem string"
+		Tooltip   "Alternative Theorem String"
 	EndArgument
 	LabelSep  xx
 	ParIndent MMM
--- lib/layouts/theorems.inc.orig	2013-01-27 15:22:45.0 +0100
+++ lib/layouts/theorems.inc	2013-01-27 15:25:24.0 +0100
@@ -29,7 +29,7 @@
 	NextNoIndent  1
 	Argument 1
 		LabelString   "Alternative Theorem String"
-		Tooltip   "Alternative theorem string"
+		Tooltip   "Alternative Theorem String"
 	EndArgument
 	LabelSep  xx
 	ParIndent MMM
--- lib/layouts/theorems-starred.inc.orig	2013-01-27 15:23:28.0 +0100
+++ lib/layouts/theorems-starred.inc	2013-01-27 15:24:35.0 +0100
@@ -30,7 +30,7 @@
 	NextNoIndent  1
 	Argument 1
 		LabelString   "Alternative Theorem String"
-		Tooltip   "Alternative theorem string"
+		Tooltip   "Alternative Theorem String"
 	EndArgument
 	LabelSep  xx
 	ParIndent MMM
--- lib/layouts/svcommon.inc.orig	2013-01-27 15:32:24.0 +0100
+++ lib/layouts/svcommon.inc	2013-01-27 15:33:08.0 +0100
@@ -596,7 +596,7 @@
 Style Description
 	Argument 1
 	  LabelString	"Longest Description Label"
-	  Tooltip	"Longest description label"
+	  Tooltip	"Longest Description Label"
 	EndArgument
 	LabelFont
 	  Series	Medium


Re: Modifications of English messages in the pot file

2013-01-27 Thread Jean-Pierre Chrétien

Le 27/01/2013 15:56, Jürgen Spitzmüller a écrit :

Jean-Pierre Chrétien wrote:

These strings differ in the text and in the tooltip:
- in some of the theorems*.inc files
'Alternative Theorem String'
- in the svcommon.inc file
'Longest Description Label'


This is intentional. The HIG we draw on suggests Header Capitalization (all
words except prepositions, conjunctions and articles capitalized) for the
menus (which is where the LabelStrings are used), and Sentence capitalization
(Only first word capitalized) for tooltips. This only applies to English, of
course.


Sure, in French we capitalize much less.
Anyway, forget my suggestion.

--
Jean-Pierre


Re: Modifications of English messages in the pot file

2013-01-29 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

> One message is unclear IMHO :
> In PrefPrinterUI.ui, replace
> 'Setting causes printer command to print to file and then use this actually 
> to 
> print.'
> with
> 'Command transmitted to the system to actually print the postscript file.'
> The first attached patch does this.

Jürgen answered to the second part of the subject, but what about this message ?

-- 
Jean-Pierre




Unknown tags in lyxrc.defaults

2013-02-19 Thread Jean-Pierre Chrétien

Hello,

After an update of lyx-2.0.6dev, I get this after reconfigure log
when I launch LyX :


LyX: Unknown tag `-lpf' [around line 16 of file ~/.lyx-2.0.6dev/lyxrc.defaults 
current token: '-lpf' context: '']
LyX: Unknown tag `$$i' [around line 16 of file ~/.lyx-2.0.6dev/lyxrc.defaults 
current token: '$$i' context: '']
LyX: Unknown tag `-mode' [around line 16 of file ~/.lyx-2.0.6dev/lyxrc.defaults 
current token: '-mode' context: '']
LyX: Unknown tag `EditPosition' [around line 17 of file 
~/.lyx-2.0.6dev/lyxrc.defaults current token: 'EditPosition' context: '']



I removed ~/.lyx-2.0.6dev, same result.

Debian Squeeze, configuration :
  Host type:i686-pc-linux-gnu
  Special build flags:  build=development warnings assertions 
stdlib-debug concept-checks use-aspell

  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:   -Wextra -Wall   -g -O
  C++ Compiler: g++ (4.4.5)
  C++ Compiler LyX flags:
  C++ Compiler flags:   -Wextra -Wall   -g -O
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.6.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.0.6dev

--
Jean-Pierre



Re: LyX 2.0.6 Source

2013-05-01 Thread Jean-Pierre Chrétien
Richard Heck  lyx.org> writes:

> 
> 
> The source code for LyX 2.0.6 is now available at
>  http://frege.brown.edu/lyx/
> Please test and compile binaries. I'll aim to do the actual release 
> later this week.

Compiles fine on Debian squeeze, , happy that you could commit patch
correcting bug #8648.

Configuration
  Host type:i686-pc-linux-gnu
  Special build flags:  build=release use-aspell
  C   Compiler: gcc 
  C   Compiler LyX flags:
  C   Compiler flags:-O2
  C++ Compiler: g++ (4.4.5)
  C++ Compiler LyX flags:
  C++ Compiler flags:-O2
  Linker flags: 
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.6.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.0.6

-- 
Jean-Pierre





Bounding box of png files

2013-05-04 Thread Jean-Pierre Chrétien

Hello,

A recent post on lyx-fr

http://thread.gmane.org/gmane.editors.lyx.french/1769

draw my attention about a bounding box consistency problem for the exemple.png 
file attached to this post, which may happen with other png files unless this 
one is very particular.


This image is recognised by LyX as being 400x900
(Graphics>Clipping>Get from file).

However clipping to {90,30,370,815} to remove left legend and title fails 
completely and moves the figure around the page whatever the LaTeX engine 
chosen, in spite of the fact that clipping appears correctly in the LyX window.


Converting externally the file to eps with IM convert gives a BB of
0 0 203 456. Clipping the original png figure to homothetic values
{46,15,188,413} gives a wrong clipping on screen, but a correct one on the 
output.

Moreover, applying the ebb utility to exemple.png gives a BB of
0 0 288 648
but this is harmless as LyX obviously does not use this utility.

Applying

$ identify -verbose exemple.png | head
Image: exemple.png
  Format: PNG (Portable Network Graphics)
  Class: DirectClass
  Geometry: 400x900+0+0
  Resolution: 55.9x55.9
  Print size: 7.15564x16.1002
  Units: PixelsPerCentimeter

does not help much, I don't see data explaining the difference between the 
difference in pixel size in png and eps.


Does this deserve an entry in bugzilla ? A warning in the docs ?

--
Jean-Pierre





Re: LyX 2.0.6 Source

2013-05-24 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

> 
> Compiles fine on Debian squeeze, , happy that you could commit patch
> correcting bug #8648.
> 
> Configuration
[]
>   C++ Compiler: g++ (4.4.5)
[]
>   Qt 4 Frontend:
>   Qt 4 version: 4.6.3
[]

I've upgraded from squeeze to wheezy, lyx-2.0.6 still compiles fine with

  C++ Compiler: g++ (4.7)
[]
  Qt 4 Frontend:
  Qt 4 version: 4.8.2

-- 
Jean-Pierre




Re: Wrong language for theorems/lemma/other amsthm environments

2013-06-09 Thread Jean-Pierre Chrétien



> Hi Damien,
>
> This is a very nice and clean minimal example (dare I say perfect?). I
> cannot reproduced the problem, even when using the French interface.

Me neither with lyx-2.0.6 on Wheezy, nor even with 1.6.10.
Might this have been a regression in the early lyx-2.0.x versions ?

--
Jean-Pierre


Re: [LyX/master] Return an error if file-open is called with a non-absolute path

2013-12-10 Thread Jean-Pierre Chrétien

Kornel wrote :

> The error message in the status line: 'Absolute filename expected.

Same here with the latest master, compiled as

Configuration
  Host type:x86_64-unknown-linux-gnu
  Special build flags:  build=development warnings assertions 
stdlib-debug concept-checks use-aspell use-hunspell

  C++ Compiler: g++ (4.7)
  C++ Compiler LyX flags:
  C++ Compiler flags:   -Wextra -Wall   -g -O
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.8.2
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-2.1.0dev

In addition, it happened twice that, after minimizing the LyX window, it reopens 
blank, and I have to kill the task. Current work is lost if changes were not 
saved. However, I can't reproduce this at will, but it is really boring as it 
means loss of data.


--
Jean-Pierre




Re: [LyX/master] Return an error if file-open is called with a non-absolute path

2013-12-10 Thread Jean-Pierre Chrétien

Kornel wrote:
>> Jean-Pierre wrote:
>> In addition, it happened twice that, after minimizing the LyX window, it
>> reopens
>> blank, and I have to kill the task.


> That is new.

Sure, but I can't file a bug report if I can't reproduce it :-)

> For now, because Vincent seems unavailable, take this patch.

Works fine, thanks.

--
Jean-Pierre



Re: Checksums and signing

2010-06-18 Thread Jean-Pierre Chrétien

Pavel Sanda a écrit :

Jean-Pierre Chrétien wrote:



Btw, the named link pointed to in section 1 is toc11, not toc7.


which link?


gpg-signed in "The tarballs are gpg-signed".

--
Jean-Pierre


Re: Checksums and signing

2010-06-18 Thread Jean-Pierre Chrétien

Pavel Sanda a écrit :

Jean-Pierre Chrétien wrote:

Hello,

I just translated in French this new section of 
<http://www.lyx.org/Download>
and I had a try with this new procedure. I'm new to gpg, so where do I find 
te keyserver ? Should not this information be added to the paragraph ?


it should find it itself. if your run gpg for the first time, just iterate it
once more.


Doesn't work...

 gpg  --keyserver  wwwkeys.eu.pgp.net   --recv-keys  C7FB382D

works fine.
Seems that gpg isn't packaged with a default keyserver on Debian Lenny.

Then:
 gpg --verify lyx-1.6.6.1.tar.bz2.sig
gpg: Signature made Wed Jun 16 19:41:27 2010 CEST using RSA key ID C7FB382D
gpg: Good signature from "LyX Release Manager ...
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the 
owner.

Primary key fingerprint: FE66 471B 4355 9707 AFDA  D955 DE7A 44FA C7FB 382D

Is the warning OK ?

--
Jean-Pierre




Branch compilation log on Debian

2010-07-06 Thread Jean-Pierre Chrétien

Hello,

Please find below some warnings which appear while successful 
complilation of branch (rev.34780) on Debian Lenny, with the following conf:


  Host type:i686-pc-linux-gnu
  Special build flags:  assertions concept-checks stdlib-debug 
warnings  use-aspell use-ispell

  C   Compiler: gcc
  C   Compiler LyX flags:
  C   Compiler flags:   -Wextra -Wall   -g -O
  C++ Compiler: g++ (4.3.2)
  C++ Compiler LyX flags:
  C++ Compiler flags:   -Wextra -Wall   -g -O
  Linker flags:
  Linker user flags:
  Qt 4 Frontend:
  Qt 4 version: 4.4.3
  Packaging:posix
  LyX binary dir:   /usr/local/bin
  LyX files dir:/usr/local/share/lyx-1.6.7svn


ui/CitationUi.ui: An invalid icon property 'icon' was encountered.
ui/CitationUi.ui: An invalid icon property 'icon' was encountered.
GuiImage.cpp: In member function ‘bool 
lyx::graphics::GuiImage::scale(const lyx::graphics::Params&)’:
GuiImage.cpp:168: warning: comparison of unsigned expression < 0 is 
always false
GuiSymbols.cpp: In member function ‘void 
lyx::frontend::GuiSymbols::updateSymbolList(bool)’:

GuiSymbols.cpp:437: warning: suggest parentheses around && within ||
LayoutFile.cpp: In member function ‘lyx::LayoutFileIndex 
lyx::LayoutFileList::addEmptyClass(const std::string&)’:
LayoutFile.cpp:230: warning: suggest explicit braces to avoid ambiguous 
‘else’
output_latex.cpp: In function 
‘__gnu_debug::_Safe_iterator > 
lyxTeXOnePar(const lyx::Buffer&, const lyx::Text&, 
__gnu_debug::_Safe_iterator >, 
lyx::odocstream&, lyx::TexRow&, const lyx::OutputParams&, const 
std::string&)’:

output_latex.cpp:714: warning: suggest parentheses around && within ||
Paragraph.cpp: In member function ‘void 
lyx::Paragraph::appendString(const lyx::docstring&, const lyx::Font&, 
const lyx::Change&)’:
Paragraph.cpp:1300: warning: comparison between signed and unsigned 
integer expressions
insets/ExternalTemplate.h: In constructor 
‘lyx::external::Template::Template()’:
insets/ExternalTemplate.h:66: warning: 
‘lyx::external::Template::preview_mode’ will be initialized after
insets/ExternalTemplate.h:64: warning:   ‘bool 
lyx::external::Template::automaticProduction’

insets/ExternalTemplate.cpp:52: warning:   when initialized here
insets/InsetCitation.cpp: In function ‘lyx::docstring 
lyxcomplexLabel(const lyx::Buffer&, const std::string&, 
const lyx::docstring&, const lyx::docstring&, const lyx::docstring&, 
lyx::CiteEngine)’:
insets/InsetCitation.cpp:202: warning: deprecated conversion from string 
constant to ‘char*’
insets/InsetCitation.cpp:206: warning: deprecated conversion from string 
constant to ‘char*’
insets/InsetTabular.cpp: In member function ‘bool 
lyx::Tabular::columnRightLine(size_t) const’:
insets/InsetTabular.cpp:1157: warning: suggest parentheses around && 
within ||
insets/InsetTabular.cpp: In member function ‘virtual void 
lyx::InsetTabular::doDispatch(lyx::Cursor&, lyx::FuncRequest&)’:
insets/InsetTabular.cpp:3694: warning: suggest parentheses around && 
within ||


HTH

--
Jean-Pierre


Re: LyX 1.6.7

2010-07-11 Thread Jean-Pierre Chrétien
Jürgen Spitzmüller  lyx.org> writes:

> 
> I've uploaded the tarballs to
> 
> ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.gz
> ftp://ftp.devel.lyx.org/pub/lyx/stable/lyx-1.6.7.tar.bz2
> 
> Please check and report back.

Compiles and installs fine on Debian Lenny.

Remaining warnings:
insets/InsetCitation.cpp: In function ‘lyx::docstring
lyxcomplexLabel(const lyx::Buffer&, const std::string&, const
lyx::docstring&, const lyx::docstring&, const lyx::docstring&, 
lyx::CiteEngine)’:
insets/InsetCitation.cpp:202: warning: deprecated conversion from string
constant to ‘char*’
insets/InsetCitation.cpp:206: warning: deprecated conversion from string
constant to ‘char*’

-- 
Jean-Pierre




Re: Bug #3221: nameref support

2010-07-14 Thread Jean-Pierre Chrétien
Uwe Stöhr  web.de> writes:

> 
> There is another issue: The text "on page" is not yet translated to the
document language.
> One manually has to add this preamble code:
> 
> \renewcommand*\Nameref[1]{`\nameref{#1}' auf Seite~\pageref{#1}}
> 
> "auf Seite" is hereby the German translation of "on page".
> 
> As this is no solution for us I propose this code instead:
> 
> \...@ifundefined{vref}{\usepackage{varioref}}{}
> \AtBeginDocument{
>   \renewcommand*{\Nameref}[1]
> {\nameref{#1}~\reftextfaraway{#1}}
> }

Why not

  {\nameref{#1}~\vpageref{#1}}

This will use all variants of varioref page handling.

-- 
Jean-Pierre



Re: Bug #3221: nameref support

2010-07-14 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:


> 
> Why not
> 
>   {\nameref{#1}~\vpageref{#1}}
> 
> This will use all variants of varioref page handling.

Rather  {\nameref{#1} \vpageref{#1}}, the unbrealkable space is not necessary
here (nor with \reftextfaraway in fact, page~xxx can be on the nest line).

-- 
Jean-Pierre





Re: Bug #3221: nameref support

2010-07-15 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

>
> > This will use all variants of varioref page handling.
> 
> Rather  {\nameref{#1} \vpageref{#1}}, the unbrealkable space is not necessary
> here (nor with \reftextfaraway in fact, page~xxx can be on the nest line).
> 

And to be cosnisten wit the original Nameref command

  {'\nameref{#1}` \vpageref{#1}}

which raised a new i18n issue: in French babel, this should read

 {\og \nameref{#1} \fg{} \vpageref{#1}}

As \nameref does not add quotes, nameref is itself inconsistent anyway,
so your option to remove them may be logical in fact.

-- 
Jean-Pierre








Re: Bug #3221: nameref support

2010-08-03 Thread Jean-Pierre Chrétien
Richard Heck  comcast.net> writes:

> 
> On 07/16/2010 09:41 AM, Uwe Stöhr wrote:
> >
> > So let's remove \Nameref support then.
> >
> Done.

The reference to "Textual reference plus " is still there today, 
and creates an error:

insets/InsetCommandParams.cpp(256): InsetCommand: Incompatible command name .
Warning: InsetCommand Error:

Incompatible command name.

-- 
Jean-Pierre




LyX and refstyle

2010-08-10 Thread Jean-Pierre Chrétien


Hello Danie,

LyX  is a highly integrated frontend to LaTeX, maybe
you are aware of its existence and have used it already.

The software currently provides support for basic labels and crossrefs
in LaTeX, and some features of more sophisticated cross referencing,
namely varioref and prettyref (and nameref in the next release).

The LyX developers are currently considering replacing prettyref by
refstyle in the coming release lyx-2.0.0. As one of the basic
principles of LyX development is that this should not change the
layout of already existing printed documents, you may imagine that
this raises a number of questions.

As a plain user (and a member of the team maintaining the French
translations of the interface, doc and web site), I was particularly
interested in this change because prettyref is not internationalized,
and in addition prettyref used with French babel creates an error due to
the character ":" being made active to manage the spacing before the
semi-colon. So I wrote a test file including various labels and cross
referencing using varioref, prettyref and refstyle, and I tested this
file with the planned patch replacing prettyref by refstyle, both in
English and in French.

So on behalf of the developers, I contact you to discuss the odds and
ends of refstyle implementation in LyX. Most the the discussions that
took place already can be found there: - threads on the lyx-devel
mailing list about the patches:
http://thread.gmane.org/gmane.editors.lyx.devel/114398
http://thread.gmane.org/gmane.editors.lyx.devel/126059
http://thread.gmane.org/gmane.editors.lyx.devel/128006 - discussion
about the prettyref bug in French http://www.lyx.org/trac/ticket/6609
I will summarize the discussion hereunder.

First of all, this table reflects the differences between prettyref
and restyle (the discussion is currently restricted to this single
issue):

+-++
|   prettyref |refstyle|
+-++
+--+--+---+-+--+
| eq   |  |  eq   | [eE]quation{s}  |  |
+--+--+---+-+--+
| lem  |  Lemma   |   | |  |
+--+--+---+-+--+
| thm  | Theorem  |   | |  |
+--+--+---+-+--+
| cha  | Chapter  | chap  | [cC]hapter{s}   |  |
+--+--+---+-+--+
| sec  | Section  | sec   | [sS]ection{s}   | adds § before number |
+--+--+---+-+--+
| tab  |  Table   | tab   |  [tT]able{s}|  |
+--+--+---+-+--+
| fig  | Figure   | fig   |  [fF]igure{s}   |  |
+--+--+---+-+--+
|  |  | part  |   [pP]art{s}|  |
+--+--+---+-+--+
|  |  |  fn   |   [nN]ote{s}|  |
+--+--+---+-+--+

To summarize these differences:
 1/ refstyle adds strings for equations
 2/ refstyle does not know theorems and lemmas
 3/ refstyle adds a paragraph sign before number
 4/ keyword for chapters is chap instead of cha
 5/ prettyref does not know parts and footnotes

Layout of existing documents can be maintained for 1-3 by creating a
specific refstyle.ref file as explained in section 1 of the refstyle
doc. Item 4 needs rewriting of the document to substitute keywords.
Item 5 needs care only if prettyref \newrefformat commands have been
issued by users to add commands to the small set provided by prettyref
(but this one is more complicated due to the various way to do this -
either on a document basis or on a class or package basis).  In
addition, LyX implements a large variety of theorem-like constructs,

During my test for French use of refstyle, I tried to use the
\usepackage[noconfig]{refstyle}
\input{myrefstyle.ref}
structure to add French translations to the existing set (see attached 
file).

This approach failed because of the line \DeclareLangOpt{french}{\RSfrench}
which creates a compilation error.
I had to rename locally myrefstyle.ref as refstyle.cfg:
http://www.lyx.org/trac/attachment/ticket/6609/refstyle.cfg
to get my enhancements working.

It seems therefore that no local solution exists to add new languages
to the existing set: the refstyle.cfg file itself must be modified.
The problem there is the time required for an updated version of
refstyle to appear in all TeX distributions.

The other constructs needed to integrate refstyle to 

Re: RefStyle Patch

2010-10-14 Thread Jean-Pierre Chrétien
Richard Heck  comcast.net> writes:

> 
> 
> OK, one last try at a refstyle patch. 
> 
> Comments welcome.

Tried on a simple fresh document.
Seems that package ifthen should be included, due to the tests in the preamble.

I'll investigate more with my examples.

-- 
Jean-Pierre





Re: RefStyle Patch

2010-10-27 Thread Jean-Pierre Chrétien
Jean-Pierre Chrétien  free.fr> writes:

> 
> Richard Heck  comcast.net> writes:
> 
> > 
> > 
> > OK, one last try at a refstyle patch. 
> > 
> > Comments welcome.

> I'll investigate more with my examples.
> 


Tested with French.
The \lyxref encapsulation does not work when ":" is active.
I'm trying to find a workaround, I'll keep you posted.

-- 
Jean-Pierre




Re: RefStyle Patch

2010-10-27 Thread Jean-Pierre Chrétien

Richard Heck a écrit :

On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:


Tested with French.
The \lyxref encapsulation does not work when ":" is active.
I'm trying to find a workaround, I'll keep you posted.

   

OK. Please let me know. We may need some \catcode thing in there?


Sure, that's the only solution I found : encapsulate the \lyxref call between 
commands deactivating/reactivating ":", which I found last Spring on a forum 
(see bug #6608) and rewrote a little.
I tried the \shorthandoff workaround, but this asks for a lot of testing to know 
if babel is loaded, and, if the case, if French is the selected language.
In addition, this does not work whith ":" being active elsewhere than in French, 
and even not with babel.


Here is the patch (beware of line cuts):

--- src/LaTeXFeatures.cpp.orig  2010-10-26 14:35:26.0 +0200
+++ src/LaTeXFeatures.cpp   2010-10-27 15:37:31.0 +0200
@@ -258,6 +258,9 @@

 static docstring const lyxref_def = from_ascii(
"\\makeatletter\n"
+   "\\newif\\ifcolonActive \\colonActivefalse\n"
+   "\\newcommand*{\\colonoff}{\\ifnum \\catcode`\\:=13 \\catcode`\\:=12 
\\colonActivetrue \\fi}\n"
+   "\\newcommand*{\\colonon}{\\ifcolonActive \\catcode`\\:=13 
\\colonActivefalse \\fi}\n"

"\\def\\lyxref#1...@lyxref#1:@:}\n"
"\\de...@lyxref#1:#2:{%\n"
"\\ifthenelse{\\equal{#2}{@}}%\n"
--- src/insets/InsetRef.cpp.orig2010-10-27 14:53:19.0 +0200
+++ src/insets/InsetRef.cpp 2010-10-27 15:44:17.0 +0200
@@ -95,7 +95,7 @@
return 0;
}

-   os << "\\lyxref{" << data << '}';
+   os << "\\colonoff\\lyxref{" << data << "}\\colonon{}";
return 0;
 }



To be able to test it, you need to have French strings available.
I contacted Danie Els in August about the unability of version 0.3 of refstyle 
to allow a new language without hacking refstyle.cfg. Following a private 
discussion with him, I tried a patch on refstyle.sty allowing to \input a local 
refstyle.def file containing the additional translations, without using the 
noconfig option. My patch did not work at the time.


Following r35623, I gave a fresh try to this and was able to make it work.
I contacted him again and he sent me an alpha version 0.4 of refstyle 
implementing a variant of the patch: refstyle.sty loads refstyle.def first, and 
if no refstyle.def is found, loads refstyle.cfg. So refstyle.def plays the role 
of a modified refstyle.cfg located in texmf-local.


This allows to load, as refstyle.def, a variant of refstyle.cfg to incude new 
languages until CTAN refstyle.cfg is updated.


He committed then v0.4 of the refstyle bundle to CTAN
http://www.ctan.org/tex-archive/macros/latex/contrib/refstyle/
with these improvements:

> Changes from version 0.3:
>
> (1) List of references can now distinguish between two and more than two 
items. For example:

>
> equation (1)
> equations (1) and (4)
> equations (1), (2), and (5)

LyX is not concerned right now.

>
> (2) Option "nokeyprefix" is added to remove all the prefixes in the 
\label commands. The user has now the option to use the standard latex 
\label command everywhere (especialy for old documents), for example:

>
>\label{tab:xxx} and then \tabref{tab:xxx} with refstyle

Again LyX does not use the \seclabel or \eqlabel coding I guess.
May be used for upgrades ??

>
> (3) Languages added: French, Italian and Portuguese
>

Here you are to use my test file (I will upload it with bug #6609).

You provided an English string for theorems, it seems to me that one should be 
provided for lemmas also, in order to be prettyref-coherent.


In the near future, we will need to create strings for other languages and the 
whole set of theorem-like stuff...


Do you intend to implement plurals and ranges before 2.0 is released ?

Regards

--
Jean-Pierre



Re: RefStyle Patch

2010-10-28 Thread Jean-Pierre Chrétien

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :

On 10/27/2010 04:17 AM, Jean-Pierre Chrétien wrote:


When I look at the exported latex file test_french_refstyle.tex, I see this:

\...@ifundefined{   hmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}

which creates the crossrefs for theorems.

This works in my example beacuse the test is always true, but the
code in LaTeXFeatures.cpp should read

   "\...@ifundefined{thmref}\n"
"  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"

instead of

   "\...@ifundefined{\thmref}\n"
"  {\\def\\RSthmtxt{theorem~}\\newref{thm}{name = \\RSthmtxt}}\n"

Right ?

--
Jean-Pierre



Re: RefStyle Patch

2010-10-28 Thread Jean-Pierre Chrétien

Richard Heck a écrit :



I'm not seeing the difference


Anyway, I'm going to do the other thing I suggested, I think.


The problem with ":" has vanished, but theorems are now unknown:
?? is returned in my bug #6609 example.

--
Jean-Pierre


Re: RefStyle Patch

2010-10-28 Thread Jean-Pierre Chrétien

Richard Heck a écrit :



Are there other things besides theorems we should define that aren't in 
refstyle.cfg?


To be prettyref-coherent, lemmas.



Is there some way we could provide translatability (in LyX's po files) 
of "theorem" here?


For the time being, we need a restricted set of declarations and translations
in LyX (no plurals, no capitalization).

If you declare all refstyle commands for theorems and such, marked as gettext 
strings, in the code, they will get translated in po files, but this will be 
static in the interface language.


We would like to have strings translated depending upon the current language in 
the document, to allow true babel i18n.


What about providing with LyX an auxiliary file containing the required 
translations (a refstyle.def file if new languages are needed) ?
When fully tested and fairly complete, we could send the file to Danie Els for 
update in CTAN.


--
Jean-Pierre



Re: RefStyle Patch

2010-10-29 Thread Jean-Pierre Chrétien

Richard Heck a écrit :

On 10/28/2010 12:24 PM, Jean-Pierre Chrétien wrote:




Perhaps we can do this: (i) Try to get translations from our own 
translators of theorem and lemma, if that covers everything prettyref 
does, that we can hardcode into LaTeXFeatures.cpp, so that we at least 
do as well as refstyle.cfg does with these two; (ii) Send an updated 
version of refstyle.cfg to Els, including those translations. The former 
could be removed after a while, i.e., once we had some sense that the 
new version was common enough.


What about adding an .inc file in the layout dir containing all
what is needed for theorems and alike ?

I'll post a tentative file with bug #6609 to illustrate the idea
(tentative because it's not working right now).

--
Jean-Pierre


Re: RefStyle Patch

2010-10-29 Thread Jean-Pierre Chrétien

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :



Are there other things besides theorems we should define that aren't 
in refstyle.cfg?


To be prettyref-coherent, lemmas.


Lemmas and theorems are OK now (but untranslated), thanks.

--
Jean-Pierre


Re: RefStyle Patch

2010-10-31 Thread Jean-Pierre Chrétien

Jean-Pierre Chrétien a écrit :



I'll post a tentative file with bug #6609 to illustrate the idea
(tentative because it's not working right now).



I performed some tests to make this file work and I corrected some typos in the 
file.


However, the current version does not work with LyX for two reasons:
 1/ the \...@ifpackageloaded{refstyle}{% command clashes because

\...@ifundefined{thmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}
  {}
\...@ifundefined{lemref}
  {\def\RSlemtxt{lemma~}\newref{lem}{name = \RSlemtxt}}
  {}

is encaspulated between \makeatletter \makeatother commmands
(this code is already encapsulated in such commands by LyX)

 2/ these commands:

\addto\captionsfrench{\renewcommand{\lemmaname}{Lemme}}
\addto\captionsfrench{\renewcommand{\theoremname}{Théorème}}

fail because \lemmaname and \theoremname are unknown in French babel.
Works with:

\addto\captionsfrench{\def\lemmaname{Lemme}}
\addto\captionsfrench{\def\theoremname{Théorème}}

(as recommended in the French babel doc anyway).

Currently refstyle cannot work natively with babel multilingual docs,
encapsulating strings definitions in \adddto\captions works, I've contacted 
Danie Els about this.


--
Jean-Pierre




Re: RefStyle Patch

2010-11-01 Thread Jean-Pierre Chrétien

Uwe Stöhr a écrit :
I haven't followed this thread, but have you seen that the new version 
0.4 of refstyle supports now French:


http://article.gmane.org/gmane.comp.tex.ctan.announce/8109


Sure, this follows a private mail exchange with Danie Els.

--
Jean-Pierre


Re: RefStyle Patch

2010-11-02 Thread Jean-Pierre Chrétien

Richard Heck a écrit :

On 10/31/2010 06:38 AM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :



So do we have an extra \makeatletter somewhere?


Yes, exporting my example file in LaTeX reads:


\makeatletter

%% LyX specific LaTeX commands.

\AtBeginDocument{\providecommand\secref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\eqref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\lemref[1]{\ref{#1}}}
\AtBeginDocument{\providecommand\thmref[1]{\ref{#1}}}
\makeatletter
\...@ifundefined{thmref}
  {\def\RSthmtxt{theorem~}\newref{thm}{name = \RSthmtxt}}
  {}
\...@ifundefined{lemref}
  {\def\RSlemtxt{lemma~}\newref{lem}{name = \RSlemtxt}}
  {}
\makeatother


%% Textclass specific LaTeX commands.
\theoremstyle{plain}




Currently refstyle cannot work natively with babel multilingual docs,
encapsulating strings definitions in \adddto\captions works, I've 
contacted Danie Els about this.



Is there something we can do in the meantime?


I got an anwer from Danie, I was mistaken about the multilingual feature of 
refstyle: it works all right (as \def commands are encapsulated in \extras 
commands) if refstyle is loaded *after* babel.


Is it possible to do this in LyX ?

In the meantime, I've found another point which the current patch misses:
part and chap are the prefixes in refstyle, so old refs are replaced by ?? if 
the "Use refstyle" box is checked.
I've added to convert_prettyref in lyx-2.0.py the code that you wrote last April 
and that I enhanced to convert all prefixes cha and par to chap and part.

I've added a step to deal with \newrefformat commands in the preamble.
Currently my re_newref string works as a command line in the pyton interpreter:


$ python
Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re_newref = re.compile(r"\newrefformat\{(\w+)\}\{(\w+)")
>>> m=re_newref.match('\newrefformat{cha}{Chapitre~\ref{#1}}')
>>> print m.group(1)
cha
>>> print m.group(2)
Chapitre
>>>


but not in the convert_prettyref code (beware of the extra newlines added by my 
mailer, I've posted the corresponding patch on bug #6609 anyway):



  def convert_prettyref(document):
	" Converts prettyref references to neutral formatted refs, updates part and 
chapter prefixes "

re_ref = re.compile("^\s*reference\s+\"(\w+):(\S+)\"")
re_lab = re.compile("^\s*name\s+\"(\w+):(\S+)\"")
re_newref = re.compile(r"\newrefformat\{(\w+)\}\{(\w+)")
   # Note: step 1, \newrefformat part: and chap: susbtitutions for par: 
and cha:

i = 0
while True:
i = find_token(document.preamble, "\\newrefformat{", i)
result=document.preamble[i]
document.warning("Found document.preamble[i]" + result)
if i == -1:
break
m = re_newref.match(result)
if m:
prefix = m.group(1)
remain = m.group(2)
document.warning("Found " + prefix + " " + result)
if prefix == "cha":
prefix = "chap"
elif prefix == "par":
prefix = "part"
document.preamble[i] = "\\newrefformat" + "\{" + prefix + "\}" 
+ remain

i = i + 1
# Note: step 2, reference part: and chap: susbtitutions for par: 
and cha:

i = 0
while True:
i = find_token(document.body, "\\begin_inset CommandInset ref", i)
if i == -1:
break
j = find_end_of_inset(document.body, i)
if j == -1:
document.warning("Malformed LyX document: No end of InsetRef")
i += 1
continue
i += 1
k = find_token(document.body, "reference", i)
if k == -1 or k > j:
i = j + 1
continue
m = re_ref.match(document.body[k])
if m:
prefix = m.group(1)
suffix = m.group(2)
if prefix == "cha":
prefix = "chap"
elif prefix == "par":
prefix = "part"
document.body[k] = "reference" + " \"" + prefix + ":" + suffix 
+ "\""

i = j + 1
# Note: step 3, label  part: and chap: susbtitutions for par: and 
cha:
i = 0
while True:
i = find_token(document.body, "\\begin_inset CommandInset label&q

Re: RefStyle Patch

2010-11-02 Thread Jean-Pierre Chrétien

Jean-Pierre Chrétien a écrit :

Richard Heck a écrit :

On 10/31/2010 06:38 AM, Jean-Pierre Chrétien wrote:

Jean-Pierre Chrétien a écrit :




I got an anwer from Danie, I was mistaken about the multilingual feature 
of refstyle: it works all right (as \def commands are encapsulated in 
\extras commands) if refstyle is loaded *after* babel.


Is it possible to do this in LyX ?


Danie corrected a bug about ":" being active with the new nokeyprefix option
in refstyle 0.4 (->v0.4a, currently unpublished), and in the same new version 
0.4a he managed to avoid the need to load babel before refstyle.
Thus it does not seem urgent to do someting about the multi-lingual refstyle 
feature.


--
Jean-Pierre


<    1   2   3   4   5   6   7   8   9   10   >