Re: Compilation warnings in branch
Uwe Stöhr wrote: This is already fixed in trunk, Jürgen, OK to go to branch too? Yes. Although this warning is harmless. Jürgen
Re: r34002 - lyx-devel/trunk
On 04/06/2010 05:42 PM, Vincent van Ravesteijn - TNW wrote: no i see in unpatched sources : New in 1.10.1: - make dist can now create lzma-compressed tarballs. so my proposal is lo use lzma from dependency and compression ratio reasons. OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate releases. So you should require 1.10.1. Maybe, I don't understand this well enough, but anyway, why do we require automake 1.10.1 for everyone ? Even for people not using make dist or the tarball at all. Who does use make dist by the way ? Is it only Pavel, or do other people do this as well ? For me, requiring this means that I can no longer compile on Linux as I don't have the appropriate rights there to update automake. You can still use cmake, aren't you? Abdel.
Re: Cmake compilation error
On 04/07/2010 06:19 PM, Kornel Benko wrote: Am Mittwoch 07 April 2010 schrieb José Matos: On Wednesday 07 April 2010 15:23:18 Kornel Benko wrote: Corrected and commited already. Sorry for not being responsive, but I broke my right arm, and it is somehow not easy to use a computer. Kornel I hope you have a fast recovery. :-) FWIW there is no need to reply. :-) Best regards, Thanks to all. It is now 8 days from the surgery, things are getting better. Courage Kornel! Abdel.
Re: LyX 1.6.6: please prepare for landing
Jean-Pierre Chrétien wrote:
Jürgen Spitzmüller a écrit :
Jean-Pierre Chrétien wrote:
What about bug #6608 ? Could the patch I suggested be applied ?
trac is down, but if I remember correctly, this was the French/prettyref
issue, right? I think this is too late for 1.6.6, we have to look into
that more deeply first.
No, this one is about the varioref problem (prettyref and varioref
issues are different, so I split up bug #6420 in bugs #6608 and #6609).
I see.
IIRC you propose to load an extra package. I'm not sure about that. For
me, the following preamble code fixes the problem as well:
\let\oldlabel\label
\renewcommand*{\label}{\catcode`\:=12 \oldlabel}
\let\oldpref\prettyref
\renewcommand*{\prettyref}{\catcode`\:=12 \oldpref}
But it's tedious to change catcodes like that. OTOH I don't know what the
package you propose does.
Just loading nameref (a companion package of hyperref) before varioref,
which can only be done by changing the lyX source in
./src/LaTeXFeatures.cpp
./src/insets/InsetRef.cpp
./src/mathed/InsetMathRef.cpp
This bug is discussed in
http://www.tug.org/pipermail/texhax/2005-September/004707.html
and in the README file of hyperref (section about varioref):
http://tug.ctan.org/tex-archive/macros/latex/contrib/hyperref/
The point here is that nameref can be loaded without hyperref,
I've added the patch to bug #6608 (patch against the current branch).
But the README text is not very encouraging:
There are too many problems with varioref. Nobody has time to
sort them out. Therefore this package is now unsupported.
Perhaps you are lucky and some of the features of varioref works
with the following loading order:
\usepackage{nameref}
\usepackage{varioref}
\usepackage{hyperref}
In any case, I'm reluctant to load such a complex package just because it
fixes varioref/French (if we are lucky). That is to say: I'm fine to use the
above order if hyperref is used, but without hyperref, I would rather welcome
a simpler, standalone solution.
Also, the problem is supposed to be fixed within babel itself (see the babel
docs, sec. 12.18.2). Babel does the same trick than nameref here (deactivating
actice chars within \vref and \vpageref). The strange thing is: if I export
your test file and compile it manually with pdflatex, no error occurs. The
error only shows up when compiling with LyX. I'd like to know why the babel
fix does not trigger when compiling with LyX.
As far as prettyref is concerned (bug #6609), the best would be to
remove this package, as it was already proposed in bug #2295 because of
the lack of internationalization.
This is no option for branch. We cannot drop prettyref in branch, this is a
file format change. For the same reason, we cannot add support for refstyle.
I the same line, I submitted an example file for crossrefs
http://article.gmane.org/gmane.editors.lyx.devel/126589
and I got no comments about it. Should it have been posted to lyx-docs ?
This is for trunk only. I guess Richard has an eye on it.
No, this one is for branch, the idea was to have one file for branch, to
check lyx2lyx translation to lyx-2.0 format.
I made it as exhaustive as possible to discuss possible improvements of
the lyx implementation of varioref/refstyle (ranges, lists,
capitalization, plurals, etc.)
As Richard's patch for refstyle needs some tuning, I did not turn it in
a file for lyx-2.0 yet.
Maybe some of your prettyref constructs for German language should be
added to file examples_crossrefs_lyx16.lyx,
to check conservativeness of the refstyle implementation.
But still, this case concerns trunk, not branch. In branch, we cannot do
anything wih refstyle.
Jürgen
Re: r34081 - lyx-devel/trunk/src
On 04/07/2010 07:02 PM, rgh...@lyx.org wrote: Author: rgheck Date: Wed Apr 7 19:02:44 2010 New Revision: 34081 URL: http://www.lyx.org/trac/changeset/34081 Log: Grant a long-standing wish of Lars's: LyX now functions even if we have no text classes for some reason (e.g., a corrupt textclass.lst). We still give the user a chance to reconfigure (Bo's idea). I wonder if we still really need to restart LyX to make use of any updated document class specifications. What would happen if we just reloaded? In any case we should try to not require a complete restart. Abdel.
RE: r34002 - lyx-devel/trunk
For me, requiring this means that I can no longer compile on Linux as I don't have the appropriate rights there to update automake. You can still use cmake, aren't you? Abdel. Yes. Vincent
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller wrote: Also, the problem is supposed to be fixed within babel itself (see the babel docs, sec. 12.18.2). Babel does the same trick than nameref here (deactivating actice chars within \vref and \vpageref). The strange thing is: if I export your test file and compile it manually with pdflatex, no error occurs. The error only shows up when compiling with LyX. I'd like to know why the babel fix does not trigger when compiling with LyX. The mystery is solved: Kile ran a different LaTeX distribution than LyX. Now I tracked down the problem to varioref itself. The bug does not occur in varioref 1.4p (2006/05/13), but it occurs with the newer varioref 1.4w (2009/09/13). I guess we need to submit a bug report to Frank Mittelbach (I'll do that). Jürgen
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller wrote: I guess we need to submit a bug report to Frank Mittelbach (I'll do that). The bug has been already reported: http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=latex/4093 Jürgen
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller a écrit :
Jean-Pierre Chrétien wrote:
Jürgen Spitzmüller a écrit :
Jean-Pierre Chrétien wrote:
But the README text is not very encouraging:
There are too many problems with varioref. Nobody has time to
sort them out. Therefore this package is now unsupported.
Sure, I read that, but for years the same remark could have been applied
to hyperref, and lyx managed to work with it.
In any case, I'm reluctant to load such a complex package just because it
fixes varioref/French (if we are lucky). That is to say: I'm fine to use the
above order if hyperref is used, but without hyperref, I would rather welcome
a simpler, standalone solution.
If you check the Use hyperref box in DocumentSettingsPDF all is
right (by the way, all is right also for the French versions of
UserGuide and Embedded Objects, which raised problems in the past with
earlier versions of TexLive).
Also, the problem is supposed to be fixed within babel itself (see the babel
docs, sec. 12.18.2). Babel does the same trick than nameref here (deactivating
actice chars within \vref and \vpageref). The strange thing is: if I export
your test file and compile it manually with pdflatex, no error occurs. The
error only shows up when compiling with LyX. I'd like to know why the babel
fix does not trigger when compiling with LyX.
I do not have such a result here, the logs files are alike (but for a
few changes on line numbering). I have texlive-2009 (no dynamic
updates). And the .tex files differ only by what is found in /tmp and
downwards.
--- erreur_varioref_lyx16.tex 2010-04-08 10:34:08.0 +0200
+++ /tmp/lyx_tmpdir.TJ3978/lyx_tmpbuf1/erreur_varioref_lyx16.tex
2010-04-08 10:45:06.0 +0200
@@ -1,5 +1,7 @@
-%% LyX 1.6.5 created this file. For more info, see http://www.lyx.org/.
-%% Do not edit unless you really know what you are doing.
+\batchmode
+\makeatletter
+\def\in...@path{{/tmp//}}
+\makeatother
\documentclass[french]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
With my conf. here, what is said in the babel doc is clearly not effective
(and the traffic on lyx-fr shows I'm not alone there).
So a solution would be to edit the docs where varioref is documented
and suggest to check the hyperref box, or deactivate locally : by
using \shorthandoff{:}{...} in ERT.
Another option would be to offer to the user an interface to insert
commands at the beginning of the preamble, so that
\usepackage{nameref}
could be added at the right location without LyX code change.
This has been already proposed as a general enhancement (ticket #5366).
As far as prettyref is concerned (bug #6609), the best would be to
remove this package, as it was already proposed in bug #2295 because of
the lack of internationalization.
This is no option for branch. We cannot drop prettyref in branch, this is a
file format change. For the same reason, we cannot add support for refstyle.
Sure, I was referring to the recent threads about refstyle
implementation in trunk.
--
Jean-Pierre
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller a écrit : Jürgen Spitzmüller wrote: Also, the problem is supposed to be fixed within babel itself (see the babel docs, sec. 12.18.2). Babel does the same trick than nameref here (deactivating actice chars within \vref and \vpageref). The strange thing is: if I export your test file and compile it manually with pdflatex, no error occurs. The error only shows up when compiling with LyX. I'd like to know why the babel fix does not trigger when compiling with LyX. The mystery is solved: Kile ran a different LaTeX distribution than LyX. Now I tracked down the problem to varioref itself. The bug does not occur in varioref 1.4p (2006/05/13), but it occurs with the newer varioref 1.4w (2009/09/13). I guess that explains why the behaviour with or without hyperref active was reversed with TexLive 2007 (standard in Debian Lenny). I just cheked with the test file and after hiding the local texlive2009: works without hyperref, fails with hyperref active. Thanks for digging this out. -- Jean-Pierre
Re: LyX 1.6.6: please prepare for landing
On 2010-04-05, Jürgen Spitzmüller wrote:
Translation updates and patches should be submitted *no later* than Friday,
April 23.
Please apply the following patches to fix/clean up the Greek language
support:
http://www.lyx.org/trac/attachment/ticket/6456/languages-polutonikogreek-branch.patch
to fix bug http://www.lyx.org/trac/ticket/6456.
http://www.lyx.org/trac/attachment/ticket/6458/LaTeXFeatures-greektext.patch
to fix bug http://www.lyx.org/trac/ticket/6458
Some comments to the second patch:
static docstring const textgreek_def = from_ascii(
- \\providecommand*{\\perispomeni}{\\char126}\n
- \\AtBeginDocument{\\DeclareRobustCommand{\\greektext}{%\n
- \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}\n
- \\renewcommand{\\~}{\\perispomeni}\n
- }}\n
+ \\DeclareRobustCommand{\\greektext}{%\n
+ \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}}\n
\\DeclareRobustCommand{\\textgreek}[1]{\\leavevmode{\\greektext #1}}\n
The old implementation overwrites the \textgreek definition from
babel with a custom version adding a re-definition of the \~ macro with
the side-effects for Greek documents described in bug 6458 and shown in
http://www.lyx.org/trac/attachment/ticket/6458/accent-tilde-in-greek-document-minimal.lyx
.
This patch brings the \textgreek definition in line with the version
provided by the 'babel' package.
Instead, the re-definition of the \~ is done
* outside the \textgreek definition, but
* local to the LGR font encoding,
so other alphabets are not affected:
- \\DeclareFontEncoding{LGR}{}{}\n);
+ \\DeclareFontEncoding{LGR}{}{}\n
+ \\DeclareTextSymbol{\\~}{LGR}{126});
Both, the current implementation and the proposed patch
* support Greek unicode characters via the definitions in unicodesymbols
independent of the document and/or text language.
* overwrite the \~ (tilde text accent) LaTeX macro so that placing a
tilde (perispomeni) accent on Greek characters is only possible for the
characters which in Greek orthography take such an accent. For other
characters the tilde is placed in front of the character.
This is the price we have to pay for the support of proper typesetting
of the multi-accented characters like ἆ (GREEK SMALL LETTER ALPHA WITH
PSILI AND PERISPOMENI).
The patch restricts this re-definition to characters of the Greek
alphabet (as opposed to any character in a Greek document).
As the accent-tilde lfun does not work properly with Greek characters
(except for text in polytonic Greek) anyway (see Bug #6463), this is
a tolerable restriction.
BTW: the right way would be to properly define the \~ text accent
macro for the LGR font encoding as in
http://milde.users.sourceforge.net/lgrenc-accents.def
.
Günter
Re: LyX 1.6.6: please prepare for landing
Guenter Milde wrote: Please apply the following patches to fix/clean up the Greek language support: I prefer to apply all those changes to trunk first, let them be tested carefully, and then backport to branch. In any case, this is too late for 1.6.6. Sorry. Jürgen
SVN to Git migration
On 04/01/2010 02:02 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: If you mean create a project for it with one or more users with pushing rigth, yes. If you mean svn2git migration, no. yes i meant the migration ;) I stumbled accross that, maybe it can help: http://blog.hartwork.org/?p=763 Abdel
Re: alpha2
Stephan Witt wrote: This patch is tested on Mac OS X 10.6.3 and OpenSuSE 11.2. It's unfinished now, as it doesn't include the aspell build script. This one I want to integrate somehow in development/LyX-Mac-binary-release.sh. But the changes to LyX code base are complete. here it compiles too, put it in. pavel
Re: r34095 - lyx-devel/trunk/src
for...@lyx.org wrote: Author: forenr Date: Thu Apr 8 22:22:20 2010 New Revision: 34095 URL: http://www.lyx.org/trac/changeset/34095 Log: Use cheaper conversion method. Modified: lyx-devel/trunk/src/Buffer.cpp Modified: lyx-devel/trunk/src/Buffer.cpp == --- lyx-devel/trunk/src/Buffer.cppThu Apr 8 16:35:25 2010(r34094) +++ lyx-devel/trunk/src/Buffer.cppThu Apr 8 22:22:20 2010(r34095) @@ -673,10 +673,10 @@ params().isfontcolor = false; params().notefontcolor = lyx::rgbFromHexName(#cc); lyx::dispatch(FuncRequest(LFUN_SET_COLOR, - from_utf8(greyedouttext #cc))); + from_ascii(greyedouttext #cc))); params().boxbgcolor = lyx::rgbFromHexName(#ff); lyx::dispatch(FuncRequest(LFUN_SET_COLOR, - from_utf8(shaded #ff))); + from_ascii(shaded #ff))); i know nothing about the issue but dispatch inside Buffer::readHeader looks like dirty hack. pavel
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller wrote: Guenter Milde wrote: Please apply the following patches to fix/clean up the Greek language support: I prefer to apply all those changes to trunk first, let them be tested you are probably the one to commit it? pavel
Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes
Uwe Stöhr wrote: i was proposing to have it coded _internally_ which means that nothing changes from the point of the stdinstes files or gui names. only the functions for reading and writing would need more code to add/strip the filename part. OK. Can you please give me a hint in what routine I would have to do the stripping? probably on the place where lexer reads and write the info from/to the file? then some parsing of this color info needs to be done before or inside the painting routines. it maybe calls for independent class BufferColor which knows all this parsing stuf and is able to return plain color codes... pavel
Re: r34095 - lyx-devel/trunk/src
On 04/08/2010 04:25 PM, Pavel Sanda wrote: for...@lyx.org wrote: Author: forenr Date: Thu Apr 8 22:22:20 2010 New Revision: 34095 URL: http://www.lyx.org/trac/changeset/34095 Log: Use cheaper conversion method. Modified: lyx-devel/trunk/src/Buffer.cpp Modified: lyx-devel/trunk/src/Buffer.cpp == --- lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 16:35:25 2010(r34094) +++ lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 22:22:20 2010(r34095) @@ -673,10 +673,10 @@ params().isfontcolor = false; params().notefontcolor = lyx::rgbFromHexName(#cc); lyx::dispatch(FuncRequest(LFUN_SET_COLOR, - from_utf8(greyedouttext #cc))); + from_ascii(greyedouttext #cc))); params().boxbgcolor = lyx::rgbFromHexName(#ff); lyx::dispatch(FuncRequest(LFUN_SET_COLOR, - from_utf8(shaded #ff))); + from_ascii(shaded #ff))); i know nothing about the issue but dispatch inside Buffer::readHeader looks like dirty hack. Indeed, that looks dangerous. This should probably be done after the document has been read. Can someone explain why we need this dispatch here? rh
Re: r34095 - lyx-devel/trunk/src
Richard Heck wrote: On 04/08/2010 04:25 PM, Pavel Sanda wrote: for...@lyx.org wrote: Author: forenr Date: Thu Apr 8 22:22:20 2010 New Revision: 34095 URL: http://www.lyx.org/trac/changeset/34095 Log: Use cheaper conversion method. Modified: lyx-devel/trunk/src/Buffer.cpp Modified: lyx-devel/trunk/src/Buffer.cpp == --- lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 16:35:25 2010(r34094) +++ lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 22:22:20 2010(r34095) @@ -673,10 +673,10 @@ params().isfontcolor = false; params().notefontcolor = lyx::rgbFromHexName(#cc); lyx::dispatch(FuncRequest(LFUN_SET_COLOR, - from_utf8(greyedouttext #cc))); + from_ascii(greyedouttext #cc))); params().boxbgcolor = lyx::rgbFromHexName(#ff); lyx::dispatch(FuncRequest(LFUN_SET_COLOR, - from_utf8(shaded #ff))); + from_ascii(shaded #ff))); i know nothing about the issue but dispatch inside Buffer::readHeader looks like dirty hack. Indeed, that looks dangerous. This should probably be done after the document has been read. Can someone explain why we need this dispatch here? i guess you are asking for r34086 pavel
Re: Compilation warnings in branch
Uwe Stöhr wrote: > This is already fixed in trunk, Jürgen, OK to go to branch too? Yes. Although this warning is harmless. Jürgen
Re: r34002 - lyx-devel/trunk
On 04/06/2010 05:42 PM, Vincent van Ravesteijn - TNW wrote: no i see in unpatched sources : New in 1.10.1: - "make dist" can now create lzma-compressed tarballs. so my proposal is lo use lzma from dependency and compression ratio reasons. OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate releases. So you should require 1.10.1. Maybe, I don't understand this well enough, but anyway, why do we require automake 1.10.1 for everyone ? Even for people not using make dist or the tarball at all. Who does use "make dist" by the way ? Is it only Pavel, or do other people do this as well ? For me, requiring this means that I can no longer compile on Linux as I don't have the appropriate rights there to update automake. You can still use cmake, aren't you? Abdel.
Re: Cmake compilation error
On 04/07/2010 06:19 PM, Kornel Benko wrote: Am Mittwoch 07 April 2010 schrieb José Matos: On Wednesday 07 April 2010 15:23:18 Kornel Benko wrote: Corrected and commited already. Sorry for not being responsive, but I broke my right arm, and it is somehow not easy to use a computer. Kornel I hope you have a fast recovery. :-) FWIW there is no need to reply. :-) Best regards, Thanks to all. It is now 8 days from the surgery, things are getting better. Courage Kornel! Abdel.
Re: LyX 1.6.6: please prepare for landing
Jean-Pierre Chrétien wrote:
> Jürgen Spitzmüller a écrit :
> > Jean-Pierre Chrétien wrote:
> >> What about bug #6608 ? Could the patch I suggested be applied ?
> >
> > trac is down, but if I remember correctly, this was the French/prettyref
> > issue, right? I think this is too late for 1.6.6, we have to look into
> > that more deeply first.
>
> No, this one is about the varioref problem (prettyref and varioref
> issues are different, so I split up bug #6420 in bugs #6608 and #6609).
I see.
> > IIRC you propose to load an extra package. I'm not sure about that. For
> > me, the following preamble code fixes the problem as well:
> >
> > \let\oldlabel\label
> > \renewcommand*{\label}{\catcode`\:=12 \oldlabel}
> > \let\oldpref\prettyref
> > \renewcommand*{\prettyref}{\catcode`\:=12 \oldpref}
> >
> > But it's tedious to change catcodes like that. OTOH I don't know what the
> > package you propose does.
>
> Just loading nameref (a companion package of hyperref) before varioref,
> which can only be done by changing the lyX source in
> ./src/LaTeXFeatures.cpp
> ./src/insets/InsetRef.cpp
> ./src/mathed/InsetMathRef.cpp
>
> This bug is discussed in
> http://www.tug.org/pipermail/texhax/2005-September/004707.html
> and in the README file of hyperref (section about varioref):
> http://tug.ctan.org/tex-archive/macros/latex/contrib/hyperref/
>
> The point here is that nameref can be loaded without hyperref,
> I've added the patch to bug #6608 (patch against the current branch).
But the README text is not very encouraging:
There are too many problems with varioref. Nobody has time to
sort them out. Therefore this package is now unsupported.
Perhaps you are lucky and some of the features of varioref works
with the following loading order:
\usepackage{nameref}
\usepackage{varioref}
\usepackage{hyperref}
In any case, I'm reluctant to load such a complex package just because it
fixes varioref/French ("if we are lucky"). That is to say: I'm fine to use the
above order if hyperref is used, but without hyperref, I would rather welcome
a simpler, standalone solution.
Also, the problem is supposed to be fixed within babel itself (see the babel
docs, sec. 12.18.2). Babel does the same trick than nameref here (deactivating
actice chars within \vref and \vpageref). The strange thing is: if I export
your test file and compile it manually with pdflatex, no error occurs. The
error only shows up when compiling with LyX. I'd like to know why the babel
fix does not trigger when compiling with LyX.
> As far as prettyref is concerned (bug #6609), the best would be to
> remove this package, as it was already proposed in bug #2295 because of
> the lack of internationalization.
This is no option for branch. We cannot drop prettyref in branch, this is a
file format change. For the same reason, we cannot add support for refstyle.
> >> I the same line, I submitted an example file for crossrefs
> >> http://article.gmane.org/gmane.editors.lyx.devel/126589
> >> and I got no comments about it. Should it have been posted to lyx-docs ?
> >
> > This is for trunk only. I guess Richard has an eye on it.
>
> No, this one is for branch, the idea was to have one file for branch, to
> check lyx2lyx translation to lyx-2.0 format.
> I made it as exhaustive as possible to discuss possible improvements of
> the lyx implementation of varioref/refstyle (ranges, lists,
> capitalization, plurals, etc.)
> As Richard's patch for refstyle needs some tuning, I did not turn it in
> a file for lyx-2.0 yet.
>
> Maybe some of your prettyref constructs for German language should be
> added to file examples_crossrefs_lyx16.lyx,
> to check conservativeness of the refstyle implementation.
But still, this case concerns trunk, not branch. In branch, we cannot do
anything wih refstyle.
Jürgen
Re: r34081 - lyx-devel/trunk/src
On 04/07/2010 07:02 PM, rgh...@lyx.org wrote: Author: rgheck Date: Wed Apr 7 19:02:44 2010 New Revision: 34081 URL: http://www.lyx.org/trac/changeset/34081 Log: Grant a long-standing wish of Lars's: LyX now functions even if we have no text classes for some reason (e.g., a corrupt textclass.lst). We still give the user a chance to reconfigure (Bo's idea). I wonder if we still really need to "restart LyX to make use of any updated document class specifications". What would happen if we just reloaded? In any case we should try to not require a complete restart. Abdel.
RE: r34002 - lyx-devel/trunk
>> >> For me, requiring this means that I can no longer compile on Linux as >> I don't have the appropriate rights there to update automake. >> > >You can still use cmake, aren't you? > >Abdel. > Yes. Vincent
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller wrote: > Also, the problem is supposed to be fixed within babel itself (see the > babel docs, sec. 12.18.2). Babel does the same trick than nameref here > (deactivating actice chars within \vref and \vpageref). The strange thing > is: if I export your test file and compile it manually with pdflatex, no > error occurs. The error only shows up when compiling with LyX. I'd like to > know why the babel fix does not trigger when compiling with LyX. The mystery is solved: Kile ran a different LaTeX distribution than LyX. Now I tracked down the problem to varioref itself. The bug does not occur in varioref 1.4p (2006/05/13), but it occurs with the newer varioref 1.4w (2009/09/13). I guess we need to submit a bug report to Frank Mittelbach (I'll do that). Jürgen
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller wrote: > I guess we need to submit a bug report to Frank Mittelbach (I'll do that). The bug has been already reported: http://www.latex-project.org/cgi-bin/ltxbugs2html?pr=latex/4093 Jürgen
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller a écrit :
Jean-Pierre Chrétien wrote:
Jürgen Spitzmüller a écrit :
Jean-Pierre Chrétien wrote:
But the README text is not very encouraging:
There are too many problems with varioref. Nobody has time to
sort them out. Therefore this package is now unsupported.
Sure, I read that, but for years the same remark could have been applied
to hyperref, and lyx managed to work with it.
In any case, I'm reluctant to load such a complex package just because it
fixes varioref/French ("if we are lucky"). That is to say: I'm fine to use the
above order if hyperref is used, but without hyperref, I would rather welcome
a simpler, standalone solution.
If you check the "Use hyperref" box in Document>Settings>PDF all is
right (by the way, all is right also for the French versions of
UserGuide and Embedded Objects, which raised problems in the past with
earlier versions of TexLive).
Also, the problem is supposed to be fixed within babel itself (see the babel
docs, sec. 12.18.2). Babel does the same trick than nameref here (deactivating
actice chars within \vref and \vpageref). The strange thing is: if I export
your test file and compile it manually with pdflatex, no error occurs. The
error only shows up when compiling with LyX. I'd like to know why the babel
fix does not trigger when compiling with LyX.
I do not have such a result here, the logs files are alike (but for a
few changes on line numbering). I have texlive-2009 (no dynamic
updates). And the .tex files differ only by what is found in /tmp and
downwards.
--- erreur_varioref_lyx16.tex 2010-04-08 10:34:08.0 +0200
+++ /tmp/lyx_tmpdir.TJ3978/lyx_tmpbuf1/erreur_varioref_lyx16.tex
2010-04-08 10:45:06.0 +0200
@@ -1,5 +1,7 @@
-%% LyX 1.6.5 created this file. For more info, see http://www.lyx.org/.
-%% Do not edit unless you really know what you are doing.
+\batchmode
+\makeatletter
+\def\in...@path{{/tmp//}}
+\makeatother
\documentclass[french]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
With my conf. here, what is said in the babel doc is clearly not effective
(and the traffic on lyx-fr shows I'm not alone there).
So a solution would be to edit the docs where varioref is documented
and suggest to check the hyperref box, or deactivate locally : by
using \shorthandoff{:}{...} in ERT.
Another option would be to offer to the user an interface to insert
commands at the beginning of the preamble, so that
\usepackage{nameref}
could be added at the right location without LyX code change.
This has been already proposed as a general enhancement (ticket #5366).
As far as prettyref is concerned (bug #6609), the best would be to
remove this package, as it was already proposed in bug #2295 because of
the lack of internationalization.
This is no option for branch. We cannot drop prettyref in branch, this is a
file format change. For the same reason, we cannot add support for refstyle.
Sure, I was referring to the recent threads about refstyle
implementation in trunk.
--
Jean-Pierre
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller a écrit : Jürgen Spitzmüller wrote: Also, the problem is supposed to be fixed within babel itself (see the babel docs, sec. 12.18.2). Babel does the same trick than nameref here (deactivating actice chars within \vref and \vpageref). The strange thing is: if I export your test file and compile it manually with pdflatex, no error occurs. The error only shows up when compiling with LyX. I'd like to know why the babel fix does not trigger when compiling with LyX. The mystery is solved: Kile ran a different LaTeX distribution than LyX. Now I tracked down the problem to varioref itself. The bug does not occur in varioref 1.4p (2006/05/13), but it occurs with the newer varioref 1.4w (2009/09/13). I guess that explains why the behaviour with or without hyperref active was reversed with TexLive 2007 (standard in Debian Lenny). I just cheked with the test file and after hiding the local texlive2009: works without hyperref, fails with hyperref active. Thanks for digging this out. -- Jean-Pierre
Re: LyX 1.6.6: please prepare for landing
On 2010-04-05, Jürgen Spitzmüller wrote:
> Translation updates and patches should be submitted *no later* than Friday,
> April 23.
Please apply the following patches to fix/clean up the Greek language
support:
http://www.lyx.org/trac/attachment/ticket/6456/languages-polutonikogreek-branch.patch
to fix bug http://www.lyx.org/trac/ticket/6456.
http://www.lyx.org/trac/attachment/ticket/6458/LaTeXFeatures-greektext.patch
to fix bug http://www.lyx.org/trac/ticket/6458
Some comments to the second patch:
static docstring const textgreek_def = from_ascii(
- "\\providecommand*{\\perispomeni}{\\char126}\n"
- "\\AtBeginDocument{\\DeclareRobustCommand{\\greektext}{%\n"
- " \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}\n"
- " \\renewcommand{\\~}{\\perispomeni}\n"
- "}}\n"
+ "\\DeclareRobustCommand{\\greektext}{%\n"
+ " \\fontencoding{LGR}\\selectfont\\def\\encodingdefault{LGR}}\n"
"\\DeclareRobustCommand{\\textgreek}[1]{\\leavevmode{\\greektext #1}}\n"
The old implementation overwrites the \textgreek definition from
babel with a custom version adding a re-definition of the \~ macro with
the side-effects for Greek documents described in bug 6458 and shown in
http://www.lyx.org/trac/attachment/ticket/6458/accent-tilde-in-greek-document-minimal.lyx
.
This patch brings the \textgreek definition in line with the version
provided by the 'babel' package.
Instead, the re-definition of the \~ is done
* outside the \textgreek definition, but
* local to the LGR font encoding,
so other alphabets are not affected:
- "\\DeclareFontEncoding{LGR}{}{}\n");
+ "\\DeclareFontEncoding{LGR}{}{}\n"
+ "\\DeclareTextSymbol{\\~}{LGR}{126}");
Both, the current implementation and the proposed patch
* support Greek unicode characters via the definitions in unicodesymbols
independent of the document and/or text language.
* overwrite the \~ (tilde text accent) LaTeX macro so that placing a
tilde (perispomeni) accent on Greek characters is only possible for the
characters which in Greek orthography take such an accent. For other
characters the tilde is placed in front of the character.
This is the price we have to pay for the support of proper typesetting
of the multi-accented characters like ἆ (GREEK SMALL LETTER ALPHA WITH
PSILI AND PERISPOMENI).
The patch restricts this re-definition to characters of the Greek
alphabet (as opposed to any character in a Greek document).
As the accent-tilde lfun does not work properly with Greek characters
(except for text in polytonic Greek) anyway (see Bug #6463), this is
a tolerable restriction.
BTW: the "right way" would be to properly define the \~ text accent
macro for the LGR font encoding as in
http://milde.users.sourceforge.net/lgrenc-accents.def
.
Günter
Re: LyX 1.6.6: please prepare for landing
Guenter Milde wrote: > Please apply the following patches to fix/clean up the Greek language > support: I prefer to apply all those changes to trunk first, let them be tested carefully, and then backport to branch. In any case, this is too late for 1.6.6. Sorry. Jürgen
SVN to Git migration
On 04/01/2010 02:02 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: If you mean create a project for it with one or more users with pushing rigth, yes. If you mean svn2git migration, no. yes i meant the migration ;) I stumbled accross that, maybe it can help: http://blog.hartwork.org/?p=763 Abdel
Re: alpha2
Stephan Witt wrote: > This patch is tested on Mac OS X 10.6.3 and OpenSuSE 11.2. > > It's unfinished now, as it doesn't include the aspell build script. > This one I want to integrate somehow in > "development/LyX-Mac-binary-release.sh". > But the changes to LyX code base are complete. here it compiles too, put it in. pavel
Re: r34095 - lyx-devel/trunk/src
for...@lyx.org wrote:
> Author: forenr
> Date: Thu Apr 8 22:22:20 2010
> New Revision: 34095
> URL: http://www.lyx.org/trac/changeset/34095
>
> Log:
> Use cheaper conversion method.
>
> Modified:
>lyx-devel/trunk/src/Buffer.cpp
>
> Modified: lyx-devel/trunk/src/Buffer.cpp
> ==
> --- lyx-devel/trunk/src/Buffer.cppThu Apr 8 16:35:25 2010(r34094)
> +++ lyx-devel/trunk/src/Buffer.cppThu Apr 8 22:22:20 2010(r34095)
> @@ -673,10 +673,10 @@
> params().isfontcolor = false;
> params().notefontcolor = lyx::rgbFromHexName("#cc");
> lyx::dispatch(FuncRequest(LFUN_SET_COLOR,
> - from_utf8("greyedouttext #cc")));
> + from_ascii("greyedouttext #cc")));
> params().boxbgcolor = lyx::rgbFromHexName("#ff");
> lyx::dispatch(FuncRequest(LFUN_SET_COLOR,
> - from_utf8("shaded #ff")));
> + from_ascii("shaded #ff")));
i know nothing about the issue but dispatch inside Buffer::readHeader looks
like dirty hack.
pavel
Re: LyX 1.6.6: please prepare for landing
Jürgen Spitzmüller wrote: > Guenter Milde wrote: > > Please apply the following patches to fix/clean up the Greek language > > support: > > I prefer to apply all those changes to trunk first, let them be tested you are probably the one to commit it? pavel
Re: document dependent color handling - was: [patch] support to change the background color of shaded boxes
Uwe Stöhr wrote: > > i was proposing to have it coded _internally_ which means that nothing > > changes from the point of the stdinstes files or gui names. only the > > functions for reading and writing would need more code to add/strip > > the filename part. > > OK. > Can you please give me a hint in what routine I would have to do the > stripping? probably on the place where lexer reads and write the info from/to the file? then some parsing of this color info needs to be done before or inside the painting routines. it maybe calls for independent class BufferColor which knows all this parsing stuf and is able to return plain color codes... pavel
Re: r34095 - lyx-devel/trunk/src
On 04/08/2010 04:25 PM, Pavel Sanda wrote:
for...@lyx.org wrote:
Author: forenr
Date: Thu Apr 8 22:22:20 2010
New Revision: 34095
URL: http://www.lyx.org/trac/changeset/34095
Log:
Use cheaper conversion method.
Modified:
lyx-devel/trunk/src/Buffer.cpp
Modified: lyx-devel/trunk/src/Buffer.cpp
==
--- lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 16:35:25 2010(r34094)
+++ lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 22:22:20 2010(r34095)
@@ -673,10 +673,10 @@
params().isfontcolor = false;
params().notefontcolor = lyx::rgbFromHexName("#cc");
lyx::dispatch(FuncRequest(LFUN_SET_COLOR,
- from_utf8("greyedouttext #cc")));
+ from_ascii("greyedouttext #cc")));
params().boxbgcolor = lyx::rgbFromHexName("#ff");
lyx::dispatch(FuncRequest(LFUN_SET_COLOR,
- from_utf8("shaded #ff")));
+ from_ascii("shaded #ff")));
i know nothing about the issue but dispatch inside Buffer::readHeader looks
like dirty hack.
Indeed, that looks dangerous. This should probably be done after the
document has been read.
Can someone explain why we need this dispatch here?
rh
Re: r34095 - lyx-devel/trunk/src
Richard Heck wrote:
> On 04/08/2010 04:25 PM, Pavel Sanda wrote:
>> for...@lyx.org wrote:
>>
>>> Author: forenr
>>> Date: Thu Apr 8 22:22:20 2010
>>> New Revision: 34095
>>> URL: http://www.lyx.org/trac/changeset/34095
>>>
>>> Log:
>>> Use cheaper conversion method.
>>>
>>> Modified:
>>> lyx-devel/trunk/src/Buffer.cpp
>>>
>>> Modified: lyx-devel/trunk/src/Buffer.cpp
>>> ==
>>> --- lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 16:35:25 2010(r34094)
>>> +++ lyx-devel/trunk/src/Buffer.cpp Thu Apr 8 22:22:20 2010(r34095)
>>> @@ -673,10 +673,10 @@
>>> params().isfontcolor = false;
>>> params().notefontcolor = lyx::rgbFromHexName("#cc");
>>> lyx::dispatch(FuncRequest(LFUN_SET_COLOR,
>>> - from_utf8("greyedouttext #cc")));
>>> + from_ascii("greyedouttext #cc")));
>>> params().boxbgcolor = lyx::rgbFromHexName("#ff");
>>> lyx::dispatch(FuncRequest(LFUN_SET_COLOR,
>>> - from_utf8("shaded #ff")));
>>> + from_ascii("shaded #ff")));
>>>
>> i know nothing about the issue but dispatch inside Buffer::readHeader
>> looks
>> like dirty hack.
>>
>>
> Indeed, that looks dangerous. This should probably be done after the
> document has been read.
>
> Can someone explain why we need this dispatch here?
i guess you are asking for r34086
pavel
