Sandor Szabo wrote:
Dear Developers,
I found on the net an online software
(http://www.orcca.on.ca/MathML/texmml/textomml.html)
which can translate tex/latex to mathml.
This is not a free software so, unfortunately we cannot rely on that.
It is possible to put an "Export to MathML" option
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
I fully agree. Up to now I still don't fully grasp the difference
between ParIterator and ParConstIterator for example. And it took me a
looong time to understand all the others.
Well it is supposed to be const_iterator semantics... You can g
Enrico Forestieri wrote:
> The attached patch fixes the problem in trunk.
> Jürgen, OK for branch, too?
Yes.
Jürgen
Uwe Stöhr wrote:
> We forgot the following in our discussion: The width is only changed when
> the user has chosen 1\columnwidth or 1\linewidth, in all other cases
> nothing will be changed. And with the fix you now really get _exectly_
> 1\columnwidth.
> So I'll commit the patch soon. Do you still
Abdelrazak Younes wrote:
> I fully agree. Up to now I still don't fully grasp the difference
> between ParIterator and ParConstIterator for example. And it took me a
> looong time to understand all the others.
Well it is supposed to be const_iterator semantics... You can get one from a
const cont
Edwin Leuven wrote:
i just upgraded to visual studio 9 2008 but have troubles building lyx.
i use cmake version 2.5-20080113 and call it as follows:
cmake -G "Visual Studio 9 2008" ..\trunk\development\cmake
-DGNUWIN32_DIR=c:\Programs\GnuWin32
as i used to do.
error messages be
Andre Poenitz wrote:
> I am currently poking around in the code and got the feeling that our
> iterators have a tendency of being used wrongly, possibly because parts
> are not really well implemented, and possibly because we don't have
> explanations on what to use when.
>
> The result was e.g.
Andre Poenitz <[EMAIL PROTECTED]> writes:
> I am tempted to collapse all the iterator classes into one (or two, for
> a const variant) 'DocIterator'. It's pretty much what we have now,
> except the question 'which one to use' would not arise, and
> 'operator++()' wouldn't do 'the right thing'. I
i just upgraded to visual studio 9 2008 but have troubles building lyx.
i use cmake version 2.5-20080113 and call it as follows:
cmake -G "Visual Studio 9 2008" ..\trunk\development\cmake
-DGNUWIN32_DIR=c:\Programs\GnuWin32
as i used to do.
error messages below.
does someone know
On Sun, Jan 13, 2008 at 09:16:11PM +0100, Horst Schirmeier wrote:
> On Sun, 13 Jan 2008, Enrico Forestieri wrote:
> > Note that the activation of the "Up" and "Down" buttons does not work
> > correctly with Qt 4.2 (4.3 is OK). When you load the attached .lyx file,
> > open the "BibTeX Bibliography
On Sun, 13 Jan 2008, Enrico Forestieri wrote:
> Note that the activation of the "Up" and "Down" buttons does not work
> correctly with Qt 4.2 (4.3 is OK). When you load the attached .lyx file,
> open the "BibTeX Bibliography" panel and select the first entry, the
> "Down" button is activated. But i
Dear Developers,
I found on the net an online software
(http://www.orcca.on.ca/MathML/texmml/textomml.html)
which can translate tex/latex to mathml.
It can handle
\documentclass[11pt]{article}
\usepackage{amsmath}
%%% Macro definitions %%%.
I use it recently, and I'm satisfied with it
(see e
> Yes, but I do not like the iconn design very much.
Me too, therefor I asked for better ideas.
> Attached is an icon from the KDE icon set which is used by LyX that strikes
me appropriate.
Me too.
Could you please send it to me again in private mail as I can't download it
from Gmane.
thank
I wrote:
> I want to put it in trunk
> anyway. When this should really make problems, what I don't assume as
> _exactly_ setting the width can only be done currently via ERT
We forgot the following in our discussion: The width is only changed when the user has chosen
1\columnwidth or 1\linewidt
I wrote:
> I want to put it in trunk
> anyway. When this should really make problems, what I don't assume as
> _exactly_ setting the width can only be done currently via ERT
We forgot the following in our discussion: The width is only changed when the user has chosen
1\columnwidth or 1\linewidt
Andre Poenitz wrote:
I am currently poking around in the code and got the feeling that our
iterators have a tendency of being used wrongly, possibly because parts
are not really well implemented, and possibly because we don't have
explanations on what to use when.
The result was e.g. a 20% runti
I am currently poking around in the code and got the feeling that our
iterators have a tendency of being used wrongly, possibly because parts
are not really well implemented, and possibly because we don't have
explanations on what to use when.
The result was e.g. a 20% runtime increase when loadi
Uwe Stöhr wrote:
> > No, it could both be fixed in 1.6.
>
> How will you do this?
Implement the possibility to insert additions and substractions as box widths.
This is the first file format change (which will revert such boxes to ERT).
Then implement the change. This is the second file format c
Uwe Stöhr wrote:
> > For an unknown reason we don't have yet an toolbar button for boxes. The
> > attached patch introduces this.
>
> Jürgen, do you think this should also go to branch?
Yes, but I do not like the iconn design very much. Attached is an icon from
the KDE icon set which is used by L
Uwe Stöhr schrieb:
For an unknown reason we don't have yet an toolbar button for boxes. The
attached patch introduces this.
Jürgen, do you think this should also go to branch?
regards Uwe
>> This means that this should be implemented in LyX 1.6 first and then could
>> be fixed in a year or so with LyX 1.7?
>
> No, it could both be fixed in 1.6.
How will you do this?
regards Uwe
Uwe Stöhr wrote:
> This means that this should be implemented in LyX 1.6 first and then could
> be fixed in a year or so with LyX 1.7?
No, it could both be fixed in 1.6.
> And what when nobody implements this
> in LyX 1.6? (I can't do this.) I don't want to wait years for this fix.
> This bug f
> It should be fixed in 1.6, after 1.6 is able to understand subtractions and
> additions in the box width.
This means that this should be implemented in LyX 1.6 first and then could be fixed in a year or so
with LyX 1.7? And what when nobody implements this in LyX 1.6? (I can't do this.)
I don'
On Sun, Jan 13, 2008 at 04:27:27PM +0100, Enrico Forestieri wrote:
> On Sat, Jan 12, 2008 at 12:22:30PM +0100, Jürgen Spitzmüller wrote:
>
> > Horst Schirmeier wrote:
> > > Please add the attached (tiny) correction, I forgot adding the up/down
> > > buttons to ButtonController's list of "only act
On Sat, Jan 12, 2008 at 12:22:30PM +0100, Jürgen Spitzmüller wrote:
> Horst Schirmeier wrote:
> > Please add the attached (tiny) correction, I forgot adding the up/down
> > buttons to ButtonController's list of "only activated when buffer
> > writable" widgets.
>
> Thanks. Committed.
Note that t
Uwe Stöhr wrote:
> But as this is a file format change, this cannot be done for LyX 1.5.x.
> Thus it is not possible to write a lyx2lyx conversion routine.
>
> Should this bug therefore never be fixed?
It should be fixed in 1.6, after 1.6 is able to understand subtractions and
additions in the b
>> > Then this needs to become possible before the change goes in.
>>
>> I don't know how to do this. And when it is implemented, it must be done
>> for LyX 1.5 too.
>
> No, this cannot go into branch (file format change).
;-) Then the cat bites its own tail.
When it should be possible to write
> Jürgen, also OK for branch?
>
> The addition of the comment looks correct to me and is OK for banch.
So bug 2492 is now fixed. The other part of the patch is now bug 4483.
regards Uwe
Uwe Stöhr wrote:
> > Then this needs to become possible before the change goes in.
>
> I don't know how to do this. And when it is implemented, it must be done
> for LyX 1.5 too.
No, this cannot go into branch (file format change).
> >> So OK, the output changes, but it will now be correct.
> >
>> LyX will then set the correct width when the file says 100col%. For a
>> conversion routine I would have to set the width to
>> width "100col%+2\fboxrule+\shadowsize"
>> but this is not possible.
>
> Then this needs to become possible before the change goes in.
I don't know how to do this. And
> makes sense IMHO.
For me too, so I commited your patch to branch and trunk.
thanks and regards
Uwe
Jürgen Spitzmüller wrote:
> BTW, we don't load xcolor with the drivers. This should be fixed as well
> (i.e. xcolor should be loaded as if it was color).
patch attached.
Jürgen
Index: src/LaTeXFeatures.cpp
===
--- src/LaTeXFeatures.c
For an unknown reason we don't have yet an toolbar button for boxes. The
attached patch introduces this.
When somebody have a better idea for the icon please post it.
regards Uwe
Index: images/box-insert.png
===
Cannot display: file
Uwe Stöhr wrote:
> That the output is changed affects all box types, because due to the wrong
> search for "1.0" in the wodth, the subtractions weren't done.
I see.
> Writing a conversion routine is not possible because the fileformat is not
> changed.
> The boxes will still look like
>
> \beg
> The change of the shadowbox width string, however, is a file format change,
> since it changes the output (we have to preserve the width of old documents,
> so you need to write a lyx2lyx conversion/reversion routine).
That the output is changed affects all box types, because due to the wrong s
Jürgen Spitzmüller wrote:
> > URL: http://www.lyx.org/trac/changeset/22537
> > Log:
> > * src/LaTeXFeatures.cpp:
> > - the package "pdfcolmk" must be loaded after [x]color.sty
> > (see package documentation).
>
> I'm intending to commit this to branch as well. The fix is obvious.
Anders Ekberg wrote:
> The proposed patches add some ligatures to the unicodesymbols file.
> The reason is that if you copy and paste text from a pdf-file that
> contain ligatures, you end up with an error that some characters can
> not be represented in the current encoding. If you change to u
The proposed patches add some ligatures to the unicodesymbols file.
The reason is that if you copy and paste text from a pdf-file that
contain ligatures, you end up with an error that some characters can
not be represented in the current encoding. If you change to utf8-
encoding, there will b
spitz wrote:
> URL: http://www.lyx.org/trac/changeset/22537
> Log:
> * src/LaTeXFeatures.cpp:
> - the package "pdfcolmk" must be loaded after [x]color.sty
> (see package documentation).
I'm intending to commit this to branch as well. The fix is obvious.
Jürgen
John Pye wrote:
> Log file is attached.
Really just a shot in the dark, but does either of the following in preamble
change anything?
a.)
\renewcommand{\lyxadded}[3]{\bgroup \color{lyxadded}#3\egroup}
\renewcommand{\lyxdeleted}[3]{\bgroup \color{lyxdeleted}\st{#3}\egroup}
b.)
\usepackage{pdf
On Sun, Jan 13, 2008 at 09:40:07PM +1100, John Pye wrote:
> Hi Jürgen,
>
> Jürgen Spitzmüller wrote:
> > John Pye wrote:
> >
> >> Attached is a screenshot with the error from LyX, and the first one
> >> highlighted. It says "argument of \let has an extra }".
> >>
> >
> > The log file would
John Pye wrote:
> Attached is a screenshot with the error from LyX, and the first one
> highlighted. It says "argument of \let has an extra }".
The log file would really help more. And could you also post an example file
that shows the behaviour?
Jürgen
rgheck wrote:
> Attached is a patch that adapts lyx_pot.py to modules. Basically, I've
> altered the layoutsl10n routine to deal with them, too, since they're
> just layout files. I think this is right, but I'll wait a bit for
> comments, as I haven't dealt with this part of the code before.
Why t
Attached is a screenshot with the error from LyX, and the first one
highlighted. It says "argument of \let has an extra }".
Cheers
JP
Jürgen Spitzmüller wrote:
> John Pye wrote:
>
>> what can I do to fix my document?
>>
>
> For a start, post the error message (or the LaTeX log file), plea
Uwe Stöhr wrote:
> The attached patch fixes bug 2492 and also sets now the correct width for
> all box sizes. To test that it now works correct, see the testcase attached
> to
> http://bugzilla.lyx.org/show_bug.cgi?id=2492
>
> Jürgen, also OK for branch?
The addition of the comment looks correct
John Pye wrote:
> Hi all,
>
> I'm afraid I got ahead of myself a bit when I wrote the following :-(
>
>> ... the track-changes stage of my [...] on the whole works very nicely.
>>
>
> An afternoon's worth of editing with track-changes turned on has
> resulted in a compound document, one fil
John Pye wrote:
> what can I do to fix my document?
For a start, post the error message (or the LaTeX log file), please.
Jürgen
> Next, there seems to be some strangeness is the expand/hide behaviour of
> footnotes. I find that when I click on a hidden footnote 'button', I
> often get an expansion of the text selection happening, rather than the
> intended result of the footnote becoming visible.
is this the bug http://bug
Hi all,
I'm afraid I got ahead of myself a bit when I wrote the following :-(
> ... the track-changes stage of my [...] on the whole works very nicely.
An afternoon's worth of editing with track-changes turned on has
resulted in a compound document, one file per chapter, that will no
longer allow
Andre Poenitz wrote:
> On Sat, Jan 12, 2008 at 10:12:31PM -0500, rgheck wrote:
>
>> John Pye wrote:
>>
>>> Firstly, the 'compressed' feature for LyX documents seems like a problem
>>> when using LyX files in a CVS/SVN repository, because one can easily
>>> change a file's type from binary t
On Sat, Jan 12, 2008 at 10:12:31PM -0500, rgheck wrote:
> John Pye wrote:
>> Firstly, the 'compressed' feature for LyX documents seems like a problem
>> when using LyX files in a CVS/SVN repository, because one can easily
>> change a file's type from binary to text and back again. This causes
>> ha
On Samstag 12 Januar 2008, Uwe Stöhr wrote:
> > Is it planned to officially support that package?
>
> LyX 1.5 supports this except of some specialities like e.g. the alignment
> of the table rules.
Thanks to José and you for this information.
> > I have only recently been pointed to booktabs (a
52 matches
Mail list logo
