Re: lyx file format changes
Amir Karger wrote:
On Thu, Aug 09, 2001 at 08:29:07AM +0200, Andre Poenitz wrote:
- LaTeX things LyX can't do: my favorite example is \section[foo]{bar},
which is supposedly going to be supported someday.
Even the old mathed read \sqrt[3]{x} so I guess it is possible...
Oh, it's definitely possible. The problem with \section is that people
haven't decided (AFAIK) on a GUI way to represent that a section should have
a different title in the TOC, which is what \section[foo] does.
The obvious GUI way for (at least for someone who don't know
latex already) is to let them edit the TOC directly, changing the
names as they see fit.
This might make it harder to see what the TOC refers to, so
maybe displaying the [foo] part in the section text makes sense.
Perhaps with a different color to distingusih it from the stuff
that actually will print. This is also friendlier to latex
experts.
Helge Hafting
Re: lyx file format changes
Amir Karger wrote:
>
> On Thu, Aug 09, 2001 at 08:29:07AM +0200, Andre Poenitz wrote:
> >
> > > - LaTeX things LyX can't do: my favorite example is \section[foo]{bar},
> > > which is supposedly going to be supported someday.
> >
> > Even the old mathed read \sqrt[3]{x} so I guess it is possible...
>
> Oh, it's definitely possible. The problem with \section is that people
> haven't decided (AFAIK) on a GUI way to represent that a section should have
> a different title in the TOC, which is what \section[foo] does.
The obvious GUI way for (at least for someone who don't know
latex already) is to let them edit the TOC directly, changing the
names as they see fit.
This might make it harder to see what the TOC refers to, so
maybe displaying the [foo] part in the section text makes sense.
Perhaps with a different color to distingusih it from the stuff
that actually will print. This is also friendlier to latex
experts.
Helge Hafting
Re: lyx file format changes
be able to get rid of the reLyXmt{} in syntax.defaults. (Actually, you
shouldn't get rid of it, since people might want to put their own personal
commands in there that aren't supported by Mathed.
If people wants support for something that is not yet in mathed they should
tell me (in simple words ...) and I'll try to get it in there. Native
support is inherently better than reLyX support, since reLyX is usually run
only once and changes for proper visual feedback on screen are slim...
Andre'
There are actually several *classes* of reLyX problems:
- new LyX features, as above
- things not supported by reLyX guts: Text::TeX (which is very very old and
I changed only a bit from the v0.01 I got from CPAN) doesn't support
anything very complicated in [], for example, which means you can lose
stuff.
PS:
- LaTeX things LyX can't do: my favorite example is \section[foo]{bar},
which is supposedly going to be supported someday.
Even the old mathed read \sqrt[3]{x} so I guess it is possible...
--
André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
Herbert Voss [EMAIL PROTECTED] writes: why should I do a lyx-latex-lyx cycle? You need it if you work on a document with a coauthor which doesn't have LyX. this is the only reason?? It is the only reason for doing the cycle I can see. Having said that, interoperability in general is a pretty good reason, I think. A lot of texts I work with are written in LaTeX, not in LyX (and they are not even written by me :-)). So a decent import facility is important to me (with Lyx 1.1.5 is works quite ok). If the full cycle works correctly, it is just a sign of the latex import being well done. Concerning the aspects of a lyx document that do not appear in the latex file, I think they are of minor importance. Maybe a merge would be useful: take these from the old lyx document, and the text from latex. Thomas [EMAIL PROTECTED] -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: lyx file format changes
On Wed, 8 Aug 2001, Andre Poenitz wrote: I wonder whether the situation would improve once we had (a) a decent document structure and (b) the reLyX code in C++. I think there are not many things in reLyX that cant' be done in C++ and - that's the point - there are more developers that know C++ than perl. Three years ago, it would have been a mistake to reimplement reLyX in C++, because C++ did not have proper regex-support. However, now we include Boost in LyX, and Boost has an excellent regex-package. It's as capable as the Perl regexps. Therefore, I think it would make sense to reimplement reLyX in C++ now. Advantages: - Yet another dependency bites the dust - More developers can work on the code - We get more control, and can provide better error handling because we are close to the real data structure. For instance, it will be simpler to insert error boxes where we get stuff that we can't grok. - If done properly, a C++ LaTeX parser would be a nice contribution to the world in general Disadvantage: - It's arguably faster to develop code in Python - Some people know Python, but not C++ Greets, Asger
Re: lyx file format changes
On Thu, Aug 09, 2001 at 08:19:56AM +0200, Andre Poenitz wrote: The conversion is important. Perhaps the problem is that there aren't many developers which know perl well. Um, I do. I program perl python for a living. Is there a bug / feature request for reLyx anywhere? I could have a poke around and see what I can do. You could try to figure out what kind of math related things reLyX does and I'll try to improve the parser so that kind of magic is not needed anymore. how about thre \protect thing for fragile stuff that was discussed recently. Michael, there are a few reLyX bugs at the sourceforge tracker you might want to look at (change category to reLyX to see them) regards john -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. - Matthew Lammers
Re: lyx file format changes
> be able to get rid of the reLyXmt{} in syntax.defaults. (Actually, you
> shouldn't get rid of it, since people might want to put their own personal
> commands in there that aren't supported by Mathed.
If people wants support for something that is not yet in mathed they should
tell me (in simple words ...) and I'll try to get it in there. "Native"
support is inherently better than reLyX support, since reLyX is usually run
only once and changes for proper visual feedback on screen are slim...
Andre'
> There are actually several *classes* of reLyX problems:
>
> - new LyX features, as above
> - things not supported by reLyX guts: Text::TeX (which is very very old and
> I changed only a bit from the v0.01 I got from CPAN) doesn't support
> anything very complicated in [], for example, which means you can lose
> stuff.
PS:
> - LaTeX things LyX can't do: my favorite example is \section[foo]{bar},
> which is supposedly going to be supported someday.
Even the old mathed read \sqrt[3]{x} so I guess it is possible...
--
André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
Herbert Voss <[EMAIL PROTECTED]> writes: >>> why should I do a lyx->latex->lyx cycle? >> >> You need it if you work on a document with a coauthor which doesn't have LyX. > > this is the only reason?? It is the only reason for doing the cycle I can see. Having said that, interoperability in general is a pretty good reason, I think. A lot of texts I work with are written in LaTeX, not in LyX (and they are not even written by me :-)). So a decent import facility is important to me (with Lyx 1.1.5 is works quite ok). If the full cycle works correctly, it is just a sign of the latex import being well done. Concerning the aspects of a lyx document that do not appear in the latex file, I think they are of minor importance. Maybe a "merge" would be useful: take these from the old lyx document, and the text from latex. Thomas <[EMAIL PROTECTED]> -- Umweltfreundlich, da aus recycleten Buchstaben.
Re: lyx file format changes
On Wed, 8 Aug 2001, Andre Poenitz wrote: > I wonder whether the situation would improve once we had (a) a decent > document structure and (b) the reLyX code in C++. > > I think there are not many things in reLyX that cant' be done in C++ and > - that's the point - there are more developers that know C++ than perl. Three years ago, it would have been a mistake to reimplement reLyX in C++, because C++ did not have proper regex-support. However, now we include Boost in LyX, and Boost has an excellent regex-package. It's as capable as the Perl regexps. Therefore, I think it would make sense to reimplement reLyX in C++ now. Advantages: - Yet another dependency bites the dust - More developers can work on the code - We get more control, and can provide better error handling because we are close to the real data structure. For instance, it will be simpler to insert error boxes where we get stuff that we can't grok. - If done properly, a C++ LaTeX parser would be a nice contribution to the world in general Disadvantage: - It's arguably faster to develop code in Python - Some people know Python, but not C++ Greets, Asger
Re: lyx file format changes
On Thu, Aug 09, 2001 at 08:19:56AM +0200, Andre Poenitz wrote: > > >The conversion is important. Perhaps the problem is that there aren't > > >many developers which know perl well. > > > > Um, I do. I program perl & python for a living. Is there a bug / > > feature request for reLyx anywhere? I could have a poke around and see > > what I can do. > > You could try to figure out what kind of math related things reLyX does > and I'll try to improve the parser so that kind of magic is not needed > anymore. how about thre \protect thing for fragile stuff that was discussed recently. Michael, there are a few reLyX bugs at the sourceforge tracker you might want to look at (change category to "reLyX" to see them) regards john -- "They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them." - Matthew Lammers
Re: lyx file format changes
On 07-Aug-2001 Lars Gullik Bjønnes wrote: We gain close to nothing by having the LyX format be latex. Let away the close to and I can agree with the above! And this will be the last mail on this subject from my part I don't go that path down again. People should studdy the mailing list archive on this subject and they will have a lot to read there, to keep them busy for a while and maybe they then change to fixing bugs instead of keeping developers busy with already multiple discussed bla, bla, ... Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I once witnessed a long-winded, month-long flamewar over the use of mice vs. trackballs...It was very silly. (By Matt Welsh)
Re: lyx file format changes
We gain close to nothing by having the LyX format be latex. Let away the close to and I can agree with the above! close to is fine. It's easier to convert LaTeX diehards with a file format they know. But in general, both of you are right... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On Tue, Aug 07, 2001 at 06:46:55PM +0200, Lars Gullik Bjønnes wrote: We gain close to nothing by having the LyX format be latex. The main problem we currently have is that reLyX is almost not maintained. Since we are continuously adding new features to LyX, reLyX stays behind, so a lyx-latex-lyx cycle can loose information. For example, reLyX doesn't support multi-lingual commands, longtables, multiple paragraphs in a table cell, natbib commands (\citet), \prettyref etc.
Re: lyx file format changes
On Wed, Aug 08, 2001 at 03:24:18PM +0300, Dekel Tsur wrote: On Tue, Aug 07, 2001 at 06:46:55PM +0200, Lars Gullik Bjønnes wrote: We gain close to nothing by having the LyX format be latex. The main problem we currently have is that reLyX is almost not maintained. Since we are continuously adding new features to LyX, reLyX stays behind, so a lyx-latex-lyx cycle can loose information. I wonder whether the situation would improve once we had (a) a decent document structure and (b) the reLyX code in C++. I think there are not many things in reLyX that cant' be done in C++ and - that's the point - there are more developers that know C++ than perl. The mathed parser is certainly crap, but it shows that one could parse LaTeX(ish) input in C++. Andre' PS: I know that reLyX does a bit more than parsing alone... -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On Wed, Aug 08, 2001 at 02:30:12PM +0200, Lars Gullik Bjønnes wrote: | The main problem we currently have is that reLyX is almost not | maintained. Then obviously the conversion from latex to lyx is not that important... at least not important for someone to step up and do the work. The conversion is important. Perhaps the problem is that there aren't many developers which know perl well. | Since we are continuously adding new features to LyX, reLyX stays behind, | so a lyx-latex-lyx cycle can loose information. And it probably always will. LyX _is_ more than a latex editor. I disagree. This cycle should give you identical .lyx files (when you are using a latex document class). | For example, reLyX doesn't support multi-lingual commands, longtables, | multiple paragraphs in a table cell, natbib commands (\citet), \prettyref | etc. Feel free to provide patches. See above...
Re: lyx file format changes
On Wed, Aug 08, 2001 at 10:18:25AM +0200, Lars Gullik Bjønnes wrote: | BTW, why 2-4 should be stored in the lyx file ? | It is more reasonable to have them in the layout file. No, never in the layout file. Why not ? I guess that the question is whether we store information about the appearance of the document in the document itself, or in an external file (layout file) ? The former is better if you want to write many documents using the same style.
Re: lyx file format changes
Lars Gullik Bjønnes wrote: Dekel Tsur [EMAIL PROTECTED] writes: | On Wed, Aug 08, 2001 at 02:30:12PM +0200, Lars Gullik Bjønnes wrote: | | The main problem we currently have is that reLyX is almost not | | maintained. | | Then obviously the conversion from latex to lyx is not that | important... at least not important for someone to step up and do the | work. | | The conversion is important. to whom? it's obviously that la(tex)-lyx is a nice thing, but tell me the users who really(!) need this way of conversion. | | Since we are continuously adding new features to LyX, reLyX stays behind, | | so a lyx-latex-lyx cycle can loose information. as I said: from a users sight lyx-latex is only important to find critical errors or to convert some stuff to whatelse ever. why should I do a lyx-latex-lyx cycle? | And it probably always will. | LyX _is_ more than a latex editor. some more information please?? | I disagree. This cycle should give you identical .lyx files (when you are | using a latex document class). no! for a user it's not important to get the same lyx file. users are interested in the same output, which is not the same. | Feel free to provide patches. | | See above... no patches there... :-) there is no known converter from ???-(La)TeX which works well, means: it does all! Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
On Wed, Aug 08, 2001 at 03:01:22PM +0200, Lars Gullik Bjønnes wrote: Ok, document specific words that the spellchecker should ignore? How will you store those in the latex document? %% LyX local words %% bla, lir, foo, var ?? sure relyx can handle this, but I stil claim that the resulting format is not really latex anymore. So what? | | For example, reLyX doesn't support multi-lingual commands, longtables, | | multiple paragraphs in a table cell, natbib commands (\citet), \prettyref | | etc. | | Feel free to provide patches. | | See above... no patches there... If only reLyX was written in python...
Re: lyx file format changes
On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: | | Since we are continuously adding new features to LyX, reLyX stays behind, | | so a lyx-latex-lyx cycle can loose information. as I said: from a users sight lyx-latex is only important to find critical errors or to convert some stuff to whatelse ever. why should I do a lyx-latex-lyx cycle? You need it if you work on a document with a coauthor which doesn't have LyX.
Re: lyx file format changes
to whom? it's obviously that la(tex)-lyx is a nice thing, but tell me the users who really(!) need this way of conversion. Everybody co-operating with LyXless LaTeX users. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
Dekel Tsur wrote: On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: | | Since we are continuously adding new features to LyX, reLyX stays behind, | | so a lyx-latex-lyx cycle can loose information. as I said: from a users sight lyx-latex is only important to find critical errors or to convert some stuff to whatelse ever. why should I do a lyx-latex-lyx cycle? You need it if you work on a document with a coauthor which doesn't have LyX. this is the only reason?? Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
You need it if you work on a document with a coauthor which doesn't have LyX. this is the only reason?? That's a pretty good reason. I won't get food if this breaks... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On Wed, Aug 08, 2001 at 04:43:42PM +0300, Dekel Tsur wrote: no patches there... If only reLyX was written in python... Go ahead. Rewrite it in Algol if it will help. :-) Most of my time on LyX is spent on the Literate support, various bug fixes and the spec file right now. I will probably look again at reLyX once things have stabilized a bit more (ERT inset, new file formats, etc). Meanwhile, if you want to help with it (or even redo it), go ahead! ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: lyx file format changes
On Wed, Aug 08, 2001 at 04:48:19PM +0200, Lars Gullik Bjønnes wrote: Dekel Tsur [EMAIL PROTECTED] writes: | Why not ? | | I guess that the question is whether we store information about the | appearance of the document in the document itself, or in an external file | (layout file) ? | The former is better if you want to write many documents using the | same style. and when you send the lyx file to someone without that (modified) layoutfile? So you send both files.
Re: lyx file format changes
Herbert Voss wrote: Dekel Tsur wrote: On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: | | Since we are continuously adding new features to LyX, reLyX stays behind, | | so a lyx-latex-lyx cycle can loose information. as I said: from a users sight lyx-latex is only important to find critical errors or to convert some stuff to whatelse ever. why should I do a lyx-latex-lyx cycle? You need it if you work on a document with a coauthor which doesn't have LyX. this is the only reason?? Last week I had to write a largish document in raw LaTeX for precisely this reason. Anyway, there's also this related scenario: you need to make some changes to your document on somebody else's computer. You don't have LyX 1.2.x installed, so you edit the exported LaTeX. Later back home, you struggle to spot all the changes and retype them into LyX. Regards, Eran Tromer
Re: lyx file format changes
On Wed, Aug 08, 2001 at 05:23:31PM +0200, Lars Gullik Bjønnes wrote: | | I guess that the question is whether we store information about the | | appearance of the document in the document itself, or in an external file | | (layout file) ? | | The former is better if you want to write many documents using the | | same style. | | and when you send the lyx file to someone without that (modified) layoutfile? | | So you send both files. And then what is the point in standarized layout files? The article.layout etc. files are for the environments/commands defined by the standard .cls files, and they should not be changed by the user. The user layout files are for defining new environments/commands or changing already defined environments/commands.
Re: lyx file format changes
On Wed, Aug 08, 2001 at 06:17:00PM +0200, Lars Gullik Bjønnes wrote: | The article.layout etc. files are for the environments/commands defined by the | standard .cls files, and they should not be changed by the user. But I want my own defined floats while still using the article.layout. Should lyx then magiacally copy the original article.layout to become a user layout file? No. First, the article.layout is read, and then the user layout file is read. (the styles that are defined in article.layout are not repeated in the user layout file) | The user layout files are for defining new environments/commands | or changing already defined environments/commands. but we have no such thing. But eventually we will
Re: lyx file format changes
Eran Tromer wrote: Herbert Voss wrote: Dekel Tsur wrote: On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: | | Since we are continuously adding new features to LyX, reLyX stays behind, | | so a lyx-latex-lyx cycle can loose information. as I said: from a users sight lyx-latex is only important to find critical errors or to convert some stuff to whatelse ever. why should I do a lyx-latex-lyx cycle? You need it if you work on a document with a coauthor which doesn't have LyX. this is the only reason?? Last week I had to write a largish document in raw LaTeX for precisely this reason. Anyway, there's also this related scenario: you need to make some changes to your document on somebody else's computer. You don't have LyX 1.2.x installed, so you edit the exported LaTeX. Later back home, you struggle to spot all the changes and retype them into LyX. in this case it's absolutely no problem to do it in latex, for both. again: since 1985 a lot of people tried to write converters from and to tex. all failed, especially for TeX-???, because tex is a kind of programming language, which can be enhanced just as you like it. so you don't have a fixed standard. I agree with Lars: if somebody updates reLyX, it will be great ... but a soon released 1.2.0 without any bugs is much more greater ... Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
Andre Poenitz a écrit : - formula were not XML-ised at all (It looked a bit harder and somebody was reorganizing the code : is it over ?) About this, I know that Jose is in vacations, but does someone know if it is planned to have math formulas translated to MathML when a DocBook file is exported to SGML (I know, it's a bit off topic)? It is planned. But don't expect anything to soon. And I am not sure whether we will see proper semantical markup at all... What do you mean with semantical markup? Is it about the MathML content tags? If so I agree that presentational markups are maybe enough. BG
Re: lyx file format changes
On Tue, Aug 07, 2001 at 03:25:04PM +0300, Dekel Tsur wrote: On Mon, Aug 06, 2001 at 12:27:36PM +0100, John Levon wrote: I'd really like to see an XML format for 1.3 ... as it would make things much easier to convert in the future ... Personally, I think it best to have lyx store its files as a valid latex files (using latex comments for storing some information). I know that this has been discussed before. What were the arguments against it ? (complexity of the parser?) Actually, XML is driven, in part, by the scientific community trying to come up with a successor to HTML that does everything that LaTeX/TeX has done for them, while leaving room for expansion in the future. And, there are plans for crafting an XSL that converts XML+MathML into LaTeX. So, you get both. Vis-a-vis MathML: we don't need to specify/support both syntactic and contextual formats. And that's why the two flavors of MathML exist: use only what makes sense for your application. And that's what LyX should do. (See my other emails on this point.) -- John Weiss Not through coercion. Not by force. But by compassion. By affection. And, a small fish. -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
On Tue, Aug 07, 2001 at 10:17:58AM +0200, Lars Gullik Bjønnes wrote: John Weiss [EMAIL PROTECTED] writes: | Having recently done an XML seminar at work, I can offer the following | to the discussion: [snip!] | | For well-formed, think lex. For valid, think yacc. And for this would would need a DTD right? NoNoNo, you misunderstand. When someone says, Well-formed XML, they mean the equivalent of, It will lex (tokenize) error-free and follows an absolutely primitive, lowest-common-denominator grammar. When they say, valid XML, they mean, It will yacc (follow a grammar) error free for the particular application it was written for. So we will have a format that conform to the LyX parser... that is really only Well-Formed XML, right? Oh, no. It follows a grammar: the LyX grammar. As long as a file follows that grammar, error free, it's also valid XML. (We might create a DTD later, but in the beginning this will only create more work.) The DTD/XSL comes in when you document that grammar. Hey, you could document the LyX file format's grammar in Danish if you wished, but using SGML DTD or XSL will be more concise. After all, SGML DTD and XSL were designed to document grammars, and both can be used to document XML grammars. The only other natural format for documenting grammars is a (heavily commented) yacc-file. I'll take XSL over that, any day. If your DTD happens to be in the format described in the XML standard (or if you use XSL), then the LyX file format is instantly portable! We can even use an XML engine to convert the LyX format into LaTeX. (That's one of the plans for XML, BTW.) I do not agree that we should do this from the beginning... we will most likely need several iterations before we are satisfied with the xml format, and I think it will be a lot easier to create the DTD afterwards. Of course we'll do several iterations. What, you eat your steaks by swallowing them whole? You don't slice into bits and chew? We can do both design and DTD simultaneously. When we need a new cell or block or attribute, we'll end up discussing it, won't we? Well, there are four ways to have that discussion: - In English (the imprecise Lingua Franca of the developer's list) - In yacc-format - In an SGML-DTD-like format. - In an XSL-like format. The latter is really flexible; I could teach it to y'all quickly. After the discussion settles down, and we agree upon a format for the new feature, I can take the email thread and clean up the XSL-like chat into real XSL. Won't take long. Then, voila! we have a grammar specification that makes the LyX XML file format portable. I think it's doable. I think it's doable without any extra effort. We just need to start out on the right foot. -- John Weiss Not through coercion. Not by force. But by compassion. By affection. And, a small fish. -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
On Wed, Aug 08, 2001 at 12:22:21AM +0200, ben wrote: John Weiss a écrit : Once we do design an XML-based LyX format, I suggest we document the format using XSL. There's no magic around XSL: it's just an XML document that uses a format designed for defining other XML formats. I'll even volunteer to work on it (I'd like to improve my XML skills). Your XSL definition is too restricted: you can do any transformation Of course it's restricted! There's wy to much hype around XML/XSL, too much misunderstanding. I can't really point out that XSL really isn't as bad as you think if I whomp everyone over the head with a full-blown, complicated description of everything XSL does. Better to start with a description of what it can do *for* *us*! After all, that's what really matters. -- John Weiss Not through coercion. Not by force. But by compassion. By affection. And, a small fish. -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
What do you mean with semantical markup? Is it about the MathML content tags? Yes. If so I agree that presentational markups are maybe enough. Depends on intended usage... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On 07-Aug-2001 Lars Gullik Bjønnes wrote: > We gain close to nothing by having the LyX format be latex. Let away the "close to" and I can agree with the above! And this will be the last mail on this subject from my part I don't go that path down again. People should studdy the mailing list archive on this subject and they will have a lot to read there, to keep them busy for a while and maybe they then change to fixing bugs instead of keeping developers busy with already multiple discussed "bla, bla, ..." Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "I once witnessed a long-winded, month-long flamewar over the use of mice vs. trackballs...It was very silly." (By Matt Welsh)
Re: lyx file format changes
> > We gain close to nothing by having the LyX format be latex. > > Let away the "close to" and I can agree with the above! "close to" is fine. It's easier to convert LaTeX diehards with a file format they know. But in general, both of you are right... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On Tue, Aug 07, 2001 at 06:46:55PM +0200, Lars Gullik Bjønnes wrote: > > We gain close to nothing by having the LyX format be latex. The main problem we currently have is that reLyX is almost not maintained. Since we are continuously adding new features to LyX, reLyX stays behind, so a lyx->latex->lyx cycle can loose information. For example, reLyX doesn't support multi-lingual commands, longtables, multiple paragraphs in a table cell, natbib commands (\citet), \prettyref etc.
Re: lyx file format changes
On Wed, Aug 08, 2001 at 03:24:18PM +0300, Dekel Tsur wrote: > On Tue, Aug 07, 2001 at 06:46:55PM +0200, Lars Gullik Bjønnes wrote: > > > > We gain close to nothing by having the LyX format be latex. > > The main problem we currently have is that reLyX is almost not maintained. > Since we are continuously adding new features to LyX, reLyX stays behind, > so a lyx->latex->lyx cycle can loose information. I wonder whether the situation would improve once we had (a) a decent document structure and (b) the reLyX code in C++. I think there are not many things in reLyX that cant' be done in C++ and - that's the point - there are more developers that know C++ than perl. The mathed parser is certainly crap, but it shows that one could parse LaTeX(ish) input in C++. Andre' PS: I know that reLyX does a bit more than parsing alone... -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On Wed, Aug 08, 2001 at 02:30:12PM +0200, Lars Gullik Bjønnes wrote: > | The main problem we currently have is that reLyX is almost not > | maintained. > > Then obviously the conversion from latex to lyx is not that > important... at least not important for someone to step up and do the > work. The conversion is important. Perhaps the problem is that there aren't many developers which know perl well. > | Since we are continuously adding new features to LyX, reLyX stays behind, > | so a lyx->latex->lyx cycle can loose information. > > And it probably always will. > LyX _is_ more than a latex editor. I disagree. This cycle should give you identical .lyx files (when you are using a latex document class). > | For example, reLyX doesn't support multi-lingual commands, longtables, > | multiple paragraphs in a table cell, natbib commands (\citet), \prettyref > | etc. > > Feel free to provide patches. See above...
Re: lyx file format changes
On Wed, Aug 08, 2001 at 10:18:25AM +0200, Lars Gullik Bjønnes wrote:
> | BTW, why 2-4 should be stored in the lyx file ?
> | It is more reasonable to have them in the layout file.
>
> No, never in the layout file.
Why not ?
I guess that the question is whether we store information about the
appearance of the document in the document itself, or in an external file
("layout file") ?
The former is better if you want to write many documents using the same style.
Re: lyx file format changes
Lars Gullik Bjønnes wrote: > > Dekel Tsur <[EMAIL PROTECTED]> writes: > > | On Wed, Aug 08, 2001 at 02:30:12PM +0200, Lars Gullik Bjønnes wrote: > | > | The main problem we currently have is that reLyX is almost not > | > | maintained. > | > > | > Then obviously the conversion from latex to lyx is not that > | > important... at least not important for someone to step up and do the > | > work. > | > | The conversion is important. to whom? it's obviously that la(tex)->lyx is a nice thing, but tell me the users who really(!) need this way of conversion. > | > | Since we are continuously adding new features to LyX, reLyX stays behind, > | > | so a lyx->latex->lyx cycle can loose information. as I said: from a users sight lyx->latex is only important to find critical errors or to convert some stuff to whatelse ever. why should I do a lyx->latex->lyx cycle? > | > And it probably always will. > | > LyX _is_ more than a latex editor. some more information please?? > | I disagree. This cycle should give you identical .lyx files (when you are > | using a latex document class). no! for a user it's not important to get the same lyx file. users are interested in the same output, which is not the same. > | > Feel free to provide patches. > | > | See above... > > no patches there... :-) there is no known converter from ???->(La)TeX which works well, means: it does all! Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
On Wed, Aug 08, 2001 at 03:01:22PM +0200, Lars Gullik Bjønnes wrote: > > Ok, document specific words that the spellchecker should ignore? > How will you store those in the latex document? > > %% LyX local words > %% bla, lir, foo, var > > ?? > > sure relyx can handle this, but I stil claim that the resulting format > is not really latex anymore. So what? > | > | For example, reLyX doesn't support multi-lingual commands, longtables, > | > | multiple paragraphs in a table cell, natbib commands (\citet), \prettyref > | > | etc. > | > > | > Feel free to provide patches. > | > | See above... > > no patches there... If only reLyX was written in python...
Re: lyx file format changes
On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: > > | > | Since we are continuously adding new features to LyX, reLyX stays behind, > > | > | so a lyx->latex->lyx cycle can loose information. > > as I said: from a users sight lyx->latex is only important > to find critical errors or to convert some stuff to whatelse > ever. > why should I do a lyx->latex->lyx cycle? You need it if you work on a document with a coauthor which doesn't have LyX.
Re: lyx file format changes
> to whom? it's obviously that la(tex)->lyx is a nice thing, > but tell me the users who really(!) need this way of > conversion. Everybody co-operating with LyXless LaTeX users. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
Dekel Tsur wrote: > > On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: > > > | > | Since we are continuously adding new features to LyX, reLyX stays behind, > > > | > | so a lyx->latex->lyx cycle can loose information. > > > > as I said: from a users sight lyx->latex is only important > > to find critical errors or to convert some stuff to whatelse > > ever. > > why should I do a lyx->latex->lyx cycle? > > You need it if you work on a document with a coauthor which doesn't have LyX. this is the only reason?? Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
> > You need it if you work on a document with a coauthor which doesn't have LyX. > > this is the only reason?? That's a pretty good reason. I won't get food if this breaks... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On Wed, Aug 08, 2001 at 04:43:42PM +0300, Dekel Tsur wrote: > > no patches there... > > If only reLyX was written in python... Go ahead. Rewrite it in Algol if it will help. :-) Most of my time on LyX is spent on the Literate support, various bug fixes and the spec file right now. I will probably look again at reLyX once things have stabilized a bit more (ERT inset, new file formats, etc). Meanwhile, if you want to help with it (or even redo it), go ahead! ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: lyx file format changes
On Wed, Aug 08, 2001 at 04:48:19PM +0200, Lars Gullik Bjønnes wrote:
> Dekel Tsur <[EMAIL PROTECTED]> writes:
> | Why not ?
> |
> | I guess that the question is whether we store information about the
> | appearance of the document in the document itself, or in an external file
> | ("layout file") ?
> | The former is better if you want to write many documents using the
> | same style.
>
> and when you send the lyx file to someone without that (modified) layoutfile?
So you send both files.
Re: lyx file format changes
Herbert Voss wrote: > > Dekel Tsur wrote: > > > > On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: > > > > | > | Since we are continuously adding new features to LyX, reLyX stays behind, > > > > | > | so a lyx->latex->lyx cycle can loose information. > > > > > > as I said: from a users sight lyx->latex is only important > > > to find critical errors or to convert some stuff to whatelse > > > ever. > > > why should I do a lyx->latex->lyx cycle? > > > > You need it if you work on a document with a coauthor which doesn't have LyX. > > this is the only reason?? Last week I had to write a largish document in raw LaTeX for precisely this reason. Anyway, there's also this related scenario: you need to make some changes to your document on somebody else's computer. You don't have LyX 1.2.x installed, so you edit the exported LaTeX. Later back home, you struggle to spot all the changes and retype them into LyX. Regards, Eran Tromer
Re: lyx file format changes
On Wed, Aug 08, 2001 at 05:23:31PM +0200, Lars Gullik Bjønnes wrote:
> | > | I guess that the question is whether we store information about the
> | > | appearance of the document in the document itself, or in an external file
> | > | ("layout file") ?
> | > | The former is better if you want to write many documents using the
> | > | same style.
> | >
> | > and when you send the lyx file to someone without that (modified) layoutfile?
> |
> | So you send both files.
>
> And then what is the point in "standarized" layout files?
The article.layout etc. files are for the environments/commands defined by the
standard .cls files, and they should not be changed by the user.
The "user layout" files are for defining new environments/commands or changing
already defined environments/commands.
Re: lyx file format changes
On Wed, Aug 08, 2001 at 06:17:00PM +0200, Lars Gullik Bjønnes wrote: > | The article.layout etc. files are for the environments/commands defined by the > | standard .cls files, and they should not be changed by the user. > > But I want my own defined floats while still using the article.layout. > > Should lyx then magiacally copy the original article.layout to become > a "user layout" file? No. First, the article.layout is read, and then the "user layout" file is read. (the styles that are defined in article.layout are not repeated in the user layout file) > | The "user layout" files are for defining new environments/commands > | or changing already defined environments/commands. > > but we have no such thing. But eventually we will
Re: lyx file format changes
Eran Tromer wrote: > > Herbert Voss wrote: > > > > Dekel Tsur wrote: > > > > > > On Wed, Aug 08, 2001 at 03:46:07PM +0200, Herbert Voss wrote: > > > > > | > | Since we are continuously adding new features to LyX, reLyX stays >behind, > > > > > | > | so a lyx->latex->lyx cycle can loose information. > > > > > > > > as I said: from a users sight lyx->latex is only important > > > > to find critical errors or to convert some stuff to whatelse > > > > ever. > > > > why should I do a lyx->latex->lyx cycle? > > > > > > You need it if you work on a document with a coauthor which doesn't have LyX. > > > > this is the only reason?? > > Last week I had to write a largish document in raw LaTeX for precisely > this reason. > > Anyway, there's also this related scenario: you need to make some > changes to your document on somebody else's computer. You don't have LyX > 1.2.x installed, so you edit the exported LaTeX. Later back home, you > struggle to spot all the changes and retype them into LyX. in this case it's absolutely no problem to do it in latex, for both. again: since 1985 a lot of people tried to write converters from and to tex. all failed, especially for TeX->???, because tex is a kind of programming language, which can be enhanced just as you like it. so you don't have a fixed standard. I agree with Lars: if somebody updates reLyX, it will be great ... but a soon released 1.2.0 without any bugs is much more greater ... Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
Andre Poenitz a écrit : > > > - formula were not XML-ised at all (It looked a bit harder and > > > somebody was reorganizing the code : is it over ?) > > > > About this, I know that Jose is in vacations, but does someone know if it is > > planned to have math formulas translated to MathML when a DocBook file is > > exported to SGML (I know, it's a bit off topic)? > > It is planned. But don't expect anything to soon. And I am not sure > whether we will see proper semantical markup at all... What do you mean with semantical markup? Is it about the MathML content tags? If so I agree that presentational markups are maybe enough. BG
Re: lyx file format changes
On Tue, Aug 07, 2001 at 03:25:04PM +0300, Dekel Tsur wrote: > On Mon, Aug 06, 2001 at 12:27:36PM +0100, John Levon wrote: > > > > I'd really like to see an XML format for 1.3 ... as it would make > > things much easier to convert in the future ... > > Personally, I think it best to have lyx store its files as a valid > latex files (using latex comments for storing some information). I > know that this has been discussed before. What were the arguments > against it ? (complexity of the parser?) Actually, XML is driven, in part, by the scientific community trying to come up with a successor to HTML that does everything that LaTeX/TeX has done for them, while leaving room for expansion in the future. And, there are plans for crafting an XSL that converts XML+MathML into LaTeX. So, you get both. Vis-a-vis MathML: we don't need to specify/support both syntactic and contextual formats. And that's why the two flavors of MathML exist: use only what makes sense for your application. And that's what LyX should do. (See my other emails on this point.) -- John Weiss "Not through coercion. Not by force. But by compassion. By affection. And, a small fish." -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
On Tue, Aug 07, 2001 at 10:17:58AM +0200, Lars Gullik Bjønnes wrote: > John Weiss <[EMAIL PROTECTED]> writes: > > | Having recently done an XML seminar at work, I can offer the following > | to the discussion: [snip!] > | > | For "well-formed", think "lex". For "valid", think "yacc". > > And for this would would need a DTD right? NoNoNo, you misunderstand. When someone says, "Well-formed XML," they mean the equivalent of, "It will lex (tokenize) error-free and follows an absolutely primitive, lowest-common-denominator grammar." When they say, "valid XML," they mean, "It will yacc (follow a grammar) error free for the particular application it was written for." > So we will have a format that conform to the LyX parser... that is > really only Well-Formed XML, right? Oh, no. It follows a grammar: the LyX grammar. As long as a file follows that grammar, error free, it's also valid XML. > (We might create a DTD later, but in the beginning this will only > create more work.) The DTD/XSL comes in when you document that grammar. Hey, you could document the LyX file format's grammar in Danish if you wished, but using SGML DTD or XSL will be more concise. After all, SGML DTD and XSL were designed to document grammars, and both can be used to document XML grammars. The only other "natural" format for documenting grammars is a (heavily commented) yacc-file. I'll take XSL over that, any day. If your DTD happens to be in the format described in the XML standard (or if you use XSL), then the LyX file format is instantly portable! We can even use an XML engine to convert the LyX format into LaTeX. (That's one of the plans for XML, BTW.) > I do not agree that we should do this from the beginning... we will > most likely need several iterations before we are satisfied with the > xml format, and I think it will be a lot easier to create the DTD > afterwards. Of course we'll do several iterations. What, you eat your steaks by swallowing them whole? You don't slice into bits and chew? We can do both design and DTD simultaneously. When we need a new cell or block or attribute, we'll end up discussing it, won't we? Well, there are four ways to have that discussion: - In English (the imprecise Lingua Franca of the developer's list) - In yacc-format - In an SGML-DTD-like format. - In an XSL-like format. The latter is really flexible; I could teach it to y'all quickly. After the discussion settles down, and we agree upon a format for the new feature, I can take the email thread and clean up the XSL-like chat into real XSL. Won't take long. Then, voila! we have a grammar specification that makes the LyX XML file format portable. I think it's doable. I think it's doable without any extra effort. We just need to start out on the right foot. -- John Weiss "Not through coercion. Not by force. But by compassion. By affection. And, a small fish." -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
On Wed, Aug 08, 2001 at 12:22:21AM +0200, ben wrote: > John Weiss a écrit : > > > Once we do design an XML-based LyX format, I suggest we document the > > format using XSL. There's no magic around XSL: it's just an XML > > document that uses a format designed for defining other XML formats. > > I'll even volunteer to work on it (I'd like to improve my XML skills). > > Your XSL definition is too restricted: you can do any transformation Of course it's restricted! There's wy to much hype around XML/XSL, too much misunderstanding. I can't really point out that "XSL really isn't as bad as you think" if I whomp everyone over the head with a full-blown, complicated description of everything XSL does. Better to start with a description of what it can do *for* *us*! After all, that's what really matters. -- John Weiss "Not through coercion. Not by force. But by compassion. By affection. And, a small fish." -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
> What do you mean with semantical markup? Is it about the MathML content > tags? Yes. > If so I agree that presentational markups are maybe enough. Depends on intended usage... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On 07-Aug-2001 Dekel Tsur wrote: I know that this has been discussed before. What were the arguments against it ? (complexity of the parser?) And not only one time. Please have a look at the mailing-list-archive. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Marriage always demands the greatest understanding of the art of insincerity possible between two human beings. -- Vicki Baum
Re: lyx file format changes
Personally, I think it best to have lyx store its files as a valid latex files (using latex comments for storing some information). I know that this has been discussed before. What were the arguments against it ? (complexity of the parser?) That's one. The next one is that there are things that are not easily representable by LaTeX (was mutirow table cells one of them? don't know) Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
Dekel Tsur a écrit : On Mon, Aug 06, 2001 at 12:27:36PM +0100, John Levon wrote: On Mon, Aug 06, 2001 at 10:05:32AM +0200, Lars Gullik Bjønnes wrote: | that we should change format inside a fix release and x 0 will be a | fix release where ONLY bugfixes should come in! We could have the simple compability code in the fix releases. But not the real format changes of course. I'd really like to see an XML format for 1.3 ... as it would make things much easier to convert in the future ... Personally, I think it best to have lyx store its files as a valid latex files (using latex comments for storing some information). I know that this has been discussed before. What were the arguments against it ? (complexity of the parser?) Future is for XML like solutions, since it's consistent, open, well structured, and it allows more various translation processes. For me LaTeX is the historical output LyX format, and it should not be stuck to it. BG
Re: lyx file format changes
John Weiss a écrit : Once we do design an XML-based LyX format, I suggest we document the format using XSL. There's no magic around XSL: it's just an XML document that uses a format designed for defining other XML formats. I'll even volunteer to work on it (I'd like to improve my XML skills). Your XSL definition is too restricted: you can do any transformation you want with XSL. You can transform XML to XML (like HTML), but to anything else. Currently I transform DocBook XML files to the 1.1.6 LyX file format (which is not yet an XML one ;-) So, with XML native format exporting to various output formats is quite possible (latex included). BG
Re: lyx file format changes
Gaillard Pierre-Olivier a écrit : [...] - formula were not XML-ised at all (It looked a bit harder and somebody was reorganizing the code : is it over ?) About this, I know that Jose is in vacations, but does someone know if it is planned to have math formulas translated to MathML when a DocBook file is exported to SGML (I know, it's a bit off topic)? BG
Re: lyx file format changes
On Tue, Aug 07, 2001 at 06:19:00PM +0200, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | Personally, I think it best to have lyx store its files as a valid latex files | (using latex comments for storing some information). | I know that this has been discussed before. What were the arguments against | it ? (complexity of the parser?) | | That's one. | | The next one is that there are things that are not easily representable by | LaTeX (was mutirow table cells one of them? don't know) - personal words lists - user defined floats - user defined theorems - user defined paragraph layouts Item 23 are representable by latex code. Item 14 can be represented by putting a comment in the latex file. BTW, why 2-4 should be stored in the lyx file ? It is more reasonable to have them in the layout file.
Re: lyx file format changes
- formula were not XML-ised at all (It looked a bit harder and somebody was reorganizing the code : is it over ?) About this, I know that Jose is in vacations, but does someone know if it is planned to have math formulas translated to MathML when a DocBook file is exported to SGML (I know, it's a bit off topic)? It is planned. But don't expect anything to soon. And I am not sure whether we will see proper semantical markup at all... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
On 07-Aug-2001 Dekel Tsur wrote: > I know that this has been discussed before. What were the arguments against > it ? (complexity of the parser?) And not only one time. Please have a look at the mailing-list-archive. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Marriage always demands the greatest understanding of the art of insincerity possible between two human beings. -- Vicki Baum
Re: lyx file format changes
> Personally, I think it best to have lyx store its files as a valid latex files > (using latex comments for storing some information). > I know that this has been discussed before. What were the arguments against > it ? (complexity of the parser?) That's one. The next one is that there are things that are not easily representable by LaTeX (was "mutirow table cells" one of them? don't know) Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
Dekel Tsur a écrit : > On Mon, Aug 06, 2001 at 12:27:36PM +0100, John Levon wrote: > > On Mon, Aug 06, 2001 at 10:05:32AM +0200, Lars Gullik Bjønnes wrote: > > > > > | that we should change format inside a "fix" release and x > 0 will be a > > > | fix release where ONLY bugfixes should come in! > > > > > > We could have the simple compability code in the fix releases. But not > > > the real format changes of course. > > > > I'd really like to see an XML format for 1.3 ... as it would make things much >easier to > > convert in the future ... > > Personally, I think it best to have lyx store its files as a valid latex files > (using latex comments for storing some information). > I know that this has been discussed before. What were the arguments against > it ? (complexity of the parser?) Future is for XML like solutions, since it's consistent, open, well structured, and it allows more various translation processes. For me LaTeX is the historical output LyX format, and it should not be stuck to it. BG
Re: lyx file format changes
John Weiss a écrit : > Once we do design an XML-based LyX format, I suggest we document the > format using XSL. There's no magic around XSL: it's just an XML > document that uses a format designed for defining other XML formats. > I'll even volunteer to work on it (I'd like to improve my XML skills). Your XSL definition is too restricted: you can do any transformation you want with XSL. You can transform XML to XML (like HTML), but to anything else. Currently I transform DocBook XML files to the 1.1.6 LyX file format (which is not yet an XML one ;-) So, with XML native format exporting to various output formats is quite possible (latex included). BG
Re: lyx file format changes
Gaillard Pierre-Olivier a écrit : > [...] > - formula were not XML-ised at all (It looked a bit harder and > somebody was reorganizing the code : is it over ?) About this, I know that Jose is in vacations, but does someone know if it is planned to have math formulas translated to MathML when a DocBook file is exported to SGML (I know, it's a bit off topic)? BG
Re: lyx file format changes
On Tue, Aug 07, 2001 at 06:19:00PM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | > Personally, I think it best to have lyx store its files as a valid latex files > | > (using latex comments for storing some information). > | > I know that this has been discussed before. What were the arguments against > | > it ? (complexity of the parser?) > | > | That's one. > | > | The next one is that there are things that are not easily representable by > | LaTeX (was "mutirow table cells" one of them? don't know) > > - personal words lists > - user defined floats > - user defined theorems > - user defined paragraph layouts Item 2&3 are representable by latex code. Item 1&4 can be represented by putting a comment in the latex file. BTW, why 2-4 should be stored in the lyx file ? It is more reasonable to have them in the layout file.
Re: lyx file format changes
> > - formula were not XML-ised at all (It looked a bit harder and > > somebody was reorganizing the code : is it over ?) > > About this, I know that Jose is in vacations, but does someone know if it is > planned to have math formulas translated to MathML when a DocBook file is > exported to SGML (I know, it's a bit off topic)? It is planned. But don't expect anything to soon. And I am not sure whether we will see proper semantical markup at all... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: lyx file format changes
Lars Gullik Bjønnes wrote: I have a couple of things that I want to do early in the 1.3.x series. - add a \begin_doc_parameters ... \end_doc_parameters - add a \begin_paragraph ... \end_paragraph - add a \begin_par_parameters ... \end_par_parameters so you want to change the file-format the third time in sequence ... :-( these are minor changes! why can't this be happend in 1.2.0? it's not important for the user to get 1.2.0 as soon as possible! Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
On 06-Aug-2001 Lars Gullik Bjønnes wrote: That will continue to happen until we have a format that makes sense. (note that for this change it is possible to make 1.2.x read the new format with just a couple of small tweeks: - ignore the begin_doc_parameters and end_doc_parameters - user begin_paragraph just as \layout, ignore end_paragraph - ignore begin_par_parameters and end_par_parameters but this will happen in a 1.2.x 0 release. ) You surely meant that this will happen for 1.3.0 as I really don't think that we should change format inside a fix release and x 0 will be a fix release where ONLY bugfixes should come in! | these are minor changes! why can't this be | happend in 1.2.0? We have so many compability hacks in the code that this is very difficult (and a lot of work.) We have already too much changes! We have to stop now and to fix ONLY bugs or we nerver will see 1.2.0 (well not in this millenium ;) | it's not important for the user to get 1.2.0 | as soon as possible! Perhaps not, but it is beggining to be important for us (developers) to get 1.2.0 out. IMO it is for both! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You know what they say -- the sweetest word in the English language is revenge. -- Peter Beard
Re: lyx file format changes
On Mon, Aug 06, 2001 at 10:05:32AM +0200, Lars Gullik Bjønnes wrote: | that we should change format inside a fix release and x 0 will be a | fix release where ONLY bugfixes should come in! We could have the simple compability code in the fix releases. But not the real format changes of course. I'd really like to see an XML format for 1.3 ... as it would make things much easier to convert in the future ... What ha[p[enned to the XML patches ? john -- They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ? - Miss Portinari
Re: lyx file format changes
On Mon, Aug 06, 2001 at 02:13:40PM +0200, Lars Gullik Bjønnes wrote: | What ha[p[enned to the XML patches ? mmm... I don't want XML... but only something XML-like. why ? having something XML-like adds none of the advantages of XML[1], and all the disadvantages[2] It's like having a coat that is waterproof-like. It will be hot and uncomfy but won't keep you dry. john [1] leverage of standard tools, etc. [2] wordiness, inflexibility, etc. -- They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ? - Miss Portinari
Re: lyx file format changes
On Mon, Aug 06, 2001 at 02:50:13PM +0200, Lars Gullik Bjønnes wrote: No, I don't think you understand what I mean by XML-like. Let's call it well-formed XML instead. I must admit I'm totally confused then ;) If it is XML, then it is well-formed XML and vice versa. So we are using an XML format (good that's what I want ;) john -- They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ? - Miss Portinari
Re: lyx file format changes
On Mon, 6 Aug 2001, John Levon wrote: No, I don't think you understand what I mean by XML-like. Let's call it well-formed XML instead. I must admit I'm totally confused then ;) If it is XML, then it is well-formed XML and vice versa. So we are using an XML format (good that's what I want ;) I guess the point is that we don't want to a full-blown XML parser in LyX. Therefore, the LyX document format can look like XML, but there are constraints to what the program will read. E.g. some well-formed XML documents will be rejected by LyX. The other way should be ok: All LyX documents would be well-formed XML documents. However, if you use a standard package to manipulate the LyX XML document, you might run into trouble. One problem with XML is that a full parser carries a pretty big foot-print along with it, and it also introduces Yet Another Dependency. Finally, no good free C++ XML parsers are really available at this point to my knowledge. Greets, Asger
Re: lyx file format changes
On Mon, Aug 06, 2001 at 03:27:53PM +0200, Asger K. Alstrup Nielsen wrote: One problem with XML is that a full parser carries a pretty big foot-print along with it, and it also introduces Yet Another Dependency. Finally, no good free C++ XML parsers are really available at this point to my knowledge. oh, I see. that makes sense ... john -- They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ? - Miss Portinari
Re: lyx file format changes
John Levon wrote: On Mon, Aug 06, 2001 at 03:27:53PM +0200, Asger K. Alstrup Nielsen wrote: One problem with XML is that a full parser carries a pretty big foot-print along with it, and it also introduces Yet Another Dependency. Finally, no good free C++ XML parsers are really available at this point to my knowledge. oh, I see. that makes sense ... Yes indeed. I made patches on early 1.1.6 versions using libxml (DOM) for reading and SAX for output. This lead to code that was easy to write: basically I would copy the standard read or write method of a class (inset, paragraph etc.) and reorganize it a bit to use the DOM or SAX, thus leading to readXML and writeXML methodes. Using a DOM tree for input really makes things easier with current LyX code. Of course SAX would be easier if the LyX classes provided good constructors (the current ones are not meant to build complete objects since LyX fills the objects with data afterwards (with the read methods or with methods called due to user operations). Libxml is a quite big dependency. But I have seen a few new DOM parsers on freshmeat and sourceforge. As far of the status of the XML attempt is concerned : - layout and most insets worked - configure script was not updated - formula were not XML-ised at all (It looked a bit harder and somebody was reorganizing the code : is it over ?) sincerely, P.O.
Re: lyx file format changes
On Mon, Aug 06, 2001 at 03:27:53PM +0200, Asger K. Alstrup Nielsen wrote: On Mon, 6 Aug 2001, John Levon wrote: No, I don't think you understand what I mean by XML-like. Let's call it well-formed XML instead. I guess the point is that we don't want to a full-blown XML parser in LyX. Therefore, the LyX document format can look like XML, but there are constraints to what the program will read. E.g. some well-formed XML documents will be rejected by LyX. Having recently done an XML seminar at work, I can offer the following to the discussion: - Well-Formed XML: A text file following the minimal requirements for an XML document. This includes the initial ? xml-1.0 ? tag, a single root-level node, no cross-nested blocks, and a few other simple rules. - Valid XML: A well-formed XML file that conforms to a known format. Thus, LyX v12.9 files will be valid XML files. For well-formed, think lex. For valid, think yacc. As for fear of an XML parser, there are, IIRC, levels of compliance when it comes to parsers. You can write an XML parser that only reads XML files in a specific valid format. Nothing wrong there. A fully-compliant parser will also parse XSL files, enabling it to read any XML document ever written, now or in the future. That, we do not need. Once we do design an XML-based LyX format, I suggest we document the format using XSL. There's no magic around XSL: it's just an XML document that uses a format designed for defining other XML formats. I'll even volunteer to work on it (I'd like to improve my XML skills). -- John Weiss Not through coercion. Not by force. But by compassion. By affection. And, a small fish. -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
On Mon, Aug 06, 2001 at 04:16:30PM +0200, Edwin Leuven wrote: So that XML parsers will handle it. (but I don't think we want to use xml parsers (perhaps a sax parser)) For what it's worth, the Qt doc states: The XML module provides a well-formed XML parser using the SAX2 (Simple API for XML) interface plus an implementation of the DOM Level 2 (Document Object Model). As I said in my earlier note, we probably don't need this degree of compliance. We already have our own custom DOM in the LyX kernel (and always have, too). The XML parser we'll need only has to handle one valid format. We can, furthermore, document that parser in XSL, thereby making LyX documents portable. As for any inverse conversions, I'm sure someone somewhere is developing an open-source XML/XSL parser that'll convert documents between DTD's. No need to duplicate those efforts --- there's more than enough for LyX do deal with. BTW: I think, with all of the file format changes, that maybe it's time to modularize the file reading/writing parts of the code and create a translator binary to convert from older to newer formats. That would cut down on the amount of backward-compatibility code the LyX kernel has to carry around, and will permit our users to convert their older files without too much effort. -- John Weiss Not through coercion. Not by force. But by compassion. By affection. And, a small fish. -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
Lars Gullik Bjønnes wrote: > > I have a couple of things that I want to do early in the 1.3.x series. > > - add a \begin_doc_parameters ... \end_doc_parameters > - add a \begin_paragraph ... \end_paragraph > - add a \begin_par_parameters ... \end_par_parameters so you want to change the file-format the third time in sequence ... :-( these are minor changes! why can't this be happend in 1.2.0? it's not important for the user to get 1.2.0 as soon as possible! Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: lyx file format changes
On 06-Aug-2001 Lars Gullik Bjønnes wrote: > That will continue to happen until we have a format that makes sense. > (note that for this change it is possible to make 1.2.x read the new > format with just a couple of small tweeks: > - ignore the begin_doc_parameters and end_doc_parameters > - user begin_paragraph just as \layout, ignore end_paragraph > - ignore begin_par_parameters and end_par_parameters > but this will happen in a 1.2.x > 0 release. > ) You surely meant that this will happen for 1.3.0 as I really don't think that we should change format inside a "fix" release and x > 0 will be a fix release where ONLY bugfixes should come in! >| these are minor changes! why can't this be >| happend in 1.2.0? > > We have so many compability hacks in the code that this is very > difficult (and a lot of work.) We have already too much changes! We have to stop now and to fix ONLY bugs or we nerver will see 1.2.0 (well not in this millenium ;) >| it's not important for the user to get 1.2.0 >| as soon as possible! > > Perhaps not, but it is beggining to be important for us (developers) > to get 1.2.0 out. IMO it is for both! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You know what they say -- the sweetest word in the English language is revenge. -- Peter Beard
Re: lyx file format changes
On Mon, Aug 06, 2001 at 10:05:32AM +0200, Lars Gullik Bjønnes wrote: > | that we should change format inside a "fix" release and x > 0 will be a > | fix release where ONLY bugfixes should come in! > > We could have the simple compability code in the fix releases. But not > the real format changes of course. I'd really like to see an XML format for 1.3 ... as it would make things much easier to convert in the future ... What ha[p[enned to the XML patches ? john -- "They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ?" - Miss Portinari
Re: lyx file format changes
On Mon, Aug 06, 2001 at 02:13:40PM +0200, Lars Gullik Bjønnes wrote: > | What ha[p[enned to the XML patches ? > > mmm... I don't want XML... but only something XML-like. why ? having something XML-like adds none of the advantages of XML[1], and all the disadvantages[2] It's like having a coat that is waterproof-like. It will be hot and uncomfy but won't keep you dry. john [1] leverage of standard tools, etc. [2] wordiness, inflexibility, etc. -- "They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ?" - Miss Portinari
Re: lyx file format changes
On Mon, Aug 06, 2001 at 02:50:13PM +0200, Lars Gullik Bjønnes wrote: > No, I don't think you understand what I mean by XML-like. Let's call > it well-formed XML instead. I must admit I'm totally confused then ;) If it is XML, then it is well-formed XML and vice versa. So we are using an XML format (good that's what I want ;) john -- "They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ?" - Miss Portinari
Re: lyx file format changes
On Mon, 6 Aug 2001, John Levon wrote: > > No, I don't think you understand what I mean by XML-like. Let's call > > it well-formed XML instead. > > I must admit I'm totally confused then ;) > > If it is XML, then it is well-formed XML and vice versa. So we are using > an XML format (good that's what I want ;) I guess the point is that we don't want to a full-blown XML parser in LyX. Therefore, the LyX document format can look like XML, but there are constraints to what the program will read. E.g. some well-formed XML documents will be rejected by LyX. The other way should be ok: All LyX documents would be well-formed XML documents. However, if you use a standard package to manipulate the LyX XML document, you might run into trouble. One problem with XML is that a full parser carries a pretty big foot-print along with it, and it also introduces Yet Another Dependency. Finally, no good free C++ XML parsers are really available at this point to my knowledge. Greets, Asger
Re: lyx file format changes
On Mon, Aug 06, 2001 at 03:27:53PM +0200, Asger K. Alstrup Nielsen wrote: > One problem with XML is that a full parser carries a pretty big > foot-print along with it, and it also introduces Yet Another > Dependency. Finally, no good free C++ XML parsers are really available > at this point to my knowledge. oh, I see. that makes sense ... john -- "They didn't know what the symbols and paradoxes meant. Instead of following the finger that points to the moon, they sat down and worshipped the finger itself. Instead of following the map, they thought it was the territory and tried to live in it. Instead of reading the menu they tried to eat it. Dig ?" - Miss Portinari
Re: lyx file format changes
John Levon wrote: > > On Mon, Aug 06, 2001 at 03:27:53PM +0200, Asger K. Alstrup Nielsen wrote: > > > One problem with XML is that a full parser carries a pretty big > > foot-print along with it, and it also introduces Yet Another > > Dependency. Finally, no good free C++ XML parsers are really available > > at this point to my knowledge. > > oh, I see. that makes sense ... > Yes indeed. I made patches on early 1.1.6 versions using libxml (DOM) for reading and SAX for output. This lead to code that was easy to write: basically I would copy the standard read or write method of a class (inset, paragraph etc.) and reorganize it a bit to use the DOM or SAX, thus leading to readXML and writeXML methodes. Using a DOM tree for input really makes things easier with current LyX code. Of course SAX would be easier if the LyX classes provided good constructors (the current ones are not meant to build complete objects since LyX fills the objects with data afterwards (with the read methods or with methods called due to user operations). Libxml is a quite big dependency. But I have seen a few new DOM parsers on freshmeat and sourceforge. As far of the status of the XML attempt is concerned : - layout and most insets worked - configure script was not updated - formula were not XML-ised at all (It looked a bit harder and somebody was reorganizing the code : is it over ?) sincerely, P.O.
Re: lyx file format changes
On Mon, Aug 06, 2001 at 03:27:53PM +0200, Asger K. Alstrup Nielsen wrote: > On Mon, 6 Aug 2001, John Levon wrote: > > > > No, I don't think you understand what I mean by XML-like. Let's call > > > it well-formed XML instead. > > I guess the point is that we don't want to a full-blown XML parser in LyX. > > Therefore, the LyX document format can look like XML, but there > are constraints to what the program will read. E.g. some well-formed > XML documents will be rejected by LyX. Having recently done an XML seminar at work, I can offer the following to the discussion: - Well-Formed XML: A text file following the minimal requirements for an XML document. This includes the initial "" tag, a single root-level node, no cross-nested blocks, and a few other simple rules. - Valid XML: A well-formed XML file that conforms to a known format. Thus, LyX v12.9 files will be valid XML files. For "well-formed", think "lex". For "valid", think "yacc". As for fear of an "XML parser", there are, IIRC, levels of compliance when it comes to parsers. You can write an XML parser that only reads XML files in a specific valid format. Nothing wrong there. A fully-compliant parser will also parse XSL files, enabling it to read any XML document ever written, now or in the future. That, we do not need. Once we do design an XML-based LyX format, I suggest we document the format using XSL. There's no magic around XSL: it's just an XML document that uses a format designed for defining other XML formats. I'll even volunteer to work on it (I'd like to improve my XML skills). -- John Weiss "Not through coercion. Not by force. But by compassion. By affection. And, a small fish." -His Holiness, the 14th Dalai Lama
Re: lyx file format changes
On Mon, Aug 06, 2001 at 04:16:30PM +0200, Edwin Leuven wrote: > > So that XML parsers will handle it. (but I don't think we want to use > > xml parsers (perhaps a sax parser)) > > For what it's worth, the Qt doc states: > > The XML module provides a well-formed XML parser using the SAX2 > (Simple API for XML) interface plus an implementation of the DOM > Level 2 (Document Object Model). As I said in my earlier note, we probably don't need this degree of compliance. We already have our own custom DOM in the LyX kernel (and always have, too). The XML parser we'll need only has to handle one valid format. We can, furthermore, document that parser in XSL, thereby making LyX documents portable. As for any inverse conversions, I'm sure someone somewhere is developing an open-source XML/XSL parser that'll convert documents between DTD's. No need to duplicate those efforts --- there's more than enough for LyX do deal with. BTW: I think, with all of the file format changes, that maybe it's time to modularize the file reading/writing parts of the code and create a "translator" binary to convert from older to newer formats. That would cut down on the amount of backward-compatibility code the LyX kernel has to carry around, and will permit our users to convert their older files without too much effort. -- John Weiss "Not through coercion. Not by force. But by compassion. By affection. And, a small fish." -His Holiness, the 14th Dalai Lama
