Re: Problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars,
|
| cxx does not like at all your latest changes. Is it really supposed to
| accept them?
A conforming C++ compiler are not supposed to take return types into
account when doing virtual overloading.
class Foo {
public:
virtual int bar() { return 10; }
};
class Bar : public Foo {
public:
string bar() { return "ten"; }
};
int main() {
Foo foo;
Bar bar;
Foo *f1 = foo;
Foo * f2 = bar;
cout foo.bar() endl;
cout bar.bar() endl;
cout f1-bar() endl;
cout f2-bar() endl;
return 0;
}
Bar::bar should overload Foo::bar.
If cxx does not support this it is further form conforming than I
thought.
Still what is strange about these errors is that we have taken
advantage of this earlier for insets too, but now cxx flags these as
errors... I am wondering if it is something I forgot to change...
Lgb
|
| JMarc
|
| /bin/sh ../../libtool --mode=compile mycxx -DHAVE_CONFIG_H -I.
| -I../../../lyx-devel/src/mathed -I../../src
| -I../../../lyx-devel/images -I../../../lyx-devel/src/mathed/../
| -I../../../lyx-devel/src/cheaders
| -I/afs/rocq/home/meval/common/include/ -I/usr/local/include/ -g
| -c ../../../lyx-devel/src/mathed/formula.C
| mycxx -DHAVE_CONFIG_H -I. -I../../../lyx-devel/src/mathed
| -I../../src -I../../../lyx-devel/images
| -I../../../lyx-devel/src/mathed/../
| -I../../../lyx-devel/src/cheaders
| -I/afs/rocq/home/meval/common/include/ -I/usr/local/include/ -g
| -Wp,-MD,.deps/formula.pp -c ../../../lyx-devel/src/mathed/formula.C
| -o formula.o
| cxx: Error: ../../../lyx-devel/src/mathed/formula.h, line 62: return type is
| not identical to return type "Inset *" of overridden virtual
| function function "Inset::Clone"
| InsetFormula * Clone() const;
| ---^
| cxx: Warning: ../../../lyx-devel/src/mathed/formula.h, line 73:
| "const char *InsetFormula::EditMessage()" does not match
| "Inset::EditMessage" -- virtual function override intended?
| char const * EditMessage() {return _("Math editor mode");}
| -^
| cxx: Warning: ../../../lyx-devel/src/mathed/formula.h, line 87:
| "void InsetFormula::GetCursorPos(int , int )" does not match
| "UpdatableInset::GetCursorPos" -- virtual function
| override intended?
| void GetCursorPos(int , int );
| -^
| cxx: Error: ../../../lyx-devel/src/mathed/../insets/insetcommand.h, line 58:
| return type is not identical to return type "Inset *" of overridden
| virtual function function "Inset::Clone"
| InsetCommand * Clone() const;
| ---^
|
| [... snip...]
Re: Bug report: LyX Strange: this should actually never happen anymore, this it should be handled by the Absolute check.
Michael Meskes [EMAIL PROTECTED] writes: | On Mon, Nov 22, 1999 at 04:23:04PM +0100, Lars Gullik Bjønnes wrote: | I think this is fixed in cvs. | | Could anyone please tell me if there is a patch for this. I'd like to | backport the neccessary changes to 1.1.2 so teh Debian package is free of | this bug. You can try out the string.patch at ftp://ftp.devel.lyx.org/pub/lyx/string.patch it contains all the changes made to lyxstring since the release of 1.1.2. Lgb
[seak.teng-fong@iname.com] Feedback from www.lyx.org
--- Start of forwarded message --- Date: Mon, 22 Nov 1999 14:25:05 +0100 Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Feedback from www.lyx.org FROM: [EMAIL PROTECTED] SEAK Teng-Fong ([EMAIL PROTECTED]) entered the following feedback message on the LyX home page: Nowadays, fractions in mathematical expressions are becoming so common that it\'s conventional to use the same font size for fractions. As a result, I\'ve to set \"math-size displaystyle\" for every fraction, and it\'s becoming very tedious. Please consider of implementing a global setting (for the whole document) for this options, or even better, this is the default for fractions unless users want to use smaller fonts. --- End of forwarded message ---
Re: Problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
Lars Lars, | | cxx does not like at all your latest changes. Is it
Lars really supposed to | accept them?
Lars A conforming C++ compiler are not supposed to take return types
Lars into account when doing virtual overloading.
Huh? In any case, neither gcc 2.8.1 not dec cxx accept your code (they
are both crap, I know...). Could you point me at the section of the
standard were this is discussed?
Concerning your example, I simply do not see how it could be
implemented. Consider the following version:
class Foo {
public:
virtual int bar() { return 10; }
};
class Bar : public Foo {
public:
string bar() { return "ten"; }
};
void baz(int i) {}
void baz(string s) {}
int main() {
Foo *foo = new bar;
baz(foo-bar()); //What code should be generated here???
return 0;
}
I can understand the case where the return type is changed to a
subclass of a class, but not chnaging int to string...
Lars If cxx does not support this it is further form conforming than
Lars I thought.
Lars Still what is strange about these errors is that we have taken
Lars advantage of this earlier for insets too, but now cxx flags
Lars these as errors... I am wondering if it is something I forgot to
Lars change...
Might be.
JMarc
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
Seak Nowadays, fractions in mathematical expressions are becoming so
Seak common that it\'s conventional to use the same font size for
Seak fractions. As a result, I\'ve to set \"math-size displaystyle\"
Seak for every fraction, and it\'s becoming very tedious. Please
Seak consider of implementing a global setting (for the whole
Seak document) for this options, or even better, this is the default
Seak for fractions unless users want to use smaller fonts.
Hmm, I do not see where this is conventionnal... This often leads to
horrible typesetting. There is absolutely zero chance for this to
become the default, as far as I am concerned.
If you want that in a document add the following to your preamble (not
tested):
\usepackage{amsmath}
\let\frac=\dfrac
JMarc
Re: Problems with latest cvs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
| Lars Lars, | | cxx does not like at all your latest changes. Is it
| Lars really supposed to | accept them?
|
| Lars A conforming C++ compiler are not supposed to take return types
| Lars into account when doing virtual overloading.
|
| Huh? In any case, neither gcc 2.8.1 not dec cxx accept your code (they
| are both crap, I know...). Could you point me at the section of the
| standard were this is discussed?
|
| Concerning your example, I simply do not see how it could be
| implemented. Consider the following version:
Ok, I may be wrong about the int/string return type.
But:
class Foo {
public:
Foo * Clone() { cout "Foo" endl; return this; }
};
class Bar : public Foo {
public:
Bar * Clone() { cout "Bar" endl; return this; }
};
int main() {
Foo foo;
Bar bar;
Foo * f1 = foo;
Foo * f2 = bar;
foo.Clone();
bar.Clone();
f1-Clone();
f2-Clone();
}
Should absolutely work.
Clause 10.3.5
Lgb
Re: Problems with latest cvs
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Ok, I may be wrong about the int/string return type. Lars But: [...] Lars Should absolutely work. It does with both compilers. Lars Clause 10.3.5 Thanks, JMarc
Re: epsilon and varepsilon bug
Mon Nov 22 1999, Alejandro Aguilar Sierra - On 22 Nov 1999, Jean-Marc Lasgouttes wrote: I agree on that. Alejandro, would you have objections? Of course, a lot of people who used to use epsilon and be pleased to see it displayed on screen will not like that, and I am sure we would get a lot of bug reports. I think we decided to display epsilon (dressed as varepsilon) because it was often used by the mathed users at that time. Anyway this is not correct so I agreed to change it. Do you want to do it, Jean Marc? I do not know what is the best solution now... The best solution is to display all the symbols, but we can't make it cleanly right now. This will change soon. How hard is it to use unicode to display fonts. I have a unicode font installed, which has almost all of the math symbols used in both normal math and in ams math. The mathed could just check for the existence of these glyphs in the unicode font specified, and if there are none, fall back to using symbol or just display the LaTeX code. Does anyone know if there is a mapping from LaTeX math codes to unicode glyph codes? If there isn't, I approximate this to be about 5 hours of work, which I would gladly spend. n. -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. Skingra er! Det finns ingenting att förstå! PGP signature
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
Jean-Marc Lasgouttes wrote:
Seak Nowadays, fractions in mathematical expressions are becoming so
Seak common that it\'s conventional to use the same font size for
Seak fractions. As a result, I\'ve to set \"math-size displaystyle\"
Seak for every fraction, and it\'s becoming very tedious. Please
Seak consider of implementing a global setting (for the whole
Seak document) for this options, or even better, this is the default
Seak for fractions unless users want to use smaller fonts.
Hmm, I do not see where this is conventionnal... This often leads to
horrible typesetting. There is absolutely zero chance for this to
become the default, as far as I am concerned.
Yes, I could assure you that it's conventional (ie. it is a
convention / habit) to use same font size in fraction as well as in non
fraction. In this fraction
y²
x = --
z
the default behaviour of LyX (and LaTeX?) is to use smaller font for 'y'
and 'z', and an even smaller one for '2', but usually, 'x', 'y' and 'z'
should have the same size.
You could check this by looking at any scientific books, reviews,
letter or articles. If you like, here are some English references at my
disposition to persuade you:
* Chemistry in Context 2nd edition; Hill Holman; ELBS; 1983, ISBN 0 17
438359 2 (For ex, page 347)
* Further Pure Mathematics; Bostock et al.; ELBS; 1987; ISBN 0 85950 519
7
(any page)
* Introduction to Quantum Mechanics; Bransden et al.; Longman Scientific
Technical; 1992; ISBN 0-582-44498-5 (any page)
* A numerical library in C for Scientists and Engineers; Lau; CRC Press;
1995; ISBN 0-8493-7376-X (eg page 286)
And even in this old article dated in 1962:
Weinberg S., Eikonal Method in Magnetohydrodynamics, The Physical Review,
Vol 126, No 6 (1962), page 1899
And of course, it's the same in French books/articles.
If you want that in a document add the following to your preamble (not
tested):
\usepackage{amsmath}
\let\frac=\dfrac
I suppose you mean in my .lyx file, right? Well, I put these two
lines at the beginning of the file and before "\layout Standard" using a
text editor. I then open it using LyX but I get this message:
LyX: Unknown token `\usepackage{amsmath}'. Inserting as text. [around
line 25 of file ~/doc/Parabole.lyx]
LyX: Unknown token `\let'. Inserting as text. [around line 25 of file
~/doc/Parabole.lyx]
LyX: Unknown token `\frac='. Inserting as text. [around line 25 of file
~/doc/Parabole.lyx]
LyX: Unknown token `\dfrac'. Inserting as text. [around line 26 of file
~/doc/Parabole.lyx]
Regards,
Seak
PS: I'm not a member of your mailing-list.
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
"Seak, Teng-Fong" [EMAIL PROTECTED] writes:
| If you want that in a document add the following to your preamble (not
| tested):
|
| \usepackage{amsmath}
| \let\frac=\dfrac
|
| I suppose you mean in my .lyx file, right? Well, I put these two
| lines at the beginning of the file and before "\layout Standard" using a
| text editor. I then open it using LyX but I get this message:
You should insert it in Layout-Preamble
Lgb
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
"Seak" == Seak, Teng-Fong [EMAIL PROTECTED] writes:
Seak Yes, I could assure you that it's conventional (ie. it is a
Seak convention / habit) to use same font size in fraction as well as
Seak in non fraction. In this fraction y² x = -- z
Seak the default behaviour of LyX (and LaTeX?) is to use smaller font
Seak for 'y' and 'z', and an even smaller one for '2', but usually,
Seak 'x', 'y' and 'z' should have the same size.
LyX put all these in the same size in a displayed equation (i.e. an
equation which is alone on its line). For a text equation (inside a
line of text), using fractions like you propose leads to an uneven
spacing of lines and makes text difficult to read (the same holds for
sum sub/superscripts).
Seak You could check this by looking at any scientific books,
Seak reviews, letter or articles. If you like, here are some English
Seak references at my disposition to persuade you:
I do not have those reference in out library, but do you mean that
they use the same size of fractions _inside_ of text? And they manage
to get a correct spacing?
Have a look at the example appended to see what I mean. In this case,
the second paragraph is clearly not typeset correctly.
If you want that in a document add the following to your preamble
(not tested):
\usepackage{amsmath} \let\frac=\dfrac
Seak I suppose you mean in my .lyx file, right? Well, I put
Seak these two lines at the beginning of the file and before "\layout
Seak Standard" using a text editor. I then open it using LyX but I
Seak get this message:
As Lars said, it is in Layout-LaTeX_Preamble.
Hope this helps.
JMarc
#This file was created by lasgoutt Tue Nov 23 14:26:58 1999
#LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
\lyxformat 2.15
\textclass article
\language default
\inputencoding latin1
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
In fact the fraction is here
\begin_inset Formula \( x=\frac{y^{2}}{z} \)
\end_inset
.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
\layout Standard
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
The fraction is here
\begin_inset Formula \( x=\displaystyle \frac{y^{2}}{z} \)
\end_inset
.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
The faction should be displayd as follows:
\begin_inset Formula
\[
x=\frac{y^{2}}{z}\]
\end_inset
\the_end
shared modules with lyx.
The "experimental" use of libtool works for linux, and I have not seen any failure reports from other archs yet. I suspect that when libtool is used in "static" mode as it is now, we should not have large problems on any system. However I'd like to see "shared" support also tested. Configure with: ./configure --enable-shared This will cause libmathed, libinset and libsupport to be built as shared libs and when "make install" be installed in /usr/local/lib/lyx This works perfectly on linux, but I am not sure on other archs. Note that use of --enable-shared double the compilation time since both static and shared libs are built. When Lyx is run in place with this setup the static version is used. I would especially like to see OS2 and Win tested. Lgb
import latex nested table bug
Hello dear LyX people,
When importing a latex file with a tabular nested in a table as in:
\documentclass{article}
\begin{document}
\begin{table}
\begin{tabular}{l}
contents
\end{tabular}
\caption{caption}
\end{table}
\end{document}
LyX cannot compile the file. When exporting the resulting LyX file to Latex again, I
receive (disregarding LyX-specific stuff):
\begin{document}
\begin{tabular}{l}
contents \\
\end{tabular}
\caption{caption}
\end{document}
The outer table-float has disappeared. Since it is possible in LyX to make a
construction like this, I assume this is a bug.
Hope you can solve it, Jos
--
ir. J. M. P. van den Oever
Laboratory of Physical Chemistry and Colloid Science
Wageningen University
http://www.fenk.wau.nl/~oever
Haagsteeg 3, 6708 PM Wageningen, The Netherlands
tel:(31) 317 486778
fax:(31) 317 483777
Re: import latex nested table bug
Jos van den Oever [EMAIL PROTECTED] writes:
Is this a reLyX bug then?
Lgb
| Hello dear LyX people,
|
| When importing a latex file with a tabular nested in a table as in:
|
| \documentclass{article}
| \begin{document}
| \begin{table}
| \begin{tabular}{l}
| contents
| \end{tabular}
| \caption{caption}
| \end{table}
| \end{document}
|
| LyX cannot compile the file. When exporting the resulting LyX file to Latex again, I
|receive (disregarding LyX-specific stuff):
|
| \begin{document}
| \begin{tabular}{l}
| contents \\
| \end{tabular}
| \caption{caption}
| \end{document}
|
| The outer table-float has disappeared. Since it is possible in LyX to make a
|construction like this, I assume this is a bug.
|
| Hope you can solve it, Jos
|
| --
| ir. J. M. P. van den Oever
| Laboratory of Physical Chemistry and Colloid Science
| Wageningen University
| http://www.fenk.wau.nl/~oever
| Haagsteeg 3, 6708 PM Wageningen, The Netherlands
| tel:(31) 317 486778
| fax:(31) 317 483777
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 03:47:33PM +0100, Jos van den Oever wrote:
When importing a latex file with a tabular nested in a table as in:
\documentclass{article}
\begin{document}
\begin{table}
\begin{tabular}{l}
contents
\end{tabular}
\caption{caption}
\end{table}
\end{document}
LyX cannot compile the file. When exporting the resulting LyX file to
Latex again, I receive (disregarding LyX-specific stuff):
Hm. I may have found a bug, but if so it's much more rare than what you're
saying. When I use exactly the file shown above, then if I try to reexport
as TeX I get a core dump. However, as long as there's any text at all (e.g.
the word "hi") before the table, it works just fine, and it includes the
table float. And exporting as LaTeX works fine. Is it possible you had an
old version of LyX?
-Amir
Re: import latex nested table bug
Sorry, I forgot to mention I use LyX 1.2 with SuSE 6.0
Re: import latex nested table bug
Amir Karger [EMAIL PROTECTED] writes:
| On Tue, Nov 23, 1999 at 03:47:33PM +0100, Jos van den Oever wrote:
| When importing a latex file with a tabular nested in a table as in:
|
| \documentclass{article}
| \begin{document}
| \begin{table}
| \begin{tabular}{l}
| contents
| \end{tabular}
| \caption{caption}
| \end{table}
| \end{document}
|
| LyX cannot compile the file. When exporting the resulting LyX file to
| Latex again, I receive (disregarding LyX-specific stuff):
|
|
| Hm. I may have found a bug, but if so it's much more rare than what you're
| saying. When I use exactly the file shown above, then if I try to reexport
| as TeX I get a core dump. However, as long as there's any text at all (e.g.
| the word "hi") before the table, it works just fine, and it includes the
| table float. And exporting as LaTeX works fine. Is it possible you had an
| old version of LyX?
What about text directly after and none before?
Lgb
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 04:33:22PM +0100, Jos van den Oever wrote: Sorry, I forgot to mention I use LyX 1.2 with SuSE 6.0 Well, I'm using 1.0.4pre1 (yes, I'm living in the dark ages) which has the same reLyX. I was able to import the file you sent, as long as I put the word "hi" before the table. -Amir
About overloading virtual methods.
Lars, two things: 1/ your exemple did not involve any virtual method, so it is not very interesting to know that it works :) 2/ In the release note for cxx 6.2 (what I have is 6.1), I found the following: The C++ International Standard permits overriding a virtual member function based only on a derived class return type. The current release does not support this capability. So finally, cxx won't allow that. I do not know what CC 5.0 does however. Did this change allow for significant code simplification, or was it just for fun and beauty? JMarc
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 04:45:12PM +0100, Lars Gullik Bjønnes wrote: Amir Karger [EMAIL PROTECTED] writes: | Hm. I may have found a bug, but if so it's much more rare than what you're | saying. When I use exactly the file shown above, then if I try to reexport | as TeX I get a core dump. However, as long as there's any text at all (e.g. | the word "hi") before the table, it works just fine, and it includes the | table float. And exporting as LaTeX works fine. Is it possible you had an | old version of LyX? What about text directly after and none before? That would break too. The problem is that no \layout Standard was being written before the table. Not to pass the buck, but that seems sort of like a LyX bug to me. I mean, figure floats don't usually require a \layout Standard before them, right? Text directly after makes no difference. It's a float, so it's not like you need to worry about having text be in the same paragraph as the float, which you do have to worry about for, e.g., inlined math. -Amir
Re: epsilon and varepsilon bug
On Tue, 23 Nov 1999, Martin Norbäck wrote: How hard is it to use unicode to display fonts. I have a unicode font installed, which has almost all of the math symbols used in both normal math and in ams math. Where can we get that font? The mathed could just check for the existence of these glyphs in the unicode font specified, and if there are none, fall back to using symbol or just display the LaTeX code. Something like that is the idea I was thinking for using the TeX fonts. Does anyone know if there is a mapping from LaTeX math codes to unicode glyph codes? If there isn't, I approximate this to be about 5 hours of work, which I would gladly spend. Great! However, more than a latex-unicode map, it would be better to have an abstract map to math entities, like those from MathML. I don't know how far the unicode font conforms the MathML proposal. Greets, Alejandro
Re: epsilon and varepsilon bug
On 22 Nov 1999, Jean-Marc Lasgouttes wrote: OK, I'll try that. BTW, Alejandro, I noticed recently that it is now possible to insert spaces in math formulas. I doubt that it is intended... Could you have a look? And there was also a patch for using primes and subscript earlier; is it correct. Yes. Where is that patch? That's how it should be: you give me one thing to do, I give you two :) Don't worry, I'll think in 3 things for you to do. ;) Agreed. What's the state of mathed currently? Is do you have something very different from what is in the source tree? Very different, but unfortunately I have not had the time to finish it. Alejandro
Re: About overloading virtual methods.
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Hmm did I forget to add the virtual to the Foo class then... Can Lars you add it and try again. Yes and, sure enough, it breaks. Lars I guess I have to revert those changes... Lars I'll just have to do in a way so that I will rembember to redo Lars this later when the compilers do this right. Right. Before failing, cxx uncovered 2 forgotten const. So keeping it working is actually useful. JMarc
Re: import latex nested table bug
Amir Karger [EMAIL PROTECTED] writes:
| On Tue, Nov 23, 1999 at 04:45:12PM +0100, Lars Gullik Bjønnes wrote:
| Amir Karger [EMAIL PROTECTED] writes:
|
| | Hm. I may have found a bug, but if so it's much more rare than what you're
| | saying. When I use exactly the file shown above, then if I try to reexport
| | as TeX I get a core dump. However, as long as there's any text at all (e.g.
| | the word "hi") before the table, it works just fine, and it includes the
| | table float. And exporting as LaTeX works fine. Is it possible you had an
| | old version of LyX?
|
| What about text directly after and none before?
|
| That would break too. The problem is that no \layout Standard was being
| written before the table. Not to pass the buck, but that seems sort of like
| a LyX bug to me. I mean, figure floats don't usually require a \layout
| Standard before them, right?
Actually I think LyX require the \layout. You can try to make a
minimal document that contains just a tabular and nothing more.
\layout xxx
really is more equiv to
\begin{paragraph}
\end{paragraph}
(that is not latex)
And _everything_ has to be in a paragraph.
Or am I wrong?
Lgb
Re: patch to lyxlookup
"Michael" == Michael Meskes [EMAIL PROTECTED] writes: Michael Here's a small patch I needed to get lyxlookup.C to compile Michael after enybling HAVE_XOPENIM. Thanks. It is in fact already done in cvs. JMarc
Re: patch to lyxlookup
Michael Meskes [EMAIL PROTECTED] writes: | --bp/iNruPH9dso1Pn | Content-Type: text/plain; charset=us-ascii | | Here's a small patch I needed to get lyxlookup.C to compile after enybling | HAVE_XOPENIM. Yes, this this is also in cvs. You know you can do a cvs rdiff -r lyx-1_1_2 -r HEAD lyx-devel To see all the changes made to lyx-devel since 1.1.2. So if you have problems with something specific you could look there for a fix first. Lgb
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 05:07:44PM +0100, Lars Gullik Bjønnes wrote:
Amir Karger [EMAIL PROTECTED] writes:
| That would break too. The problem is that no \layout Standard was being
| written before the table. Not to pass the buck, but that seems sort of like
| a LyX bug to me. I mean, figure floats don't usually require a \layout
| Standard before them, right?
Actually I think LyX require the \layout. You can try to make a
minimal document that contains just a tabular and nothing more.
\layout xxx
really is more equiv to
\begin{paragraph}
\end{paragraph}
And _everything_ has to be in a paragraph.
Or am I wrong?
Sigh. You're right.
In fact, this points out another bug in reLyX. If you have
hi
\begin{table}
...
\end{table}
bye
"hi" and "bye" should be in the same paragraph. But reLyX will make them
separate paragraphs, because there are new paragraphs *inside* the table. It
looks like tables basically need to be handled like footnotes (not
surprising since they're both floats!) Unfortunately, I think that changing
tables to be handled exactly like footnotes could cause havoc if someone has
a footnote inside a table! (Of course, you're not really supposed to do
that.)
I'll put it on my todo list (which may never get done).
In the meantime, I added a CheckForNewParagraph call, which will add a
\layout command before a table if it's the beginning of a paragraph, as
necessary.
I've got a few little bugfixes that I ought to check in, but I've been lazy
because I never really checked out lyx-devel. Also, are there ever going to
be 1.0.4 updates?
-Amir
That french key problem
I just compiled lyx with XopenIM enabled and was able to reproduce this problem. To me it looks like this is really a french locale problem. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Re: epsilon and varepsilon bug
Tue Nov 23 1999, Alejandro Aguilar Sierra - How hard is it to use unicode to display fonts. I have a unicode font installed, which has almost all of the math symbols used in both normal math and in ams math. Where can we get that font? I got a lot of unicode fonts from links found at http://www.cl.cam.ac.uk/~mgk25/unicode.html Does anyone know if there is a mapping from LaTeX math codes to unicode glyph codes? If there isn't, I approximate this to be about 5 hours of work, which I would gladly spend. Great! However, more than a latex-unicode map, it would be better to have an abstract map to math entities, like those from MathML. I don't know how far the unicode font conforms the MathML proposal. Searching the internet I found something called the Omega typesetting system http://www.gutenberg.eu.org/omega/ which may contain what we want. Otherwise there is a tool called TeX4ht, which apperently translates TeX into XML (including MathML). MathML can then hopefully be translated into the correct Unicode characters. I'll dive into this as soon as I get some time on my hands...deadline on Thursday for a big prototype at work... n. -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. Skingra er! Det finns ingenting att förstå! PGP signature
FILE - ostream
I've put a patch under http://mathematik.htwm.de/Software/LyX/index.html.en that uses ostreams instead of FILEs for output and generally cleans up a bit (in my eyes). It's a bit longish and it is only tested with my own stuff, so I do not want do throw it an anybody who is reading the list. Since I have never used a few of the functions I had to change I'd like to ask you to apply it and test it with your own docs. Any comment is welcome. Regards, Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: epsilon and varepsilon bug
You are probably right with both assumptions. However, the result is a hack *and* not what a 'native' LaTeX speaker would expect. I'd rather admit a shortcoming than to hack around. Some day we might be able to display arbitrary bitmaps in any place. Doing a hack now will not prevent us from doing it right later. What's wrong then with the 'clean solution'? You type a \varepsilon, you see a \varepsilon, you get a \varepsilon? Well, the point of LyX is that it can display something like math better than for instance Emacs can. This includes symbols. If the math is displayed correctly in LyX, it's much easier to understand it and find bugs in it. Greets, Asger
Re: patch to lyxlookup
On Tue, Nov 23, 1999 at 05:15:46PM +0100, Lars Gullik Bjønnes wrote: You know you can do a cvs rdiff -r lyx-1_1_2 -r HEAD lyx-devel No, I didn't know that. Thanks. So I take it this command gives me all the changes. Does it give me a patch file? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Re: patch to lyxlookup
On Tue, Nov 23, 1999 at 05:13:19PM +0100, Jean-Marc Lasgouttes wrote: Thanks. It is in fact already done in cvs. Thanks. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Re: FILE - ostream
I've put a patch under http://mathematik.htwm.de/Software/LyX/index.html.en that uses ostreams instead of FILEs for output and generally cleans up a bit (in my eyes). I recommended all developers to check this stuff out. It's good work. It's a bit longish and it is only tested with my own stuff, so I do not want do throw it an anybody who is reading the list. Good move. Since I have never used a few of the functions I had to change I'd like to ask you to apply it and test it with your own docs. Any comment is welcome. I didn't try it, but read most of it, fast. It's impressing work you have done there. Congratulations. I recommend that Lgb includes this as the next mayor clean-up item of LyX-devel, after we have had a new release with the latest bug-fixes and clean-ups (when is that coming, Lgb?). Then, we should have a release with the new load/save code, and a relatively long period of testing so that all bugs are ironed out. One important comment before it's ready for inclusion though: The error handling is insufficient. Yes, I realize that the old code didn't exactly do a great job of handling errors, but a rewrite should at least not be worse. I noticed that the code in buffer.C does not do any error checking at all, after we have saved a document. That's no good. Ideally, it should do error handling all the time... What good are the autosave and emergency save routines if LyX can not even detect out-of-space on the disk and won't complain when the user specifically asks for a save? Regarding testing: It's always a good idea to test stuff like this with the documentation that is included with LyX, because those are long and complex documents. Especially the User Guide is a fine stress-test since that uses maybe 90% of all LyX features. So, load the User Guide, and save it as user1.lyx. Then, load user1.lyx and save it as user2.lyx. Now, do a "diff -u user1.lyx user2.lyx" and it should come up empty. If not, you have certainly found a bug. Also, do a diff with the original version of the User guide, and manually inspect all differences. You should know your code, and should be able to decide if things are ok. If the diff is huge, you will probably notice why, and maybe that will motivate you to redo some of the work to get it closer to the original. That is always a good idea, because the LyX format is also used in several external tools. However, disregarding changes that should be ok, this technique can at least point you in the direction of finding bugs. Repeat the exercise with some of the complicated Example documents that relies on special features, such as the tables document, one that uses color, etc. In this way, it should be managable to get pretty good coverage of the new code. Once again, congratulations on the great job! It must have taken quite a while for you to do this, and I'm glad to see that you took our advice: Just grab an area, and then attack it. I would not have recommended that you grabbed this area as the first thing, but I don't complain that you did, knowing that it's a huge task ;-) And hopefully, it has given you more knowledge about how LyX works, and with that, it will be easier for you to begin a new clean-up project. Welcome aboard! Asger
cvs Nov. 3 INDEX bug
I clicked Index before the first word in a Section* and before I had even setup and index record, dumb eh? LyX thought so. It crashed. But the new functionality is most apprecitated and works nicely as soon as I plug my brain in. I wouldn't even bother to report this except that I know what perfectionists the LyX dev team are. Garst
New SUSE RPMS of lyx-1.1.2
Hi folks, There are new SUSE RPMs of lyx-1.1.2 available in my ftp directory at ftp://ftp.sylvan.com/pub/lyx/SUSE I don't know who to thank for these, since I stupidly deleted his Email. Thanks, whoever did these RPMs, please speak up and claim credit. :-) ---Kayvan -- Kayvan Aghaiepour Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars,
|
| cxx does not like at all your latest changes. Is it really supposed to
| accept them?
A conforming C++ compiler are not supposed to take return types into
account when doing virtual overloading.
class Foo {
public:
virtual int bar() { return 10; }
};
class Bar : public Foo {
public:
string bar() { return "ten"; }
};
int main() {
Foo foo;
Bar bar;
Foo *f1 =
Foo * f2 =
cout << foo.bar() << endl;
cout << bar.bar() << endl;
cout << f1->bar() << endl;
cout << f2->bar() << endl;
return 0;
}
Bar::bar should overload Foo::bar.
If cxx does not support this it is further form conforming than I
thought.
Still what is strange about these errors is that we have taken
advantage of this earlier for insets too, but now cxx flags these as
errors... I am wondering if it is something I forgot to change...
Lgb
|
| JMarc
|
| /bin/sh ../../libtool --mode=compile mycxx -DHAVE_CONFIG_H -I.
| -I../../../lyx-devel/src/mathed -I../../src
| -I../../../lyx-devel/images -I../../../lyx-devel/src/mathed/../
| -I../../../lyx-devel/src/cheaders
| -I/afs/rocq/home/meval/common/include/ -I/usr/local/include/ -g
| -c ../../../lyx-devel/src/mathed/formula.C
| mycxx -DHAVE_CONFIG_H -I. -I../../../lyx-devel/src/mathed
| -I../../src -I../../../lyx-devel/images
| -I../../../lyx-devel/src/mathed/../
| -I../../../lyx-devel/src/cheaders
| -I/afs/rocq/home/meval/common/include/ -I/usr/local/include/ -g
| -Wp,-MD,.deps/formula.pp -c ../../../lyx-devel/src/mathed/formula.C
| -o formula.o
| cxx: Error: ../../../lyx-devel/src/mathed/formula.h, line 62: return type is
| not identical to return type "Inset *" of overridden virtual
| function function "Inset::Clone"
| InsetFormula * Clone() const;
| ---^
| cxx: Warning: ../../../lyx-devel/src/mathed/formula.h, line 73:
| "const char *InsetFormula::EditMessage()" does not match
| "Inset::EditMessage" -- virtual function override intended?
| char const * EditMessage() {return _("Math editor mode");}
| -^
| cxx: Warning: ../../../lyx-devel/src/mathed/formula.h, line 87:
| "void InsetFormula::GetCursorPos(int &, int &)" does not match
| "UpdatableInset::GetCursorPos" -- virtual function
| override intended?
| void GetCursorPos(int &, int &);
| -^
| cxx: Error: ../../../lyx-devel/src/mathed/../insets/insetcommand.h, line 58:
| return type is not identical to return type "Inset *" of overridden
| virtual function function "Inset::Clone"
| InsetCommand * Clone() const;
| ---^
|
| [... snip...]
Re: Bug report: LyX Strange: this should actually never happen anymore, this it should be handled by the Absolute check.
Michael Meskes <[EMAIL PROTECTED]> writes: | On Mon, Nov 22, 1999 at 04:23:04PM +0100, Lars Gullik Bjønnes wrote: | > I think this is fixed in cvs. | | Could anyone please tell me if there is a patch for this. I'd like to | backport the neccessary changes to 1.1.2 so teh Debian package is free of | this bug. You can try out the string.patch at ftp://ftp.devel.lyx.org/pub/lyx/string.patch it contains all the changes made to lyxstring since the release of 1.1.2. Lgb
[seak.teng-fong@iname.com] Feedback from www.lyx.org
--- Start of forwarded message --- Date: Mon, 22 Nov 1999 14:25:05 +0100 Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Feedback from www.lyx.org FROM: [EMAIL PROTECTED] SEAK Teng-Fong ([EMAIL PROTECTED]) entered the following feedback message on the LyX home page: Nowadays, fractions in mathematical expressions are becoming so common that it\'s conventional to use the same font size for fractions. As a result, I\'ve to set \"math-size displaystyle\" for every fraction, and it\'s becoming very tedious. Please consider of implementing a global setting (for the whole document) for this options, or even better, this is the default for fractions unless users want to use smaller fonts. --- End of forwarded message ---
Re: Problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Lars, | | cxx does not like at all your latest changes. Is it
Lars> really supposed to | accept them?
Lars> A conforming C++ compiler are not supposed to take return types
Lars> into account when doing virtual overloading.
Huh? In any case, neither gcc 2.8.1 not dec cxx accept your code (they
are both crap, I know...). Could you point me at the section of the
standard were this is discussed?
Concerning your example, I simply do not see how it could be
implemented. Consider the following version:
class Foo {
public:
virtual int bar() { return 10; }
};
class Bar : public Foo {
public:
string bar() { return "ten"; }
};
void baz(int i) {}
void baz(string s) {}
int main() {
Foo *foo = new bar;
baz(foo->bar()); //What code should be generated here???
return 0;
}
I can understand the case where the return type is changed to a
subclass of a class, but not chnaging int to string...
Lars> If cxx does not support this it is further form conforming than
Lars> I thought.
Lars> Still what is strange about these errors is that we have taken
Lars> advantage of this earlier for insets too, but now cxx flags
Lars> these as errors... I am wondering if it is something I forgot to
Lars> change...
Might be.
JMarc
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
Seak> Nowadays, fractions in mathematical expressions are becoming so
Seak> common that it\'s conventional to use the same font size for
Seak> fractions. As a result, I\'ve to set \"math-size displaystyle\"
Seak> for every fraction, and it\'s becoming very tedious. Please
Seak> consider of implementing a global setting (for the whole
Seak> document) for this options, or even better, this is the default
Seak> for fractions unless users want to use smaller fonts.
Hmm, I do not see where this is conventionnal... This often leads to
horrible typesetting. There is absolutely zero chance for this to
become the default, as far as I am concerned.
If you want that in a document add the following to your preamble (not
tested):
\usepackage{amsmath}
\let\frac=\dfrac
JMarc
Re: Problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> Lars, | | cxx does not like at all your latest changes. Is it
| Lars> really supposed to | accept them?
|
| Lars> A conforming C++ compiler are not supposed to take return types
| Lars> into account when doing virtual overloading.
|
| Huh? In any case, neither gcc 2.8.1 not dec cxx accept your code (they
| are both crap, I know...). Could you point me at the section of the
| standard were this is discussed?
|
| Concerning your example, I simply do not see how it could be
| implemented. Consider the following version:
Ok, I may be wrong about the int/string return type.
But:
class Foo {
public:
Foo * Clone() { cout << "Foo" << endl; return this; }
};
class Bar : public Foo {
public:
Bar * Clone() { cout << "Bar" << endl; return this; }
};
int main() {
Foo foo;
Bar bar;
Foo * f1 =
Foo * f2 =
foo.Clone();
bar.Clone();
f1->Clone();
f2->Clone();
}
Should absolutely work.
Clause 10.3.5
Lgb
Re: Problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Ok, I may be wrong about the int/string return type. Lars> But: [...] Lars> Should absolutely work. It does with both compilers. Lars> Clause 10.3.5 Thanks, JMarc
Re: epsilon and varepsilon bug
Mon Nov 22 1999, Alejandro Aguilar Sierra -> > On 22 Nov 1999, Jean-Marc Lasgouttes wrote: > > > I agree on that. Alejandro, would you have objections? Of course, a > > lot of people who used to use epsilon and be pleased to see it > > displayed on screen will not like that, and I am sure we would get a > > lot of bug reports. > > I think we decided to display epsilon (dressed as varepsilon) because it > was often used by the mathed users at that time. Anyway this is not > correct so I agreed to change it. Do you want to do it, Jean Marc? > > > I do not know what is the best solution now... > > The best solution is to display all the symbols, but we can't make it > cleanly right now. This will change soon. How hard is it to use unicode to display fonts. I have a unicode font installed, which has almost all of the math symbols used in both normal math and in ams math. The mathed could just check for the existence of these glyphs in the unicode font specified, and if there are none, fall back to using symbol or just display the LaTeX code. Does anyone know if there is a mapping from LaTeX math codes to unicode glyph codes? If there isn't, I approximate this to be about 5 hours of work, which I would gladly spend. n. -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. Skingra er! Det finns ingenting att förstå! PGP signature
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
Jean-Marc Lasgouttes wrote:
> Seak> Nowadays, fractions in mathematical expressions are becoming so
> Seak> common that it\'s conventional to use the same font size for
> Seak> fractions. As a result, I\'ve to set \"math-size displaystyle\"
> Seak> for every fraction, and it\'s becoming very tedious. Please
> Seak> consider of implementing a global setting (for the whole
> Seak> document) for this options, or even better, this is the default
> Seak> for fractions unless users want to use smaller fonts.
>
> Hmm, I do not see where this is conventionnal... This often leads to
> horrible typesetting. There is absolutely zero chance for this to
> become the default, as far as I am concerned.
Yes, I could assure you that it's conventional (ie. it is a
convention / habit) to use same font size in fraction as well as in non
fraction. In this fraction
y²
x = --
z
the default behaviour of LyX (and LaTeX?) is to use smaller font for 'y'
and 'z', and an even smaller one for '2', but usually, 'x', 'y' and 'z'
should have the same size.
You could check this by looking at any scientific books, reviews,
letter or articles. If you like, here are some English references at my
disposition to persuade you:
* Chemistry in Context 2nd edition; Hill & Holman; ELBS; 1983, ISBN 0 17
438359 2 (For ex, page 347)
* Further Pure Mathematics; Bostock et al.; ELBS; 1987; ISBN 0 85950 519
7
(any page)
* Introduction to Quantum Mechanics; Bransden et al.; Longman Scientific
& Technical; 1992; ISBN 0-582-44498-5 (any page)
* A numerical library in C for Scientists and Engineers; Lau; CRC Press;
1995; ISBN 0-8493-7376-X (eg page 286)
And even in this old article dated in 1962:
Weinberg S., Eikonal Method in Magnetohydrodynamics, The Physical Review,
Vol 126, No 6 (1962), page 1899
And of course, it's the same in French books/articles.
> If you want that in a document add the following to your preamble (not
> tested):
>
> \usepackage{amsmath}
> \let\frac=\dfrac
I suppose you mean in my .lyx file, right? Well, I put these two
lines at the beginning of the file and before "\layout Standard" using a
text editor. I then open it using LyX but I get this message:
LyX: Unknown token `\usepackage{amsmath}'. Inserting as text. [around
line 25 of file ~/doc/Parabole.lyx]
LyX: Unknown token `\let'. Inserting as text. [around line 25 of file
~/doc/Parabole.lyx]
LyX: Unknown token `\frac='. Inserting as text. [around line 25 of file
~/doc/Parabole.lyx]
LyX: Unknown token `\dfrac'. Inserting as text. [around line 26 of file
~/doc/Parabole.lyx]
Regards,
Seak
PS: I'm not a member of your mailing-list.
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
"Seak, Teng-Fong" <[EMAIL PROTECTED]> writes:
| > If you want that in a document add the following to your preamble (not
| > tested):
| >
| > \usepackage{amsmath}
| > \let\frac=\dfrac
|
| I suppose you mean in my .lyx file, right? Well, I put these two
| lines at the beginning of the file and before "\layout Standard" using a
| text editor. I then open it using LyX but I get this message:
You should insert it in Layout->Preamble
Lgb
Re: [seak.teng-fong@iname.com] Feedback from www.lyx.org
> "Seak" == Seak, Teng-Fong <[EMAIL PROTECTED]> writes:
Seak> Yes, I could assure you that it's conventional (ie. it is a
Seak> convention / habit) to use same font size in fraction as well as
Seak> in non fraction. In this fraction y² x = -- z
Seak> the default behaviour of LyX (and LaTeX?) is to use smaller font
Seak> for 'y' and 'z', and an even smaller one for '2', but usually,
Seak> 'x', 'y' and 'z' should have the same size.
LyX put all these in the same size in a displayed equation (i.e. an
equation which is alone on its line). For a text equation (inside a
line of text), using fractions like you propose leads to an uneven
spacing of lines and makes text difficult to read (the same holds for
sum sub/superscripts).
Seak> You could check this by looking at any scientific books,
Seak> reviews, letter or articles. If you like, here are some English
Seak> references at my disposition to persuade you:
I do not have those reference in out library, but do you mean that
they use the same size of fractions _inside_ of text? And they manage
to get a correct spacing?
Have a look at the example appended to see what I mean. In this case,
the second paragraph is clearly not typeset correctly.
>> If you want that in a document add the following to your preamble
>> (not tested):
>>
>> \usepackage{amsmath} \let\frac=\dfrac
Seak> I suppose you mean in my .lyx file, right? Well, I put
Seak> these two lines at the beginning of the file and before "\layout
Seak> Standard" using a text editor. I then open it using LyX but I
Seak> get this message:
As Lars said, it is in Layout->LaTeX_Preamble.
Hope this helps.
JMarc
#This file was created by Tue Nov 23 14:26:58 1999
#LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
\lyxformat 2.15
\textclass article
\language default
\inputencoding latin1
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
In fact the fraction is here
\begin_inset Formula \( x=\frac{y^{2}}{z} \)
\end_inset
.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
This fraction is small and so the line spacing is even.
\layout Standard
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
The fraction is here
\begin_inset Formula \( x=\displaystyle \frac{y^{2}}{z} \)
\end_inset
.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
This fraction is big, so the line spacing is not even.
The faction should be displayd as follows:
\begin_inset Formula
\[
x=\frac{y^{2}}{z}\]
\end_inset
\the_end
shared modules with lyx.
The "experimental" use of libtool works for linux, and I have not seen any failure reports from other archs yet. I suspect that when libtool is used in "static" mode as it is now, we should not have large problems on any system. However I'd like to see "shared" support also tested. Configure with: ./configure --enable-shared This will cause libmathed, libinset and libsupport to be built as shared libs and when "make install" be installed in /usr/local/lib/lyx This works perfectly on linux, but I am not sure on other archs. Note that use of --enable-shared double the compilation time since both static and shared libs are built. When Lyx is run in place with this setup the static version is used. I would especially like to see OS2 and Win tested. Lgb
import latex nested table bug
Hello dear LyX people,
When importing a latex file with a tabular nested in a table as in:
\documentclass{article}
\begin{document}
\begin{table}
\begin{tabular}{l}
contents
\end{tabular}
\caption{caption}
\end{table}
\end{document}
LyX cannot compile the file. When exporting the resulting LyX file to Latex again, I
receive (disregarding LyX-specific stuff):
\begin{document}
\begin{tabular}{l}
contents \\
\end{tabular}
\caption{caption}
\end{document}
The outer table-float has disappeared. Since it is possible in LyX to make a
construction like this, I assume this is a bug.
Hope you can solve it, Jos
--
ir. J. M. P. van den Oever
Laboratory of Physical Chemistry and Colloid Science
Wageningen University
http://www.fenk.wau.nl/~oever
Haagsteeg 3, 6708 PM Wageningen, The Netherlands
tel:(31) 317 486778
fax:(31) 317 483777
Re: import latex nested table bug
Jos van den Oever <[EMAIL PROTECTED]> writes:
Is this a reLyX bug then?
Lgb
| Hello dear LyX people,
|
| When importing a latex file with a tabular nested in a table as in:
|
| \documentclass{article}
| \begin{document}
| \begin{table}
| \begin{tabular}{l}
| contents
| \end{tabular}
| \caption{caption}
| \end{table}
| \end{document}
|
| LyX cannot compile the file. When exporting the resulting LyX file to Latex again, I
|receive (disregarding LyX-specific stuff):
|
| \begin{document}
| \begin{tabular}{l}
| contents \\
| \end{tabular}
| \caption{caption}
| \end{document}
|
| The outer table-float has disappeared. Since it is possible in LyX to make a
|construction like this, I assume this is a bug.
|
| Hope you can solve it, Jos
|
| --
| ir. J. M. P. van den Oever
| Laboratory of Physical Chemistry and Colloid Science
| Wageningen University
| http://www.fenk.wau.nl/~oever
| Haagsteeg 3, 6708 PM Wageningen, The Netherlands
| tel:(31) 317 486778
| fax:(31) 317 483777
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 03:47:33PM +0100, Jos van den Oever wrote:
> When importing a latex file with a tabular nested in a table as in:
>
> \documentclass{article}
> \begin{document}
> \begin{table}
> \begin{tabular}{l}
> contents
> \end{tabular}
> \caption{caption}
> \end{table}
> \end{document}
>
> LyX cannot compile the file. When exporting the resulting LyX file to
> Latex again, I receive (disregarding LyX-specific stuff):
>
Hm. I may have found a bug, but if so it's much more rare than what you're
saying. When I use exactly the file shown above, then if I try to reexport
as TeX I get a core dump. However, as long as there's any text at all (e.g.
the word "hi") before the table, it works just fine, and it includes the
table float. And exporting as LaTeX works fine. Is it possible you had an
old version of LyX?
-Amir
Re: import latex nested table bug
Sorry, I forgot to mention I use LyX 1.2 with SuSE 6.0
Re: import latex nested table bug
Amir Karger <[EMAIL PROTECTED]> writes:
| On Tue, Nov 23, 1999 at 03:47:33PM +0100, Jos van den Oever wrote:
| > When importing a latex file with a tabular nested in a table as in:
| >
| > \documentclass{article}
| > \begin{document}
| > \begin{table}
| > \begin{tabular}{l}
| > contents
| > \end{tabular}
| > \caption{caption}
| > \end{table}
| > \end{document}
| >
| > LyX cannot compile the file. When exporting the resulting LyX file to
| > Latex again, I receive (disregarding LyX-specific stuff):
| >
|
| Hm. I may have found a bug, but if so it's much more rare than what you're
| saying. When I use exactly the file shown above, then if I try to reexport
| as TeX I get a core dump. However, as long as there's any text at all (e.g.
| the word "hi") before the table, it works just fine, and it includes the
| table float. And exporting as LaTeX works fine. Is it possible you had an
| old version of LyX?
What about text directly after and none before?
Lgb
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 04:33:22PM +0100, Jos van den Oever wrote: > Sorry, I forgot to mention I use LyX 1.2 with SuSE 6.0 Well, I'm using 1.0.4pre1 (yes, I'm living in the dark ages) which has the same reLyX. I was able to import the file you sent, as long as I put the word "hi" before the table. -Amir
About overloading virtual methods.
Lars, two things: 1/ your exemple did not involve any virtual method, so it is not very interesting to know that it works :) 2/ In the release note for cxx 6.2 (what I have is 6.1), I found the following: The C++ International Standard permits overriding a virtual member function based only on a derived class return type. The current release does not support this capability. So finally, cxx won't allow that. I do not know what CC 5.0 does however. Did this change allow for significant code simplification, or was it just for fun and beauty? JMarc
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 04:45:12PM +0100, Lars Gullik Bjønnes wrote: > Amir Karger <[EMAIL PROTECTED]> writes: > > | Hm. I may have found a bug, but if so it's much more rare than what you're > | saying. When I use exactly the file shown above, then if I try to reexport > | as TeX I get a core dump. However, as long as there's any text at all (e.g. > | the word "hi") before the table, it works just fine, and it includes the > | table float. And exporting as LaTeX works fine. Is it possible you had an > | old version of LyX? > > What about text directly after and none before? That would break too. The problem is that no \layout Standard was being written before the table. Not to pass the buck, but that seems sort of like a LyX bug to me. I mean, figure floats don't usually require a \layout Standard before them, right? Text directly after makes no difference. It's a float, so it's not like you need to worry about having text be in the same paragraph as the float, which you do have to worry about for, e.g., inlined math. -Amir
Re: epsilon and varepsilon bug
On Tue, 23 Nov 1999, Martin Norbäck wrote: > How hard is it to use unicode to display fonts. > I have a unicode font installed, which has almost all of the math > symbols used in both normal math and in ams math. Where can we get that font? > The mathed could just check for the existence of these glyphs in the > unicode font specified, and if there are none, fall back to using symbol > or just display the LaTeX code. Something like that is the idea I was thinking for using the TeX fonts. > Does anyone know if there is a mapping from LaTeX math codes to unicode > glyph codes? If there isn't, I approximate this to be about 5 hours of > work, which I would gladly spend. Great! However, more than a latex<->unicode map, it would be better to have an abstract map to math entities, like those from MathML. I don't know how far the unicode font conforms the MathML proposal. Greets, Alejandro
Re: epsilon and varepsilon bug
On 22 Nov 1999, Jean-Marc Lasgouttes wrote: > OK, I'll try that. BTW, Alejandro, I noticed recently that it is now > possible to insert spaces in math formulas. I doubt that it is > intended... Could you have a look? And there was also a patch for > using primes and subscript earlier; is it correct. Yes. Where is that patch? > That's how it should be: you give me one thing to do, I give you two :) Don't worry, I'll think in 3 things for you to do. ;) > Agreed. What's the state of mathed currently? Is do you have something > very different from what is in the source tree? Very different, but unfortunately I have not had the time to finish it. Alejandro
Re: About overloading virtual methods.
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Hmm did I forget to add the virtual to the Foo class then... Can Lars> you add it and try again. Yes and, sure enough, it breaks. Lars> I guess I have to revert those changes... Lars> I'll just have to do in a way so that I will rembember to redo Lars> this later when the compilers do this right. Right. Before failing, cxx uncovered 2 forgotten const. So keeping it working is actually useful. JMarc
Re: import latex nested table bug
Amir Karger <[EMAIL PROTECTED]> writes:
| On Tue, Nov 23, 1999 at 04:45:12PM +0100, Lars Gullik Bjønnes wrote:
| > Amir Karger <[EMAIL PROTECTED]> writes:
| >
| > | Hm. I may have found a bug, but if so it's much more rare than what you're
| > | saying. When I use exactly the file shown above, then if I try to reexport
| > | as TeX I get a core dump. However, as long as there's any text at all (e.g.
| > | the word "hi") before the table, it works just fine, and it includes the
| > | table float. And exporting as LaTeX works fine. Is it possible you had an
| > | old version of LyX?
| >
| > What about text directly after and none before?
|
| That would break too. The problem is that no \layout Standard was being
| written before the table. Not to pass the buck, but that seems sort of like
| a LyX bug to me. I mean, figure floats don't usually require a \layout
| Standard before them, right?
Actually I think LyX require the \layout. You can try to make a
minimal document that contains just a tabular and nothing more.
\layout xxx
really is more equiv to
\begin{paragraph}
\end{paragraph}
(that is not latex)
And _everything_ has to be in a paragraph.
Or am I wrong?
Lgb
Re: patch to lyxlookup
> "Michael" == Michael Meskes <[EMAIL PROTECTED]> writes: Michael> Here's a small patch I needed to get lyxlookup.C to compile Michael> after enybling HAVE_XOPENIM. Thanks. It is in fact already done in cvs. JMarc
Re: patch to lyxlookup
Michael Meskes <[EMAIL PROTECTED]> writes: | --bp/iNruPH9dso1Pn | Content-Type: text/plain; charset=us-ascii | | Here's a small patch I needed to get lyxlookup.C to compile after enybling | HAVE_XOPENIM. Yes, this this is also in cvs. You know you can do a cvs rdiff -r lyx-1_1_2 -r HEAD lyx-devel To see all the changes made to lyx-devel since 1.1.2. So if you have problems with something specific you could look there for a fix first. Lgb
Re: import latex nested table bug
On Tue, Nov 23, 1999 at 05:07:44PM +0100, Lars Gullik Bjønnes wrote:
> Amir Karger <[EMAIL PROTECTED]> writes:
>
> | That would break too. The problem is that no \layout Standard was being
> | written before the table. Not to pass the buck, but that seems sort of like
> | a LyX bug to me. I mean, figure floats don't usually require a \layout
> | Standard before them, right?
>
> Actually I think LyX require the \layout. You can try to make a
> minimal document that contains just a tabular and nothing more.
>
> \layout xxx
>
> really is more equiv to
>
> \begin{paragraph}
> \end{paragraph}
>
> And _everything_ has to be in a paragraph.
>
> Or am I wrong?
Sigh. You're right.
In fact, this points out another bug in reLyX. If you have
hi
\begin{table}
...
\end{table}
bye
"hi" and "bye" should be in the same paragraph. But reLyX will make them
separate paragraphs, because there are new paragraphs *inside* the table. It
looks like tables basically need to be handled like footnotes (not
surprising since they're both floats!) Unfortunately, I think that changing
tables to be handled exactly like footnotes could cause havoc if someone has
a footnote inside a table! (Of course, you're not really supposed to do
that.)
I'll put it on my todo list (which may never get done).
In the meantime, I added a CheckForNewParagraph call, which will add a
\layout command before a table if it's the beginning of a paragraph, as
necessary.
I've got a few little bugfixes that I ought to check in, but I've been lazy
because I never really checked out lyx-devel. Also, are there ever going to
be 1.0.4 updates?
-Amir
That french key problem
I just compiled lyx with XopenIM enabled and was able to reproduce this problem. To me it looks like this is really a french locale problem. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Re: epsilon and varepsilon bug
Tue Nov 23 1999, Alejandro Aguilar Sierra -> > > How hard is it to use unicode to display fonts. > > I have a unicode font installed, which has almost all of the math > > symbols used in both normal math and in ams math. > > Where can we get that font? I got a lot of unicode fonts from links found at http://www.cl.cam.ac.uk/~mgk25/unicode.html > > Does anyone know if there is a mapping from LaTeX math codes to unicode > > glyph codes? If there isn't, I approximate this to be about 5 hours of > > work, which I would gladly spend. > > Great! However, more than a latex<->unicode map, it would be better to > have an abstract map to math entities, like those from MathML. I > don't know how far the unicode font conforms the MathML proposal. Searching the internet I found something called the Omega typesetting system http://www.gutenberg.eu.org/omega/ which may contain what we want. Otherwise there is a tool called TeX4ht, which apperently translates TeX into XML (including MathML). MathML can then hopefully be translated into the correct Unicode characters. I'll dive into this as soon as I get some time on my hands...deadline on Thursday for a big prototype at work... n. -- [ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ] Opinions expressed above are mine, and not those of my future employees. Skingra er! Det finns ingenting att förstå! PGP signature
FILE -> ostream
I've put a patch under http://mathematik.htwm.de/Software/LyX/index.html.en that uses ostreams instead of FILEs for output and generally cleans up a bit (in my eyes). It's a bit longish and it is only tested with my own stuff, so I do not want do throw it an anybody who is reading the list. Since I have never used a few of the functions I had to change I'd like to ask you to apply it and test it with your own docs. Any comment is welcome. Regards, Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: epsilon and varepsilon bug
> You are probably right with both assumptions. However, the result is a > hack *and* not what a 'native' LaTeX speaker would expect. I'd rather > admit a shortcoming than to hack around. Some day we might be able to > display arbitrary bitmaps in any place. Doing a hack now will not prevent us from doing it right later. > What's wrong then with the 'clean solution'? You type a \varepsilon, > you see a \varepsilon, you get a \varepsilon? Well, the point of LyX is that it can display something like math better than for instance Emacs can. This includes symbols. If the math is displayed correctly in LyX, it's much easier to understand it and find bugs in it. Greets, Asger
Re: patch to lyxlookup
On Tue, Nov 23, 1999 at 05:15:46PM +0100, Lars Gullik Bjønnes wrote: > You know you can do a > > cvs rdiff -r lyx-1_1_2 -r HEAD lyx-devel No, I didn't know that. Thanks. So I take it this command gives me all the changes. Does it give me a patch file? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Re: patch to lyxlookup
On Tue, Nov 23, 1999 at 05:13:19PM +0100, Jean-Marc Lasgouttes wrote: > Thanks. It is in fact already done in cvs. Thanks. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: [EMAIL PROTECTED] | Use PostgreSQL!
Re: FILE -> ostream
> I've put a patch under > > http://mathematik.htwm.de/Software/LyX/index.html.en > > that uses ostreams instead of FILEs for output and generally cleans up a > bit (in my eyes). I recommended all developers to check this stuff out. It's good work. > It's a bit longish and it is only tested with my own stuff, so I do not > want do throw it an anybody who is reading the list. Good move. > Since I have never used a few of the functions I had to change > I'd like to ask you to apply it and test it with your own docs. > Any comment is welcome. I didn't try it, but read most of it, fast. It's impressing work you have done there. Congratulations. I recommend that Lgb includes this as the next mayor clean-up item of LyX-devel, after we have had a new release with the latest bug-fixes and clean-ups (when is that coming, Lgb?). Then, we should have a release with the new load/save code, and a relatively long period of testing so that all bugs are ironed out. One important comment before it's ready for inclusion though: The error handling is insufficient. Yes, I realize that the old code didn't exactly do a great job of handling errors, but a rewrite should at least not be worse. I noticed that the code in buffer.C does not do any error checking at all, after we have saved a document. That's no good. Ideally, it should do error handling all the time... What good are the autosave and emergency save routines if LyX can not even detect out-of-space on the disk and won't complain when the user specifically asks for a save? Regarding testing: It's always a good idea to test stuff like this with the documentation that is included with LyX, because those are long and complex documents. Especially the User Guide is a fine stress-test since that uses maybe 90% of all LyX features. So, load the User Guide, and save it as user1.lyx. Then, load user1.lyx and save it as user2.lyx. Now, do a "diff -u user1.lyx user2.lyx" and it should come up empty. If not, you have certainly found a bug. Also, do a diff with the original version of the User guide, and manually inspect all differences. You should know your code, and should be able to decide if things are ok. If the diff is huge, you will probably notice why, and maybe that will motivate you to redo some of the work to get it closer to the original. That is always a good idea, because the LyX format is also used in several external tools. However, disregarding changes that should be ok, this technique can at least point you in the direction of finding bugs. Repeat the exercise with some of the complicated Example documents that relies on special features, such as the tables document, one that uses color, etc. In this way, it should be managable to get pretty good coverage of the new code. Once again, congratulations on the great job! It must have taken quite a while for you to do this, and I'm glad to see that you took our advice: Just grab an area, and then attack it. I would not have recommended that you grabbed this area as the first thing, but I don't complain that you did, knowing that it's a huge task ;-) And hopefully, it has given you more knowledge about how LyX works, and with that, it will be easier for you to begin a new clean-up project. Welcome aboard! Asger
cvs Nov. 3 INDEX bug
I clicked Index before the first word in a Section* and before I had even setup and index record, dumb eh? LyX thought so. It crashed. But the new functionality is most apprecitated and works nicely as soon as I plug my brain in. I wouldn't even bother to report this except that I know what perfectionists the LyX dev team are. Garst
New SUSE RPMS of lyx-1.1.2
Hi folks, There are new SUSE RPMs of lyx-1.1.2 available in my ftp directory at ftp://ftp.sylvan.com/pub/lyx/SUSE I don't know who to thank for these, since I stupidly deleted his Email. Thanks, whoever did these RPMs, please speak up and claim credit. :-) ---Kayvan -- Kayvan Aghaiepour Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
