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
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
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
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.
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 (%)
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}
+
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
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
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:
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
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}
>> +
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
52 matches
Mail list logo
