On 16/10/2008 22:41, rgheck wrote:
Andre Poenitz wrote:
On Thu, Oct 16, 2008 at 03:23:10PM -0400, rgheck wrote:
+
+if (!foundOne)
+return false;
+
+return true;
+}
"return foundOne;"
Thanks. Copy-paste
I wonder a bit about the size of the patches, and I have to admit
Andre Poenitz wrote:
On Thu, Oct 16, 2008 at 03:23:10PM -0400, rgheck wrote:
+
+ if (!foundOne)
+ return false;
+
+ return true;
+}
"return foundOne;"
Thanks. Copy-paste
I wonder a bit about the size of the patches, and I have to admit that I
did n
On Thu, Oct 16, 2008 at 03:23:10PM -0400, rgheck wrote:
> +
> + if (!foundOne)
> + return false;
> +
> + return true;
> +}
"return foundOne;"
I wonder a bit about the size of the patches, and I have to admit that I
did not follow closely. Is this still necessary, or rather a
Jean-Marc Lasgouttes wrote:
> But there are probably more symbols that we'd like to translate...
Sure. But as an intermediate solution it is IMHO better than the current
one.
Georg
When I added this a while ago, I always meant to add checks here, to
make sure the module the user wants to load really can be loaded. The
attached patch adds the necessary routine to BufferParams, and then
simplifies GuiDocument a bit, since the code used in BufferParams was
simply stolen fr
Here finally is the patch I've been promising in the CVS logs. It
addresses an issue that came up with the new siamltex layout.
It seems there are circumstances under which a layout might itself want
to provide the functionality associated with a given module, so that (i)
we do not want the
On Thu, Oct 16, 2008 at 01:39:08PM -0400, rgheck wrote:
> José Matos wrote:
> > Hi,
> > the file attached shows a problem when converting an index from 1.5 to
> > 1.6.
> >
> > The problem is that the original index is: "\~\/ Operator" the problem
> > is
> > that the conversion to latex t
On Thursday 2008-10-16 14:15, José Matos wrote:
>On Thursday 16 October 2008 18:18:31 José Matos wrote:
>> Hi,
>> the file attached shows a problem when converting an index from 1.5 to
>> 1.6.
>>
>> The problem is that the original index is: "\~\/ Operator" the problem
>> is
Is this su
On Thu, Oct 16, 2008 at 05:41:56PM +0200, Georg Baum wrote:
> Abdelrazak Younes wrote:
>
> > On 13/10/2008 21:31, Georg Baum wrote:
> >> Both ascii and latin1 are a subset of utf8,
> >
> > ascii certainly but latin1, I don't think so, AFAIK. latin1 is a subset
> > of ucs4/utf32, is that what you
On Thu, Oct 16, 2008 at 05:40:51PM +0200, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > Or slurp in the contents of the .tex file and try various encodings
> > until we find one that "does the trick", possibly after cutting it
> > into parts for which we know that the encoding stays constant.
>
José Matos <[EMAIL PROTECTED]> writes:
> Even weird is the fact that if the pdf is generated inside lyx it works while
> it fails if the file is first exported to latex and then all the generation
> is
> done outside... :-(
A small example would be nice...
JMarc
On Thursday 16 October 2008 18:18:31 José Matos wrote:
> Hi,
> the file attached shows a problem when converting an index from 1.5 to
> 1.6.
>
> The problem is that the original index is: "\~\/ Operator" the problem
> is
> that the conversion to latex transforms the \~ as an accent int
José Matos wrote:
Hi,
the file attached shows a problem when converting an index from 1.5 to
1.6.
The problem is that the original index is: "\~\/ Operator" the problem is
that the conversion to latex transforms the \~ as an accent into unicode
character 0303 the tilde accent. Clearl
Hi,
the file attached shows a problem when converting an index from 1.5 to
1.6.
The problem is that the original index is: "\~\/ Operator" the problem
is
that the conversion to latex transforms the \~ as an accent into unicode
character 0303 the tilde accent. Clearly this wrong
Georg Baum <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
>> After thinking about it, I think these lines are not worse today than
>> they were at their inception. So we can keep them a bit more, until we
>> have a proper solution :)
>
> Or output some InsetLaTeXAccent instead. That wi
Jean-Marc Lasgouttes wrote:
> After thinking about it, I think these lines are not worse today than
> they were at their inception. So we can keep them a bit more, until we
> have a proper solution :)
Or output some InsetLaTeXAccent instead. That will work with any encoding,
and lyx2lyx will conv
Abdelrazak Younes wrote:
> On 13/10/2008 21:31, Georg Baum wrote:
>> Both ascii and latin1 are a subset of utf8,
>
> ascii certainly but latin1, I don't think so, AFAIK. latin1 is a subset
> of ucs4/utf32, is that what you meant?
Of course you are right, I mixed that up. So if tex2lyx detects a
Andre Poenitz wrote:
> Or slurp in the contents of the .tex file and try various encodings
> until we find one that "does the trick", possibly after cutting it
> into parts for which we know that the encoding stays constant.
Yes. Note that this can become quite tricky, though: Some variable width
Here is a trival file. Feel free to make a bugzilla entry from it. I
am too busy right now.
Stefan
foo.tex
Description: Binary data
Am 16.10.2008 um 17:22 schrieb Uwe Stöhr:
Stefan Schimanski schrieb:
You mean it is fixed in trunk now? Still have this behaviour,
though I might be som
Stefan Schimanski schrieb:
You mean it is fixed in trunk now? Still have this behaviour, though I
might be some days behind.
OK, then this bug is still there. Please report it at bugzilla and send me LyX-testfile. I'll have a
look.
thanks and regards
Uwe
Am 16.10.2008 um 15:38 schrieb Uwe Stöhr:
> Before exporting foo.lyx :
> \global\def\var{\func{var}}
>
> After importing foo.tex :
> \global\global\def\var{\func{var}}
Should work in next test release as we in the meantime fixed the bug
that causes this.- Please test this again when the next
> Before exporting foo.lyx :
> \global\def\var{\func{var}}
>
> After importing foo.tex :
> \global\global\def\var{\func{var}}
Should work in next test release as we in the meantime fixed the bug that causes this.- Please test
this again when the next lyX 1.6 release comes out. When the bug is th
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> I think it does that already... If it is true, then the direct support
>> for umlauts should be killed now.
>
> I am a bit dense today...
Actually, I think I was a bit dense yesterday.
> Should I just remove the lines, replace them by utf8 output or do
23 matches
Mail list logo
