Re: Language change within Flex inset exports wrong babel construct
Jürgen Spitzmüller spitz at 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
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-10, Jürgen Spitzmüller wrote:
[-- Type: text/plain, Encoding: quoted-printable --]
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.
Could we call the new bool mask_newline or escape_newline, please?
This seems better to reflect its function (prevent unwanted whitespace):
...
+++ src/output_latex.cpp (Arbeitskopie)
...
bool pending_newline = false;
+ bool unskip_newline = false;
...
- if (pending_newline)
+ if (pending_newline) {
+ if (unskip_newline)
+ // prevent unwanted whitespace
+ os '%';
os '\n';
+ }
Thanks,
Günter
Re: Language change within Flex inset exports wrong babel construct
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
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-10, Jürgen Spitzmüller wrote:
> [-- Type: text/plain, Encoding: quoted-printable --]
> 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.
Could we call the new bool "mask_newline" or "escape_newline", please?
This seems better to reflect its function (prevent unwanted whitespace):
...
> +++ src/output_latex.cpp (Arbeitskopie)
...
> bool pending_newline = false;
> + bool unskip_newline = false;
...
> - if (pending_newline)
> + if (pending_newline) {
> + if (unskip_newline)
> + // prevent unwanted whitespace
> + os << '%';
> os << '\n';
> + }
Thanks,
Günter
Re: Language change within Flex inset exports wrong babel construct
Guenter Milde milde at 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
On 2011-06-09, Jean-Pierre Chrétien wrote:
Guenter Milde milde at 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 ?
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.)
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?)
Günter
Re: Language change within Flex inset exports wrong babel construct
Guenter Milde milde at 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
On 2011-06-09, Jean-Pierre Chrétien wrote: Guenter Milde milde at users.berlios.de writes: 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. I still have a lyx-svn version without the languages patch: the example showed spurious space in Initial and Correction 1. Exporting to LaTeX and fixing the extrasfrench definition, the spurious space in Correction 1 vanished -- i.e. Correction 1 is correct. 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 ? Of course the one that leads to the un-escaped line-break before the closing } of the code inset ;-) Unfortunately, I am not familiar with the code and cannot tell you which is it. Günter
Re: Language change within Flex inset exports wrong babel construct
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.
Jürgen
Index: src/output_latex.cpp
===
--- src/output_latex.cpp (Revision 38989)
+++ src/output_latex.cpp (Arbeitskopie)
@@ -720,6 +720,7 @@
}
bool pending_newline = false;
+ bool unskip_newline = false;
switch (style.latextype) {
case LATEX_ITEM_ENVIRONMENT:
case LATEX_LIST_ENVIRONMENT:
@@ -793,6 +794,7 @@
$$lang,
current_lang));
pending_newline = true;
+ unskip_newline = true;
}
} else if (!par_lang.empty()) {
os from_ascii(subst(
@@ -800,14 +802,19 @@
$$lang,
par_lang));
pending_newline = true;
+unskip_newline = true;
}
}
}
if (closing_rtl_ltr_environment)
os };
- if (pending_newline)
+ if (pending_newline) {
+ if (unskip_newline)
+ // prevent unwanted whitespace
+ os '%';
os '\n';
+ }
// if this is a CJK-paragraph and the next isn't, close CJK
// also if the next paragraph is a multilingual environment (because of nesting)
Re: Language change within Flex inset exports wrong babel construct
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
On 2011-06-09, Jean-Pierre Chrétien wrote:
> 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 ?
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.)
> 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"?)
Günter
Re: Language change within Flex inset exports wrong babel construct
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
On 2011-06-09, Jean-Pierre Chrétien wrote: > Guenter Milde users.berlios.de> writes: > 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. I still have a lyx-svn version without the languages patch: the example showed spurious space in Initial and Correction 1. Exporting to LaTeX and fixing the extrasfrench definition, the spurious space in Correction 1 vanished -- i.e. Correction 1 is correct. > 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 ? Of course the one that leads to the un-escaped line-break before the closing } of the code inset ;-) Unfortunately, I am not familiar with the code and cannot tell you which is it. Günter
Re: Language change within Flex inset exports wrong babel construct
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.
Jürgen
Index: src/output_latex.cpp
===
--- src/output_latex.cpp (Revision 38989)
+++ src/output_latex.cpp (Arbeitskopie)
@@ -720,6 +720,7 @@
}
bool pending_newline = false;
+ bool unskip_newline = false;
switch (style.latextype) {
case LATEX_ITEM_ENVIRONMENT:
case LATEX_LIST_ENVIRONMENT:
@@ -793,6 +794,7 @@
"$$lang",
current_lang));
pending_newline = true;
+ unskip_newline = true;
}
} else if (!par_lang.empty()) {
os << from_ascii(subst(
@@ -800,14 +802,19 @@
"$$lang",
par_lang));
pending_newline = true;
+unskip_newline = true;
}
}
}
if (closing_rtl_ltr_environment)
os << "}";
- if (pending_newline)
+ if (pending_newline) {
+ if (unskip_newline)
+ // prevent unwanted whitespace
+ os << '%';
os << '\n';
+ }
// if this is a CJK-paragraph and the next isn't, close CJK
// also if the next paragraph is a multilingual environment (because of nesting)
Re: Language change within Flex inset exports wrong babel construct
Guenter Milde wrote:
This white space disappears by properly escaping
the line breaks in \addto\extrasfrench{...}.
So I hope it is easily fixed for 2.1 (or 2.0.1).
Sure. Just add the % to languages and be done with it.
There are still other whitespace issues, though, with language changes at the
beginning of quotations and macros. These were already present in 1.6.
Jürgen
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-06, Jürgen Spitzmüller wrote:
Guenter Milde wrote:
This white space disappears by properly escaping
the line breaks in \addto\extrasfrench{...}.
So I hope it is easily fixed for 2.1 (or 2.0.1).
Sure. Just add the % to languages and be done with it.
Here is the patch for lib/languages:
@@ -360,8 +360,8 @@ Language french
LangCode fr_FR
PostBabelPreamble
\addto\extrasfrench{%
- \providecommand{\og}{\leavevmode\flqq~}
- \providecommand{\fg}{\ifdim\lastskip\z@\unskip\fi~\frqq}
+ \providecommand{\og}{\leavevmode\flqq~}%
+ \providecommand{\fg}{\ifdim\lastskip\z@\unskip\fi~\frqq}%
}
EndPostBabelPreamble
End
Please apply to 2.0 and devel.
There are still other whitespace issues, though, with language changes
at the beginning of quotations and macros. These were already present
in 1.6.
Could you be more specific? I could not find more missing line-break
escapes in lib/languages, but there might be more somewhere in the C code.
Thanks,
Günter
Re: Language change within Flex inset exports wrong babel construct
On 06/06/2011 07:45 AM, Guenter Milde wrote:
On 2011-06-06, Jürgen Spitzmüller wrote:
Guenter Milde wrote:
This white space disappears by properly escaping
the line breaks in \addto\extrasfrench{...}.
So I hope it is easily fixed for 2.1 (or 2.0.1).
Sure. Just add the % to languages and be done with it.
Here is the patch for lib/languages:
@@ -360,8 +360,8 @@ Language french
LangCode fr_FR
PostBabelPreamble
\addto\extrasfrench{%
-\providecommand{\og}{\leavevmode\flqq~}
-\providecommand{\fg}{\ifdim\lastskip\z@\unskip\fi~\frqq}
+\providecommand{\og}{\leavevmode\flqq~}%
+\providecommand{\fg}{\ifdim\lastskip\z@\unskip\fi~\frqq}%
}
EndPostBabelPreamble
End
Please apply to 2.0 and devel.
Done, thank you.
rh
Re: Language change within Flex inset exports wrong babel construct
Guenter Milde wrote: Could you be more specific? I could not find more missing line-break escapes in lib/languages, but there might be more somewhere in the C code. I'll try to make a test case when I find time (too busy currently). The issue often arises when I use a foreign language for a complete quote or a heading. This gives vertical or horizontal unwanted whitespace. Adding an empty ERT works around this. Jürgen
Re: Language change within Flex inset exports wrong babel construct
Guenter Milde wrote:
> > This white space disappears by properly escaping
> > the line breaks in \addto\extrasfrench{...}.
>
> So I hope it is easily fixed for 2.1 (or 2.0.1).
Sure. Just add the % to languages and be done with it.
There are still other whitespace issues, though, with language changes at the
beginning of quotations and macros. These were already present in 1.6.
Jürgen
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-06, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> > This white space disappears by properly escaping
>> > the line breaks in \addto\extrasfrench{...}.
>> So I hope it is easily fixed for 2.1 (or 2.0.1).
> Sure. Just add the % to languages and be done with it.
Here is the patch for lib/languages:
@@ -360,8 +360,8 @@ Language french
LangCode fr_FR
PostBabelPreamble
\addto\extrasfrench{%
- \providecommand{\og}{\leavevmode\flqq~}
- \providecommand{\fg}{\ifdim\lastskip>\z@\unskip\fi~\frqq}
+ \providecommand{\og}{\leavevmode\flqq~}%
+ \providecommand{\fg}{\ifdim\lastskip>\z@\unskip\fi~\frqq}%
}
EndPostBabelPreamble
End
Please apply to 2.0 and devel.
> There are still other whitespace issues, though, with language changes
> at the beginning of quotations and macros. These were already present
> in 1.6.
Could you be more specific? I could not find more missing line-break
escapes in lib/languages, but there might be more somewhere in the C code.
Thanks,
Günter
Re: Language change within Flex inset exports wrong babel construct
On 06/06/2011 07:45 AM, Guenter Milde wrote:
> On 2011-06-06, Jürgen Spitzmüller wrote:
>> Guenter Milde wrote:
This white space disappears by properly escaping
the line breaks in \addto\extrasfrench{...}.
>>> So I hope it is easily fixed for 2.1 (or 2.0.1).
>> Sure. Just add the % to languages and be done with it.
> Here is the patch for lib/languages:
>
> @@ -360,8 +360,8 @@ Language french
> LangCode fr_FR
> PostBabelPreamble
> \addto\extrasfrench{%
> -\providecommand{\og}{\leavevmode\flqq~}
> -\providecommand{\fg}{\ifdim\lastskip>\z@\unskip\fi~\frqq}
> +\providecommand{\og}{\leavevmode\flqq~}%
> +\providecommand{\fg}{\ifdim\lastskip>\z@\unskip\fi~\frqq}%
> }
> EndPostBabelPreamble
> End
>
> Please apply to 2.0 and devel.
>
Done, thank you.
rh
Re: Language change within Flex inset exports wrong babel construct
Guenter Milde wrote: > Could you be more specific? I could not find more missing line-break > escapes in lib/languages, but there might be more somewhere in the C code. I'll try to make a test case when I find time (too busy currently). The issue often arises when I use a foreign language for a complete quote or a heading. This gives vertical or horizontal unwanted whitespace. Adding an empty ERT works around this. Jürgen
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-02, Jean-Pierre Chrétien wrote:
[-- Type: text/plain, Encoding: 7bit --]
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
...
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.
Günter
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-03, Enrico Forestieri wrote: On Fri, Jun 03, 2011 at 09:47:35AM +0200, Jean-Marc Lasgouttes wrote: Le 03/06/11 02:07, Enrico Forestieri a écrit : See attached patch. I am not sure I understand the patch, but how come one has to decide based on isMainText()? What about a Flex inset in a Note? What would the situation be different? I am not sure I understand the question, either. As \selectlanguage introduces spurious white space, it should not be used in inline content. It does not. Only the incorrect use (with a non-escaped line-break) does. Günter
Re: Language change within Flex inset exports wrong babel construct
On Sun, Jun 05, 2011 at 09:08:11PM +, Guenter Milde wrote:
On 2011-06-03, Enrico Forestieri wrote:
On Fri, Jun 03, 2011 at 09:47:35AM +0200, Jean-Marc Lasgouttes wrote:
Le 03/06/11 02:07, Enrico Forestieri a écrit :
See attached patch.
I am not sure I understand the patch, but how come one has to decide
based on isMainText()? What about a Flex inset in a Note? What would
the situation be different?
I am not sure I understand the question, either.
As \selectlanguage introduces spurious white space, it should not be used
in inline content.
It does not. Only the incorrect use (with a non-escaped line-break)
does.
That is yet another source of white space. However, even escaping the
line break, white space is still added. Further investigation shows that
the problem seems specifically related to the french language and the
\addto\extrasfrench{...} added by LyX to the preamble.
Compiling the attached example, you can see that spurious white space
is added after word. This white space disappears by properly escaping
the line breaks in \addto\extrasfrench{...}.
--
Enrico
babel.tex
Description: TeX document
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-05, Enrico Forestieri wrote:
As \selectlanguage introduces spurious white space, it should not be used
in inline content.
It does not. Only the incorrect use (with a non-escaped line-break)
does.
That is yet another source of white space. However, even escaping the
line break, white space is still added. Further investigation shows that
the problem seems specifically related to the french language and the
\addto\extrasfrench{...} added by LyX to the preamble.
Compiling the attached example, you can see that spurious white space
is added after word.
This is a regression in LyX 2, as in LyX 1.6 the
\addto\extrasfrench{...} line is all in one line.
This white space disappears by properly escaping
the line breaks in \addto\extrasfrench{...}.
So I hope it is easily fixed for 2.1 (or 2.0.1).
Thanks for pointing this out.
Günter
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-02, Jean-Pierre Chrétien wrote:
> [-- Type: text/plain, Encoding: 7bit --]
> 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
...
> 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.
Günter
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-03, Enrico Forestieri wrote: > On Fri, Jun 03, 2011 at 09:47:35AM +0200, Jean-Marc Lasgouttes wrote: >> Le 03/06/11 02:07, Enrico Forestieri a écrit : >> >See attached patch. >> I am not sure I understand the patch, but how come one has to decide >> based on isMainText()? What about a Flex inset in a Note? What would >> the situation be different? > I am not sure I understand the question, either. > As \selectlanguage introduces spurious white space, it should not be used > in "inline" content. It does not. Only the incorrect use (with a non-escaped line-break) does. Günter
Re: Language change within Flex inset exports wrong babel construct
On Sun, Jun 05, 2011 at 09:08:11PM +, Guenter Milde wrote:
> On 2011-06-03, Enrico Forestieri wrote:
> > On Fri, Jun 03, 2011 at 09:47:35AM +0200, Jean-Marc Lasgouttes wrote:
>
> >> Le 03/06/11 02:07, Enrico Forestieri a écrit :
> >> >See attached patch.
>
> >> I am not sure I understand the patch, but how come one has to decide
> >> based on isMainText()? What about a Flex inset in a Note? What would
> >> the situation be different?
>
> > I am not sure I understand the question, either.
>
> > As \selectlanguage introduces spurious white space, it should not be used
> > in "inline" content.
>
> It does not. Only the incorrect use (with a non-escaped line-break)
> does.
That is yet another source of white space. However, even escaping the
line break, white space is still added. Further investigation shows that
the problem seems specifically related to the french language and the
\addto\extrasfrench{...} added by LyX to the preamble.
Compiling the attached example, you can see that spurious white space
is added after "word". This white space disappears by properly escaping
the line breaks in \addto\extrasfrench{...}.
--
Enrico
babel.tex
Description: TeX document
Re: Language change within Flex inset exports wrong babel construct
On 2011-06-05, Enrico Forestieri wrote:
>> > As \selectlanguage introduces spurious white space, it should not be used
>> > in "inline" content.
>> It does not. Only the incorrect use (with a non-escaped line-break)
>> does.
> That is yet another source of white space. However, even escaping the
> line break, white space is still added. Further investigation shows that
> the problem seems specifically related to the french language and the
> \addto\extrasfrench{...} added by LyX to the preamble.
> Compiling the attached example, you can see that spurious white space
> is added after "word".
This is a regression in LyX 2, as in LyX 1.6 the
\addto\extrasfrench{...} line is all in one line.
> This white space disappears by properly escaping
> the line breaks in \addto\extrasfrench{...}.
So I hope it is easily fixed for 2.1 (or 2.0.1).
Thanks for pointing this out.
Günter
Re: Language change within Flex inset exports wrong babel construct
Le 03/06/11 02:07, Enrico Forestieri a écrit : See attached patch. I am not sure I understand the patch, but how come one has to decide based on isMainText()? What about a Flex inset in a Note? What would the situation be different? JMarc
Re: Language change within Flex inset exports wrong babel construct
Enrico Forestieri forenr at 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
Jean-Marc Lasgouttes wrote: See attached patch. I am not sure I understand the patch, but how come one has to decide based on isMainText()? What about a Flex inset in a Note? What would the situation be different? I am not sure either. I often face such problems for environments (quotations, lists) or macros (sections) which are in a foreign language, i.e. where isMainText() is true. I have got into the habit to insert an empty ERT (in the main laguage) at every such paragraph meanwhile. Jürgen
Re: Language change within Flex inset exports wrong babel construct
On Fri, Jun 03, 2011 at 09:47:35AM +0200, Jean-Marc Lasgouttes wrote: Le 03/06/11 02:07, Enrico Forestieri a écrit : See attached patch. I am not sure I understand the patch, but how come one has to decide based on isMainText()? What about a Flex inset in a Note? What would the situation be different? I am not sure I understand the question, either. As \selectlanguage introduces spurious white space, it should not be used in inline content. As \selectlanguage is only used when the language is changed at the very beginning of a LyX paragraph, checking isMainText() ensures that it is used only at the beginning of a LaTeX paragraph, such that the spurious white space added at the end is not harmful. -- Enrico
Re: Language change within Flex inset exports wrong babel construct
Le 03/06/11 14:26, Enrico Forestieri a écrit : As \selectlanguage introduces spurious white space, it should not be used in inline content. As \selectlanguage is only used when the language is changed at the very beginning of a LyX paragraph, checking isMainText() ensures that it is used only at the beginning of a LaTeX paragraph, such that the spurious white space added at the end is not harmful. How well does that work when the flex inset is in a branch, for example? Can the otexstream be queried to know whether we are at the start of a LaTeX paragraph? JMarc
Re: Language change within Flex inset exports wrong babel construct
On Fri, Jun 03, 2011 at 02:32:16PM +0200, Jean-Marc Lasgouttes wrote: Le 03/06/11 14:26, Enrico Forestieri a écrit : As \selectlanguage introduces spurious white space, it should not be used in inline content. As \selectlanguage is only used when the language is changed at the very beginning of a LyX paragraph, checking isMainText() ensures that it is used only at the beginning of a LaTeX paragraph, such that the spurious white space added at the end is not harmful. How well does that work when the flex inset is in a branch, for example? Very well, apparently. Can the otexstream be queried to know whether we are at the start of a LaTeX paragraph? No, you can only know whether we are at the start of a new line. I start to think that you don't realize that this only matters at export time, though. -- Enrico
Re: Language change within Flex inset exports wrong babel construct
Le 03/06/11 02:07, Enrico Forestieri a écrit : See attached patch. I am not sure I understand the patch, but how come one has to decide based on isMainText()? What about a Flex inset in a Note? What would the situation be different? JMarc
Re: Language change within Flex inset exports wrong babel construct
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
Jean-Marc Lasgouttes wrote: > > See attached patch. > > I am not sure I understand the patch, but how come one has to decide > based on isMainText()? What about a Flex inset in a Note? What would the > situation be different? I am not sure either. I often face such problems for environments (quotations, lists) or macros (sections) which are in a foreign language, i.e. where isMainText() is true. I have got into the habit to insert an empty ERT (in the main laguage) at every such paragraph meanwhile. Jürgen
Re: Language change within Flex inset exports wrong babel construct
On Fri, Jun 03, 2011 at 09:47:35AM +0200, Jean-Marc Lasgouttes wrote: > Le 03/06/11 02:07, Enrico Forestieri a écrit : > >See attached patch. > > I am not sure I understand the patch, but how come one has to decide > based on isMainText()? What about a Flex inset in a Note? What would > the situation be different? I am not sure I understand the question, either. As \selectlanguage introduces spurious white space, it should not be used in "inline" content. As \selectlanguage is only used when the language is changed at the very beginning of a LyX paragraph, checking isMainText() ensures that it is used only at the beginning of a LaTeX paragraph, such that the spurious white space added at the end is not harmful. -- Enrico
Re: Language change within Flex inset exports wrong babel construct
Le 03/06/11 14:26, Enrico Forestieri a écrit : As \selectlanguage introduces spurious white space, it should not be used in "inline" content. As \selectlanguage is only used when the language is changed at the very beginning of a LyX paragraph, checking isMainText() ensures that it is used only at the beginning of a LaTeX paragraph, such that the spurious white space added at the end is not harmful. How well does that work when the flex inset is in a branch, for example? Can the otexstream be queried to know whether we are at the start of a LaTeX paragraph? JMarc
Re: Language change within Flex inset exports wrong babel construct
On Fri, Jun 03, 2011 at 02:32:16PM +0200, Jean-Marc Lasgouttes wrote: > Le 03/06/11 14:26, Enrico Forestieri a écrit : > >As \selectlanguage introduces spurious white space, it should not be used > >in "inline" content. As \selectlanguage is only used when the language is > >changed at the very beginning of a LyX paragraph, checking isMainText() > >ensures that it is used only at the beginning of a LaTeX paragraph, such > >that the spurious white space added at the end is not harmful. > > How well does that work when the flex inset is in a branch, for > example? Very well, apparently. > Can the otexstream be queried to know whether we are at the > start of a LaTeX paragraph? No, you can only know whether we are at the start of a new line. I start to think that you don't realize that this only matters at export time, though. -- Enrico
Language change within Flex inset exports wrong babel construct
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
On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
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 ?
I think so. I've had a look at it, and it's more difficult than it might
seem. A comment in the code (this is output_latex.cpp, lines 770ff)
suggests that sometimes we do need to restore the language, whereas it
seems that in this sort of case we do not. That suggests we need a
layout tag.
Richard
Re: Language change within Flex inset exports wrong babel construct
On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
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 ?
I think so. I've had a look at it, and it's more difficult than it might
seem. A comment in the code (this is output_latex.cpp, lines 770ff)
suggests that sometimes we do need to restore the language, whereas it
seems that in this sort of case we do not. That suggests we need a
layout tag.
I am not sure it's so difficult. Note that \selectlanguage is used when the
language is changed at the start of a paragraph, otherwise \foreignlanguage
is used. In the given example, a workaround is inserting {} in ERT right
before word and then changing the language of word only. You can see
that \foreignlanguage is then employed. Maybe \selectlanguage could be
used at the start of a paragraph only if Text::isMainText() is true.
--
Enrico
Re: Language change within Flex inset exports wrong babel construct
On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:
On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
I think so. I've had a look at it, and it's more difficult than it might
seem. A comment in the code (this is output_latex.cpp, lines 770ff)
suggests that sometimes we do need to restore the language, whereas it
seems that in this sort of case we do not. That suggests we need a
layout tag.
I am not sure it's so difficult. Note that \selectlanguage is used when the
language is changed at the start of a paragraph, otherwise \foreignlanguage
is used. In the given example, a workaround is inserting {} in ERT right
before word and then changing the language of word only. You can see
that \foreignlanguage is then employed. Maybe \selectlanguage could be
used at the start of a paragraph only if Text::isMainText() is true.
See attached patch.
--
Enrico
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(revisione 38933)
+++ src/output_latex.cpp(copia locale)
@@ -86,6 +86,8 @@ static TeXEnvironmentData prepareEnviron
BufferParams const bparams = buf.params();
+ bool const maintext = text.isMainText();
+
// FIXME This test should not be necessary.
// We should perhaps issue an error if it is.
Layout const style = text.inset().forcePlainLayout() ?
@@ -118,9 +120,12 @@ static TeXEnvironmentData prepareEnviron
string const doc_lang = use_pg ?
getPolyglossiaEnvName(doc_language) : doc_language-babel();
string const lang_begin_command = use_pg ?
- \\begin{$$lang} : lyxrc.language_command_begin;
+ \\begin{$$lang} : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
- \\end{$$lang} : lyxrc.language_command_end;
+ \\end{$$lang} : maintext ? lyxrc.language_command_end : };
+
+ bool const breakline = maintext || use_pg;
if (par_lang != prev_par_lang) {
if (!lang_end_command.empty()
@@ -129,9 +134,10 @@ static TeXEnvironmentData prepareEnviron
os from_ascii(subst(
lang_end_command,
$$lang,
- prev_par_lang))
- // the '%' is necessary to prevent unwanted whitespace
- %\n;
+ prev_par_lang));
+ if (breakline)
+ // break line but prevent unwanted whitespace
+ os safebreakln;
}
if ((lang_end_command.empty() ||
@@ -146,8 +152,9 @@ static TeXEnvironmentData prepareEnviron
os [
from_ascii(data.par_language-polyglossiaOpts())
];
- // the '%' is necessary to prevent unwanted whitespace
- os %\n;
+ if (breakline)
+ // break line but prevent unwanted whitespace
+ os safebreakln;
}
}
@@ -518,9 +525,12 @@ void TeXOnePar(Buffer const buf,
string const outer_lang = use_pg ?
getPolyglossiaEnvName(outer_language) : outer_language-babel();
string const lang_begin_command = use_pg ?
- \\begin{$$lang} : lyxrc.language_command_begin;
+ \\begin{$$lang} : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
- \\end{$$lang} : lyxrc.language_command_end;
+ \\end{$$lang} : maintext ? lyxrc.language_command_end : };
+
+ bool const breakline = maintext || use_pg;
if (par_lang != prev_lang
// check if we already put language command in TeXEnvironment()
@@ -535,9 +545,10 @@ void TeXOnePar(Buffer const buf,
{
os from_ascii(subst(lang_end_command,
$$lang,
- prev_lang))
- // the '%' is necessary to prevent unwanted
whitespace
- %\n;
+ prev_lang));
+ if (breakline)
+ // break line but prevent unwanted whitespace
+ os safebreakln;
}
// We need to open a new language if we couldn't close the
previous
@@ -594,8 +605,9 @@ void TeXOnePar(Buffer const buf,
os [
Re: Language change within Flex inset exports wrong babel construct
On 06/02/2011 08:07 PM, Enrico Forestieri wrote:
On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:
On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
I think so. I've had a look at it, and it's more difficult than it might
seem. A comment in the code (this is output_latex.cpp, lines 770ff)
suggests that sometimes we do need to restore the language, whereas it
seems that in this sort of case we do not. That suggests we need a
layout tag.
I am not sure it's so difficult. Note that \selectlanguage is used when the
language is changed at the start of a paragraph, otherwise \foreignlanguage
is used. In the given example, a workaround is inserting {} in ERT right
before word and then changing the language of word only. You can see
that \foreignlanguage is then employed. Maybe \selectlanguage could be
used at the start of a paragraph only if Text::isMainText() is true.
See attached patch.
Well, you understand this part of the code much (MUCH!) better than I
do, which is pretty much not at all. Jurgen, you care to comment (for
branch)?
Richard
Language change within Flex inset exports wrong babel construct
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
On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
> 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 ?
>
I think so. I've had a look at it, and it's more difficult than it might
seem. A comment in the code (this is output_latex.cpp, lines 770ff)
suggests that sometimes we do need to restore the language, whereas it
seems that in this sort of case we do not. That suggests we need a
layout tag.
Richard
Re: Language change within Flex inset exports wrong babel construct
On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
> On 06/02/2011 12:37 PM, Jean-Pierre Chrétien wrote:
> > 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 ?
> >
> I think so. I've had a look at it, and it's more difficult than it might
> seem. A comment in the code (this is output_latex.cpp, lines 770ff)
> suggests that sometimes we do need to restore the language, whereas it
> seems that in this sort of case we do not. That suggests we need a
> layout tag.
I am not sure it's so difficult. Note that \selectlanguage is used when the
language is changed at the start of a paragraph, otherwise \foreignlanguage
is used. In the given example, a workaround is inserting {} in ERT right
before "word" and then changing the language of "word" only. You can see
that \foreignlanguage is then employed. Maybe \selectlanguage could be
used at the start of a paragraph only if Text::isMainText() is true.
--
Enrico
Re: Language change within Flex inset exports wrong babel construct
On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:
> On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
>
> > I think so. I've had a look at it, and it's more difficult than it might
> > seem. A comment in the code (this is output_latex.cpp, lines 770ff)
> > suggests that sometimes we do need to restore the language, whereas it
> > seems that in this sort of case we do not. That suggests we need a
> > layout tag.
>
> I am not sure it's so difficult. Note that \selectlanguage is used when the
> language is changed at the start of a paragraph, otherwise \foreignlanguage
> is used. In the given example, a workaround is inserting {} in ERT right
> before "word" and then changing the language of "word" only. You can see
> that \foreignlanguage is then employed. Maybe \selectlanguage could be
> used at the start of a paragraph only if Text::isMainText() is true.
See attached patch.
--
Enrico
Index: src/output_latex.cpp
===
--- src/output_latex.cpp(revisione 38933)
+++ src/output_latex.cpp(copia locale)
@@ -86,6 +86,8 @@ static TeXEnvironmentData prepareEnviron
BufferParams const & bparams = buf.params();
+ bool const maintext = text.isMainText();
+
// FIXME This test should not be necessary.
// We should perhaps issue an error if it is.
Layout const & style = text.inset().forcePlainLayout() ?
@@ -118,9 +120,12 @@ static TeXEnvironmentData prepareEnviron
string const doc_lang = use_pg ?
getPolyglossiaEnvName(doc_language) : doc_language->babel();
string const lang_begin_command = use_pg ?
- "\\begin{$$lang}" : lyxrc.language_command_begin;
+ "\\begin{$$lang}" : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
- "\\end{$$lang}" : lyxrc.language_command_end;
+ "\\end{$$lang}" : maintext ? lyxrc.language_command_end : "}";
+
+ bool const breakline = maintext || use_pg;
if (par_lang != prev_par_lang) {
if (!lang_end_command.empty() &&
@@ -129,9 +134,10 @@ static TeXEnvironmentData prepareEnviron
os << from_ascii(subst(
lang_end_command,
"$$lang",
- prev_par_lang))
- // the '%' is necessary to prevent unwanted whitespace
- << "%\n";
+ prev_par_lang));
+ if (breakline)
+ // break line but prevent unwanted whitespace
+ os << safebreakln;
}
if ((lang_end_command.empty() ||
@@ -146,8 +152,9 @@ static TeXEnvironmentData prepareEnviron
os << "["
<<
from_ascii(data.par_language->polyglossiaOpts())
<< "]";
- // the '%' is necessary to prevent unwanted whitespace
- os << "%\n";
+ if (breakline)
+ // break line but prevent unwanted whitespace
+ os << safebreakln;
}
}
@@ -518,9 +525,12 @@ void TeXOnePar(Buffer const & buf,
string const outer_lang = use_pg ?
getPolyglossiaEnvName(outer_language) : outer_language->babel();
string const lang_begin_command = use_pg ?
- "\\begin{$$lang}" : lyxrc.language_command_begin;
+ "\\begin{$$lang}" : maintext ? lyxrc.language_command_begin
+: lyxrc.language_command_local;
string const lang_end_command = use_pg ?
- "\\end{$$lang}" : lyxrc.language_command_end;
+ "\\end{$$lang}" : maintext ? lyxrc.language_command_end : "}";
+
+ bool const breakline = maintext || use_pg;
if (par_lang != prev_lang
// check if we already put language command in TeXEnvironment()
@@ -535,9 +545,10 @@ void TeXOnePar(Buffer const & buf,
{
os << from_ascii(subst(lang_end_command,
"$$lang",
- prev_lang))
- // the '%' is necessary to prevent unwanted
whitespace
- << "%\n";
+ prev_lang));
+ if (breakline)
+ // break line but prevent unwanted whitespace
+ os << safebreakln;
}
// We need to open a new language if we couldn't close the
previous
@@ -594,8 +605,9 @@ void TeXOnePar(Buffer const &
Re: Language change within Flex inset exports wrong babel construct
On 06/02/2011 08:07 PM, Enrico Forestieri wrote:
> On Thu, Jun 02, 2011 at 11:36:08PM +0200, Enrico Forestieri wrote:
>
>> On Thu, Jun 02, 2011 at 03:56:42PM -0400, Richard Heck wrote:
>>
>>> I think so. I've had a look at it, and it's more difficult than it might
>>> seem. A comment in the code (this is output_latex.cpp, lines 770ff)
>>> suggests that sometimes we do need to restore the language, whereas it
>>> seems that in this sort of case we do not. That suggests we need a
>>> layout tag.
>> I am not sure it's so difficult. Note that \selectlanguage is used when the
>> language is changed at the start of a paragraph, otherwise \foreignlanguage
>> is used. In the given example, a workaround is inserting {} in ERT right
>> before "word" and then changing the language of "word" only. You can see
>> that \foreignlanguage is then employed. Maybe \selectlanguage could be
>> used at the start of a paragraph only if Text::isMainText() is true.
> See attached patch.
>
Well, you understand this part of the code much (MUCH!) better than I
do, which is pretty much not at all. Jurgen, you care to comment (for
branch)?
Richard
