Re: Special superscript and subscript arrangements
On Tue, 7 Dec 1999, Seak, Teng-Fong wrote:
> Jules Bean wrote:
>
> > On Tue, 30 Nov 1999, Seak, Teng-Fong wrote:
> >
> > > I don't understand quite your question. Maybe we've got some
> > > misunderstanding :-) Actually, I knew how to enter {}. When I ask Lyx
> > > to support R_{i}{}^{j}{}_{kl}, I wanted in fact LyX not to display the red
> > {}
> > > to make the tensor look a bit better.
> >
> > There are two quite orthogonal issues here:
> >
> > [snipped]
> > 1) Availability of font characters: LyX uses a set of X-windows fonts.
> > These have in them some approximation to many of the commonly wanted
> > characters in mathematical notation, but by no means all of them. LyX will
> > not be able to support the others without new fonts - and possibly a more
> > extendable font system.
>
> No, no, there's nothing to do with font. Have you tried that expression
> that I'd written, by the way? Well, except if you're talking about invisible
> font for displaying {} in the mathbox :-)
That was with reference to your other message, about blackboard bold :-)
>
> > 2) Previewing complex things may not be worth it. TeX is an extremely
> > complex system, dealing well with a variety of very complex on-page
> > display issues. It may not be appropriate for LyX to attempt to solve
> > some of these complex problems independently -- it's only intended to be a
> > WYSIWYG previewer.
>
> The expression R_{i}{}^{j}{}_{kl} is nothing fancy. It's at the base of
> LaTeX. No auxiliary macro is needed, neither is it an extension to the
> standard. It's just because this is seldom used so people might have
> forgotten it.
It's not even that seldom used. There's plenty of common TeX idioms that
LyX can't preview. My point is that LyX isn't a complete TeX renderer, so
the dev-team have made decisions about which TeX constructs it can
understand. In fact, I think LyX *should* preview the tensor construct,
but no one has written the code yet.
My point, I think, is that not supporting the tensor is not an oversight.
It simply hasn't been done, because there are so many things to do :-)
LyX's job is hard, because TeX is a bad document description language,
although it's a good page layout language.
Jules
/+---+-\
| Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd|
| Jules aka | [EMAIL PROTECTED] | Richmond, Surrey |
| Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* |
++---+-+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\--/
Re: Special superscript and subscript arrangements
Jules Bean wrote:
> On Tue, 30 Nov 1999, Seak, Teng-Fong wrote:
>
> > I don't understand quite your question. Maybe we've got some
> > misunderstanding :-) Actually, I knew how to enter {}. When I ask Lyx
> > to support R_{i}{}^{j}{}_{kl}, I wanted in fact LyX not to display the red
> {}
> > to make the tensor look a bit better.
>
> There are two quite orthogonal issues here:
>
> [snipped]
> 1) Availability of font characters: LyX uses a set of X-windows fonts.
> These have in them some approximation to many of the commonly wanted
> characters in mathematical notation, but by no means all of them. LyX will
> not be able to support the others without new fonts - and possibly a more
> extendable font system.
No, no, there's nothing to do with font. Have you tried that expression
that I'd written, by the way? Well, except if you're talking about invisible
font for displaying {} in the mathbox :-)
> 2) Previewing complex things may not be worth it. TeX is an extremely
> complex system, dealing well with a variety of very complex on-page
> display issues. It may not be appropriate for LyX to attempt to solve
> some of these complex problems independently -- it's only intended to be a
> WYSIWYG previewer.
The expression R_{i}{}^{j}{}_{kl} is nothing fancy. It's at the base of
LaTeX. No auxiliary macro is needed, neither is it an extension to the
standard. It's just because this is seldom used so people might have
forgotten it.
> Tangentially to that, there's the more general question of exactly which
> job LyX is trying to solve. At the moment (at least for complex
> mathmematically documents) LyX is best thought of as a helpful tool for
> writing LaTeX, but the author needs to know, or at least be willing to
> learn as he goes along, LaTeX in order to acheive more complex effects.
> LyX is essentially a LaTeX front-end.
I agree with you. I totally understand that LyX is WYSIWYM not WYSIWYG.
I don't mind sub/superscript aren't displayed with a smaller font on the
screen, eg. But at the moment when there's something red on the screen, I'd
like to know what it is, and I'd also wonder if what I see is what I really
mean ;-)
Back to the suggestion: I think if no red {} is displayed, it might also
be difficult to understand what the underlying latex expression is. Maybe a
red (or any other colour) vertical bar could be drawn instead of {} to show
that sub/superscripts aren't rearranged to group together.
Seak
Re: Special superscript and subscript arrangements
On Fri, 3 Dec 1999, Andre' Poenitz wrote: > Andre' > > PS: I am really sorry if I sounded too harsh (again) yesterday. > Hey, if any of us bothered to take offence at mailing lists or usenet, we'd have dropped of the net ages ago ;-) /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Special superscript and subscript arrangements
> directory src/kernel. There's a very good design doc there also -- I > think Asger has this on his web site as well. I can't find the included .eps picture. ANy idea? Andre' PS: I am really sorry if I sounded too harsh (again) yesterday. -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: Special superscript and subscript arrangements
If this lyx DTD is close to that used by TeX4ht, somebody else has done the work already ;-) Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: Special superscript and subscript arrangements
Jules are you subscribed to the list? If so I can stop cc'ing to you. On Thu, 2 Dec 1999, Jules Bean wrote: > > If someone were to take this leap I'd suggest getting Asger's kernel first > > so you minimised your work. Either that or just start generalising the > > docbook support now instead of waiting for the docbook support to be > > complete. > > What's in Asger's kernel? A general C++ editting kernel. Could perhaps be turned into a general purpose editting library. See the lyx CVS repository in the directory src/kernel. There's a very good design doc there also -- I think Asger has this on his web site as well. Allan. (ARRae)
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Andre' Poenitz wrote: > > So am I, I just don't see much point in starting yet-another-word-processor > > project when it's possible to improve an existing one. > > That's the point where opinions differ. There are perhaps as many as two dozen word-processors around fighting for developers and attention. There are at least 4 that are specifically using LaTeX. LyX is probably closest to the holy grail already and moving in that direction. Quite a bit of the work has already been done in the old branch. Unfortunately the old branch is so unstable its been archived and we are endeavouring to backport a small section at a time and get them stable. This should prove considerably faster than trying to stabilise the old branch. [See Lars' post for answers to the rest of your email -- ie. I agree] > Does anybody actually work on that? I for one want to work on it full time but I have this silly PhD thesis I'm supposed to finish before I can do that. Lars in particular has pushed through a lot of the stuff he did from the old branch already. > Even if we had backported those 1 lines we would have a nice kernel, > but to achieve GUI independence etc, more work would be needed. A lot of > it, I'd say... Well as one of the key gui-indep developers I can assure you that the dialogs at least are almost a drop-in replacement from the old branch. "Almost" because if we do it right and use the new libsigc++ we'll have to modify the code a little as it's introduced. There are also likely to be a few bug fixes or other small changes that need to be merged between the two. Dialogs are comparatively easy although I really need to update that gui-indep doc so I have a chance of offloading some of the work to volunteers. The hard work in gui-indep is the buffer rendering and main lyx window (ie. the BufferView and the LyXView) but both these areas have been explored in the old branch and you've partaken in the recent discussions so you've heard this before. Allan. (ARRae)
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Amir Karger wrote: > On Thu, Dec 02, 1999 at 12:01:49PM +, Jose Abilio Oliveira Matos wrote: > > Furthermore a reLyX clone (more like a twin ;) to translate from > > tex to the lyx dtd directly would be needed. > > > > José > > Ugh. Good luck finding someone to write it :) No problem. I'd do it. Perl Wizard /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Special superscript and subscript arrangements
On Thu, Dec 02, 1999 at 12:01:49PM +, Jose Abilio Oliveira Matos wrote: > Furthermore a reLyX clone (more like a twin ;) to translate from > tex to the lyx dtd directly would be needed. > > José Ugh. Good luck finding someone to write it :) -Amir
Re: Special superscript and subscript arrangements
On 2 Dec 1999, Lars Gullik Bjønnes wrote: > Jules Bean <[EMAIL PROTECTED]> writes: > > | proto lyxml fragment > | > | > | A > | category > | C > | is: > | > | a collection of objects, > | \ob C > | > | a collection of morphisms, > | > | - > > Actaully this is the direction I want the LyX format to envolve. And a > lot of that is quite easy to do right now. If you look at the previous > devel branch I began doing some fo this, but I used more latex like > constructs, but that is not really important. Excellent :-). Eventually, it would be nice if LyX became completely LaTeX-independent (so LaTex was just a back-end, and that's all) but for now we're going to need a way for users to input direct LaTeX from time to time. > > Note however that we need to support some hardcoding of spacing and > the like: > > > > ... > > ... > > Surely it's better to say ... > I think we should try to begin taking LyX in this direction, _but_ we > have more pressing tasks. Fair enough :-) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Special superscript and subscript arrangements
Jules Bean <[EMAIL PROTECTED]> writes: | proto lyxml fragment | | | A | category | C | is: | | a collection of objects, | \ob C | | a collection of morphisms, | | - Actaully this is the direction I want the LyX format to envolve. And a lot of that is quite easy to do right now. If you look at the previous devel branch I began doing some fo this, but I used more latex like constructs, but that is not really important. Note however that we need to support some hardcoding of spacing and the like: ... ... I think we should try to begin taking LyX in this direction, _but_ we have more pressing tasks. Lgb
Re: Special superscript and subscript arrangements
"Andre' Poenitz" <[EMAIL PROTECTED]> writes: | But I think improving LyX *is* difficult, not because it is already perfect | but because of all built-in legacies. I think the now defunct branch is | *the* proof that structural improvements to LyX are impossible. Without | structural improvements I can't see it survive. This is where I think you are absolutely wrong. The problem with low-level LyX code today is special cases. There are tens of special cases in the low-level code that really obfuscates how things really work. Most of these low-level special cases can be removed by: - remove support for them (mono, fastselect) - or made into higher level constructs. - tabular suport -> tabular inset - footnotes and floats into approp. insets. When you get these special cases out of the low-level code it is easier to make huger structural changes too. | > We tried to make a giant leap forward with the previous development branch | > but with only six or so in the team we couldn't get the momentum to get | > airborne. | | You did not start from scratch. You took an important part out of LyX, | rewrote it and tried to fit it in again. I did not fit. No excactly how it was done... The problem with doing something like this, as we have realised, is that you need to stay stable all the time. Without being stable you loose users and if you loose users you loose testers. And without testers you loose bug reports. | > Hence the demise of the old branch and the change of plan to a | > softly softly approach. Lots of little safe steps. At least we can | > backport the major changes from the old development strand and LyX will | > evolve over time into the glorious wonder we all want it to become. | | Does anybody actually work on that? I just diffed the 'old' and | > 'new' What old an new files? lyx -> lyx-devel ? | files in the main src dir. 69000 lines. Even if you take into account | that 'diff' does not work optimally, it's a safe guess to say there are | 1 lines of changes *excluding* all the kernel stuff. Note that there are a _lot_ of whitespace changes, name changes and the like. also in previous devel there were a working tabular inset and some code to begin a footnote inset. | Even if we had backported those 1 lines we would have a nice kernel, | but to achieve GUI independence etc, more work would be needed. A lot of | it, I'd say... Actually much of the gui code is just drop in. F.ex. the port of the LyXAction in previous devel to current cvs was basically just a cp. | On the other hand: Writing 1 lines *from scratch* (I do mean an | empty directory here!) is not *that* hard. Especially when all the ideas | are already there. | | > We didn't. Maybe some more noise and hype might have gotton more people | > to help out. | | I don't think so. I tried a couple of times to get involved with LyX | development and I always gave up because it was too difficult for me to | understand what's going on. Things need to be simple for people to start | work. LyX is not simple and won't be for quite a while, so there won't | be many new developers. And so on ;-| That depends on what areas in LyX you want to work on. One thing f.ex. that would be nice is a footnoteinset, this should be developed without handling the current kernel code at all, when it is finished and works, we can just remove the footnot handling from the low-level code. Lgb
Re: Special superscript and subscript arrangements
On Thu, Dec 02, 1999 at 12:43:01PM +0100, Andre' Poenitz wrote: > > Yup. Even more sense in an XML world. > > How would a LyX file format look like in an XML world? > Something like MathML? Anybody with working experience? > Does anybody know of a .tex -> .mml translator? I guess this is more up to the point, the only way to the lyx dev team to decide for the adoption of xml will be when someone presents a reliable LyX DTD (XML conforming of course ;) that also takes cares of the legacy documents (at least those from the 1.0.x), and that is easily extensible. Furthermore a reLyX clone (more like a twin ;) to translate from tex to the lyx dtd directly would be needed. > Andre' -- José
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Andre' Poenitz wrote:
> > Yup. Even more sense in an XML world.
>
> How would a LyX file format look like in an XML world?
That would be up to us.
> Something like MathML?
That wouldn't be a bad idea, for example. Best not to reinvent the wheel.
But, AFAIK, MathML is only for the math bits. So maybe a hypothetical
LyXML would use MathML entities inside sections, but other stuff
elsewhere.
> Anybody with working experience?
> Does anybody know of a .tex -> .mml translator?
Don't know of one. They're not possible, in general, of course - TeX is a
vastly more powerful format.
I was thinking of a more simple direct translation of our current format.
Consider this fragment of a real LyX file (I have deleted the blank lines
to take up less space)
lyx file fragment
\layout Section
Definitions and Examples
\layout Definition
A
\emph on
category
\emph default
\begin_inset Formula \( \mathcal{C} \)
\end_inset
is:
\begin_deeper
\layout Itemize
a collection of
\emph on
objects
\emph default
,
\begin_inset Formula \( \ob \mathcal{C} \)
\end_inset
\layout Itemize
a collection of
\emph on
morphisms
\emph default
,
end fragment
proto lyxml fragment
A
category
C
is:
a collection of objects,
\ob C
a collection of morphisms,
-
Note that:
We don't need the begin_deeper cruft. Nesting is made an obvious part of
the format.
The format is slightly more concise, and (IMO) easier to read.
I don't know if backslashes are legal XML. If not, \ob (which is a
user-defined \def) needs to be escaped somehow; perhaps as or similar.
Jules
/+---+-\
| Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd|
| Jules aka | [EMAIL PROTECTED] | Richmond, Surrey |
| Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* |
++---+-+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\--/
Re: Special superscript and subscript arrangements
> Yup. Even more sense in an XML world. How would a LyX file format look like in an XML world? Something like MathML? Anybody with working experience? Does anybody know of a .tex -> .mml translator? Andre' -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Jose Abilio Oliveira Matos wrote: > > > Ok, I'm sorry for the confusion, I don't want LyX to be one more html > editor, that's really an unpleseant idea :) > > What I was refering is the present ability to load the textclasses, > where some configuration is available and extend it. As I said > some time ago (not sure how long :) the textclasses are our stylesheets, > more like css than dsssl or XLT. > > This could be extended, I think, to further control the final output. Yes. > > > > I think that we also need a way to change a document from latex to > > > docbook and convert the document structure from one to the other, and > > > vice versa. That mechanism doesn't exist now. > > > > Tricky though, isn't it. I guess there are enough similarities between > > article.cls and docbook that it could probably be done for articles and > > related classes. A very hard problem in general, though. > > Why not? ;-) > I don't mean the general problem, but some sort of filters, between > specific layouts. Use this filter if you have it, ignore it otherwise. > Ah, yes. This would be excellent. In particular, if we were using XML for *all* our documents, such filters would be trivial to write - XML is designed to easy conversion between different DTDs. > > Latex class-> xml myDTD class > layoutLyX-CodeCode > BlaBla Standard#difficult to translate > Title Mytitle > > Does this makes sense? :) Yup. Even more sense in an XML world. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Special superscript and subscript arrangements
On Thu, Dec 02, 1999 at 10:52:26AM +, Jules Bean wrote: > On Thu, 2 Dec 1999, Jose Abilio Oliveira Matos wrote: > > > As Allan said there are already several steps in that direction in > > the docbook support. There are several abstractions that would allow > > to make another backend really easy. One example, if anyone has the > > time or the energy to do it is a native html backend... > > Yuck. What an unpleasant idea ;-) Hmm... uh.. depends what you mean by > backend, I guess. Certainly, native editing of HTML documents is, IMO, a > feature of only slight usefulness - HTML is a horrible format. However, > editing in a SGML/XML designed for the purpose and then exporting to HTML > would be cool. > Ok, I'm sorry for the confusion, I don't want LyX to be one more html editor, that's really an unpleseant idea :) What I was refering is the present ability to load the textclasses, where some configuration is available and extend it. As I said some time ago (not sure how long :) the textclasses are our stylesheets, more like css than dsssl or XLT. This could be extended, I think, to further control the final output. > > I think that we also need a way to change a document from latex to > > docbook and convert the document structure from one to the other, and > > vice versa. That mechanism doesn't exist now. > > Tricky though, isn't it. I guess there are enough similarities between > article.cls and docbook that it could probably be done for articles and > related classes. A very hard problem in general, though. Why not? ;-) I don't mean the general problem, but some sort of filters, between specific layouts. Use this filter if you have it, ignore it otherwise. A simple example, the layout that is intended to have (computer) code is the LyX-Code in article, and Code in docbook. If you import any lyx latex related document chunck it would lost all the information only because the layout have different names even if they represent the same thing. Now suppose that you create a certain xml document, does this means that all the code paragraphs should be called LyX-Code so that the simple copy and past from other latex class documents doesn't loose this knowleadge? The filters I am refering to could be as simple as this: Latex class-> xml myDTD class layoutLyX-Code Code BlaBlaStandard#difficult to translate Title Mytitle Does this makes sense? :) > Jules > > /+---+-\ > | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd | > | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | > | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | > ++---+-+ > | War doesn't demonstrate who's right... just who's left. | > | When privacy is outlawed... only the outlaws have privacy. | > \--/ -- José
Re: Special superscript and subscript arrangements
> So am I, I just don't see much point in starting yet-another-word-processor > project when it's possible to improve an existing one. That's the point where opinions differ. You think of LyX as something that could be improved fairly easy. As long as 'improving' means 'adding features' I could even agree (when stretching the definition of 'fairly' a bit ;-)). But I think improving LyX *is* difficult, not because it is already perfect but because of all built-in legacies. I think the now defunct branch is *the* proof that structural improvements to LyX are impossible. Without structural improvements I can't see it survive. > We tried to make a giant leap forward with the previous development branch > but with only six or so in the team we couldn't get the momentum to get > airborne. You did not start from scratch. You took an important part out of LyX, rewrote it and tried to fit it in again. I did not fit. > Hence the demise of the old branch and the change of plan to a > softly softly approach. Lots of little safe steps. At least we can > backport the major changes from the old development strand and LyX will > evolve over time into the glorious wonder we all want it to become. Does anybody actually work on that? I just diffed the 'old' and 'new' files in the main src dir. 69000 lines. Even if you take into account that 'diff' does not work optimally, it's a safe guess to say there are 1 lines of changes *excluding* all the kernel stuff. Even if we had backported those 1 lines we would have a nice kernel, but to achieve GUI independence etc, more work would be needed. A lot of it, I'd say... On the other hand: Writing 1 lines *from scratch* (I do mean an empty directory here!) is not *that* hard. Especially when all the ideas are already there. > We didn't. Maybe some more noise and hype might have gotton more people > to help out. I don't think so. I tried a couple of times to get involved with LyX development and I always gave up because it was too difficult for me to understand what's going on. Things need to be simple for people to start work. LyX is not simple and won't be for quite a while, so there won't be many new developers. And so on ;-| Andre' PS: > ... > Argueably you only get airborne by either running faster or jumping off a > cliff. At least if you fail to takeoff while running you still have a > life ahead of you ;-) It's just one of your virtual lifes that you are losing ;-) -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Jose Abilio Oliveira Matos wrote: > On Thu, Dec 02, 1999 at 12:31:37PM +1000, Allan Rae wrote: > > On Wed, 1 Dec 1999, Jules Bean wrote: > > > I would quite like, personally, a LyX-like program which is a more generic > > > 'structured' document editor. Probably an XML editor, with the ability to > > > backend onto LaTeX, but also other formats. If I have time, I may have a > > > look at that problem. > > As Allan said there are already several steps in that direction in > the docbook support. There are several abstractions that would allow > to make another backend really easy. One example, if anyone has the > time or the energy to do it is a native html backend... Yuck. What an unpleasant idea ;-) Hmm... uh.. depends what you mean by backend, I guess. Certainly, native editing of HTML documents is, IMO, a feature of only slight usefulness - HTML is a horrible format. However, editing in a SGML/XML designed for the purpose and then exporting to HTML would be cool. > > > It will probably be some time before we get a generalised XML/SGML > > editting mode as there are a number of issues related to document > > hierarchy and syntax that we are working through as our support for > > Docbook improves -- changes/extensions of .layout information. The > > changes required for better Docbook support also benefit the LaTeX > > support. > > Something that I'm waiting for are better insets, more generalized, because that's > something that docbook support needs, because eventually everything there is > an inset. > > I think that we also need a way to change a document from latex to > docbook and convert the document structure from one to the other, and > vice versa. That mechanism doesn't exist now. Tricky though, isn't it. I guess there are enough similarities between article.cls and docbook that it could probably be done for articles and related classes. A very hard problem in general, though. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Allan Rae wrote: > On Thu, 2 Dec 1999, Andre' Poenitz wrote: > > > I'd be really interested in some 'test project': Read in an XML file, > > display it nicely *including math*, export it to tex. Just to convince > > me that the second approach is not *much* better than the first ;-) > > If someone were to take this leap I'd suggest getting Asger's kernel first > so you minimised your work. Either that or just start generalising the > docbook support now instead of waiting for the docbook support to be > complete. What's in Asger's kernel? Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Andre' Poenitz wrote: > > > > On Wed, 1 Dec 1999, Jules Bean wrote: > > > I would quite like, personally, a LyX-like program which is a more generic > > > 'structured' document editor. Probably an XML editor, with the ability to > > > backend onto LaTeX, but also other formats. If I have time, I may have a > > > look at that problem. > > > > Don't run off and reinvent the wheel. > > I am actually fully sympathetic with Jules. > > The problem is not 'reinventing the wheel'. That is not necessary. > I have the feeling that most people here share more or less the same > vision of what constitutes a Good Document Processor. Yup. My comments weren't intended to suggest that LyX should be abandoned. They may have been slanted by the fact that I'm not a LyX developer, and I was trying not to sound like it was my decision what happened with the LyX project ;-) > I have to admit that I not yet convinced which one I consider the better, > although I am fairly sure that I'd take the second approach if it were > my work and I had enough resources to spend. I'd be really interested in > some 'test project': Read in an XML file, display it nicely *including math*, > export it to tex. Just to convince me that the second approach is not > *much* better than the first ;-) I was thinking of something along these lines. Actually, I was thinking more of saving a file in XML format, an XML format equivalent to .lyx, and then loading that back in. Note that 'read in an XML file' doesn't mean anything. XML is a file format format, not just a file format ;-). What we need, at the end of the day, is the ability to read in any XML file in any format, and print it to TeX according to an XSL stylesheet. It's not clear if XSL is currently quite ready for prime-time use, though. But even defining a LyX XML format (.lyxml?) would be a significant win. XML formats are easy to parse, and furthermore once lyx is natively using XML it becomes easy to write plugins to do clever things (tm) because XML is designed for manipulation (and, for example, perl and python modules exist to manipulate the groves). Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Special superscript and subscript arrangements
On Thu, Dec 02, 1999 at 12:31:37PM +1000, Allan Rae wrote: > On Wed, 1 Dec 1999, Jules Bean wrote: > > I would quite like, personally, a LyX-like program which is a more generic > > 'structured' document editor. Probably an XML editor, with the ability to > > backend onto LaTeX, but also other formats. If I have time, I may have a > > look at that problem. As Allan said there are already several steps in that direction in the docbook support. There are several abstractions that would allow to make another backend really easy. One example, if anyone has the time or the energy to do it is a native html backend... > Don't run off and reinvent the wheel. LyX is evolving in approximately > that direction although we will almost certainly have two modes of > editting. The well supported LaTeX mode we have now and a generalised > version of the SGML Docbook support. The Docbook side of things isn't so > well supported at present since Jose' is the only one working on that. > I'm sure he'd welcome your assistance. You are more than right here :) > It will probably be some time before we get a generalised XML/SGML > editting mode as there are a number of issues related to document > hierarchy and syntax that we are working through as our support for > Docbook improves -- changes/extensions of .layout information. The > changes required for better Docbook support also benefit the LaTeX > support. Something that I'm waiting for are better insets, more generalized, because that's something that docbook support needs, because eventually everything there is an inset. I think that we also need a way to change a document from latex to docbook and convert the document structure from one to the other, and vice versa. That mechanism doesn't exist now. > Once Docbook is well supported we can then generalise ie. walk before we > can run. > > Allan. (ARRae) -- José
Re: Special superscript and subscript arrangements
On Thu, 2 Dec 1999, Andre' Poenitz wrote: > > On Wed, 1 Dec 1999, Jules Bean wrote: > > > I would quite like, personally, a LyX-like program which is a more generic > > > 'structured' document editor. Probably an XML editor, with the ability to > > > backend onto LaTeX, but also other formats. If I have time, I may have a > > > look at that problem. > > > > Don't run off and reinvent the wheel. > > I am actually fully sympathetic with Jules. So am I, I just don't see much point in starting yet-another-word-processor project when it's possible to improve an existing one. Especially with many if not all the developers of LyX already trying to head LyX in that direction. > The problem is not 'reinventing the wheel'. That is not necessary. > I have the feeling that most people here share more or less the same > vision of what constitutes a Good Document Processor. > > The actual difference are the various ideas of how to get there. > There are advantages and disadvantages with both approaches. [...] > The second is better - once you get through. If you get stuck, > you lose everything. We tried to make a giant leap forward with the previous development branch but with only six or so in the team we couldn't get the momentum to get airborne. Hence the demise of the old branch and the change of plan to a softly softly approach. Lots of little safe steps. At least we can backport the major changes from the old development strand and LyX will evolve over time into the glorious wonder we all want it to become. > I have to admit that I not yet convinced which one I consider the better, > although I am fairly sure that I'd take the second approach if it were > my work and I had enough resources to spend. ...^^^ We didn't. Maybe some more noise and hype might have gotton more people to help out. Admittedly we were taking the trail and turning it into a highway in one go (to butcher your analogies) rather than starting a whole new highway. > I'd be really interested in some 'test project': Read in an XML file, > display it nicely *including math*, export it to tex. Just to convince > me that the second approach is not *much* better than the first ;-) If someone were to take this leap I'd suggest getting Asger's kernel first so you minimised your work. Either that or just start generalising the docbook support now instead of waiting for the docbook support to be complete. > > Once Docbook is well supported we can then generalise ie. walk before we > > can run. > > Allan. (ARRae) > > Well. You do not need to run once you've learned how to fly ;-) Argueably you only get airborne by either running faster or jumping off a cliff. At least if you fail to takeoff while running you still have a life ahead of you ;-) Allan. (ARRae)
Re: Special superscript and subscript arrangements
> > On Wed, 1 Dec 1999, Jules Bean wrote: > > I would quite like, personally, a LyX-like program which is a more generic > > 'structured' document editor. Probably an XML editor, with the ability to > > backend onto LaTeX, but also other formats. If I have time, I may have a > > look at that problem. > > Don't run off and reinvent the wheel. I am actually fully sympathetic with Jules. The problem is not 'reinventing the wheel'. That is not necessary. I have the feeling that most people here share more or less the same vision of what constitutes a Good Document Processor. The actual difference are the various ideas of how to get there. There are - the people who say: look, there is a trail, pave it, broaden it, straighten it, tar it, and look: we have a highway. and - the people who say: come on, let's abandon the trail and build the highway in one step. (and of course - the people who say: well, the trail is fine, I am contend with that.) There are advantages and disadvantages with both approaches. The first approach is costly and lengthy. You repeat work, you pave the trail although you know that you'll throw it away in the end. But every step could be seen as an improvement. You can stop anywhere in the process and still you have gained something. The second is better - once you get through. If you get stuck, you lose everything. I have to admit that I not yet convinced which one I consider the better, although I am fairly sure that I'd take the second approach if it were my work and I had enough resources to spend. I'd be really interested in some 'test project': Read in an XML file, display it nicely *including math*, export it to tex. Just to convince me that the second approach is not *much* better than the first ;-) Andre' PS: > Once Docbook is well supported we can then generalise ie. walk before we > can run. > Allan. (ARRae) Well. You do not need to run once you've learned how to fly ;-) -- Andre' Poenitz .. [EMAIL PROTECTED]
Re: Special superscript and subscript arrangements
On Wed, 1 Dec 1999, Jules Bean wrote: > I would quite like, personally, a LyX-like program which is a more generic > 'structured' document editor. Probably an XML editor, with the ability to > backend onto LaTeX, but also other formats. If I have time, I may have a > look at that problem. Don't run off and reinvent the wheel. LyX is evolving in approximately that direction although we will almost certainly have two modes of editting. The well supported LaTeX mode we have now and a generalised version of the SGML Docbook support. The Docbook side of things isn't so well supported at present since Jose' is the only one working on that. I'm sure he'd welcome your assistance. It will probably be some time before we get a generalised XML/SGML editting mode as there are a number of issues related to document hierarchy and syntax that we are working through as our support for Docbook improves -- changes/extensions of .layout information. The changes required for better Docbook support also benefit the LaTeX support. Once Docbook is well supported we can then generalise ie. walk before we can run. Allan. (ARRae)
Re: Special superscript and subscript arrangements
On Tue, 30 Nov 1999, Seak, Teng-Fong wrote:
> Jean-Marc Lasgouttes wrote:
>
> > Seak,> I just checked that actually \tensor isn't included in
> > Seak,> standard macros in tetex. But if LyX could support things like
> > Seak,> R_i{}^j{}_{kl} it's alright good enough.
> >
> > What about the following? I entered the {} by typing \ {
> >
> > JMarc
> >
> > #This file was created by Tue Nov 30 14:46:10 1999
> > [deleted]
> > \begin_inset Formula \( R_{i}{}^{j}{}_{kl} \)
> > \end_inset
>
> I don't understand quite your question. Maybe we've got some
> misunderstanding :-) Actually, I knew how to enter {}. When I ask Lyx
> to support R_i{}^j{}_{kl}, I wanted in fact LyX not to display the red {}
> to make the tensor look a bit better.
There are two quite orthogonal issues here:
Q: What does LyX *allow* you to enter, to enable you to produce the most
neatly typeset mathematical documents?
A: LyX, by allowing you access to the underlying LaTeX and TeX commands,
allows you to typeset anything at all.
Q: To what extent does LyX make this easier than directly entering the TeX
commands, and how well does it preview it on-screen?
A: There are various limiting factors here:
1) Availability of font characters: LyX uses a set of X-windows fonts.
These have in them some approximation to many of the commonly wanted
characters in mathematical notation, but by no means all of them. LyX will
not be able to support the others without new fonts - and possibly a more
extendable font system.
2) Previewing complex things may not be worth it. TeX is an extremely
complex system, dealing well with a variety of very complex on-page
display issues. It may not be appropriate for LyX to attempt to solve
some of these complex problems independently -- it's only intended to be a
WYSIWYG previewer.
Tangentially to that, there's the more general question of exactly which
job LyX is trying to solve. At the moment (at least for complex
mathmematically documents) LyX is best thought of as a helpful tool for
writing LaTeX, but the author needs to know, or at least be willing to
learn as he goes along, LaTeX in order to acheive more complex effects.
LyX is essentially a LaTeX front-end.
I would quite like, personally, a LyX-like program which is a more generic
'structured' document editor. Probably an XML editor, with the ability to
backend onto LaTeX, but also other formats. If I have time, I may have a
look at that problem.
Jules
/+---+-\
| Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd|
| Jules aka | [EMAIL PROTECTED] | Richmond, Surrey |
| Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* |
++---+-+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\--/
Re: Special superscript and subscript arrangements
> The best would be of course to give a hand to Alejandro so that this > actually happens :) Oh sorry, I'm more a scientist (and an end-user) than a computer scientist. I know how to programme in Fortran, Pascal and Matlab. But in C (or C++), I'm a real novice. If it was written in Fortran, I could help :-)
Re: Special superscript and subscript arrangements
> "Seak," == Seak, Teng-Fong <[EMAIL PROTECTED]> writes: Seak> Of course, I mean in future version of LyX, not the Seak> present one :-) It's for the wish-list and I'm very patient to Seak> wait for this to happen. The best would be of course to give a hand to Alejandro so that this actually happens :) JMarc
Re: Special superscript and subscript arrangements
> Seak> I don't understand quite your question. Maybe we've got
> Seak> some misunderstanding :-) Actually, I knew how to enter {}. When
> Seak> I ask Lyx to support R_i{}^j{}_{kl}, I wanted in fact LyX not to
> Seak> display the red {} to make the tensor look a bit better.
>
> I do not know how to do that...
Of course, I mean in future version of LyX, not the present one :-)
It's for the wish-list and I'm very patient to wait for this to happen.
Re: Special superscript and subscript arrangements
> "Seak" == Seak, Teng-Fong <[EMAIL PROTECTED]> writes:
Seak> I don't understand quite your question. Maybe we've got
Seak> some misunderstanding :-) Actually, I knew how to enter {}. When
Seak> I ask Lyx to support R_i{}^j{}_{kl}, I wanted in fact LyX not to
Seak> display the red {} to make the tensor look a bit better.
I do not know how to do that...
Seak> By the way, LyX always put and expect {} after ^ or _ even
Seak> when it's not necessary. Would this cause problem when someone
Seak> wants to import pieces of latex code containing something like
Seak> R_i instead of R_{i}?
reLyX takes care of this. Mathed in fact uses a strict latex syntax.
JMarc
Re: Special superscript and subscript arrangements
> By the way, LyX always put and expect {} after ^ or _ even when it's
> not necessary. Would this cause problem when someone wants to import
> pieces of latex code containing something like R_i instead of R_{i}?
If you 'import' LaTeX by editing .lyx files you have to make sure to
put everything into {}. Otherwise it is taken care of 'automatically' ;-)
Andre'
--
Andre' Poenitz .. [EMAIL PROTECTED]
Re: Special superscript and subscript arrangements
Jean-Marc Lasgouttes wrote:
> Seak,> I just checked that actually \tensor isn't included in
> Seak,> standard macros in tetex. But if LyX could support things like
> Seak,> R_i{}^j{}_{kl} it's alright good enough.
>
> What about the following? I entered the {} by typing \ {
>
> JMarc
>
> #This file was created by Tue Nov 30 14:46:10 1999
> [deleted]
> \begin_inset Formula \( R_{i}{}^{j}{}_{kl} \)
> \end_inset
I don't understand quite your question. Maybe we've got some
misunderstanding :-) Actually, I knew how to enter {}. When I ask Lyx
to support R_i{}^j{}_{kl}, I wanted in fact LyX not to display the red {}
to make the tensor look a bit better.
By the way, LyX always put and expect {} after ^ or _ even when it's
not necessary. Would this cause problem when someone wants to import
pieces of latex code containing something like R_i instead of R_{i}?
Re: Special superscript and subscript arrangements
> "Seak," == Seak, Teng-Fong <[EMAIL PROTECTED]> writes:
Seak,> "Seak, Teng-Fong" wrote:
>> o When we want to write tensors in Einstein's notation, we could
>> write it in latex in this way, R_i{}^j{}_{kl} so that subscripts
>> and superscripts won't be rearranged together. This time, I found
>> out how to insert the {} (by the red TeX button) :-) but LyX
>> couldn't process it correctly. Maybe the same problem as \dj{}
>> mentioned in "Known Bugs"?
>>
>> By the way, there is macro to do the same thing. For the same
>> tensor, it's written in this way: \tensor{R}{_i^j_{kl}}
>>
>> Maybe LyX can be programmed to handle this too?
Seak,> I just checked that actually \tensor isn't included in
Seak,> standard macros in tetex. But if LyX could support things like
Seak,> R_i{}^j{}_{kl} it's alright good enough.
What about the following? I entered the {} by typing \ {
JMarc
#This file was created by Tue Nov 30 14:46:10 1999
#LyX 1.0 (C) 1995-1999 Matthias Ettrich and the LyX Team
\lyxformat 2.15
\textclass article
\language default
\inputencoding default
\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
\begin_inset Formula \( R_{i}{}^{j}{}_{kl} \)
\end_inset
\the_end
Re: Special superscript and subscript arrangements
"Seak, Teng-Fong" wrote:
> oWhen we want to write tensors in Einstein's notation, we could
> write it in latex in this way, R_i{}^j{}_{kl} so that subscripts and
> superscripts won't be rearranged together. This time, I found out how
> to insert the {} (by the red TeX button) :-) but LyX couldn't process it
> correctly. Maybe the same problem as \dj{} mentioned in "Known Bugs"?
>
> By the way, there is macro to do the same thing. For the same
> tensor, it's written in this way: \tensor{R}{_i^j_{kl}}
>
> Maybe LyX can be programmed to handle this too?
I just checked that actually \tensor isn't included in standard macros
in tetex. But if LyX could support things like R_i{}^j{}_{kl} it's alright
good enough.
Seak
Special superscript and subscript arrangements
oWhen we want to write tensors in Einstein's notation, we could
write it in latex in this way, R_i{}^j{}_{kl} so that subscripts and
superscripts won't be rearranged together. This time, I found out how
to insert the {} (by the red TeX button) :-) but LyX couldn't process it
correctly. Maybe the same problem as \dj{} mentioned in "Known Bugs"?
By the way, there is macro to do the same thing. For the same
tensor, it's written in this way: \tensor{R}{_i^j_{kl}}
Maybe LyX can be programmed to handle this too?
o Superscripts and subscripts are usual put on the right of variable.
But in atomic notations, eg, they are put to the left. There's no
problem to insert them (just type them). The following lyx example
illustrates this:
\begin_inset Formula \( ^{235}_{92}U+^{1}_{0}n\rightarrow
^{236}_{92}U\rightarrow \ldots \)
\end_inset
However, I wonder if LaTeX (or LyX) allows us to right-adjust those
numbers. For the moment, they're left-adjusted by defaults. Therefore,
I should add in predefined spaces provided by the math-panel. But as
you could imagine, the result is only _approximatively_ right adjusted.
Regards
Seak T.F.
