On Wed, Dec 26, 2012 at 5:45 AM, Pavel Sanda <sa...@lyx.org> wrote: > Nico Williams wrote: >> I've filed a request for enhancement so that external "plugins" can be >> found by configure.py. > > Sure, I know. What I don't know is whether or when someone will pick it up and > implement it. Changing configure.py is matter of adding couple of python > lines and most probably you can have it in 2.0.6. > We can wait and see what happens :)
Ah, ok. When I'm ready I'll ask for my converters to be added to configure.py. > The problem is that once we ship it under LyX flag officially we are > responsible to fix its bug and maintain it in future. That's why so > much fuss around. That much is understood :) >> However, I was hoping that I could perhaps get you >> interested in a different approach. > > We flamed about this (=using internal python library which parses .lyx > format for export to another format) approach to death and final decision > was that we rather implement HTML output from the very beginning than > maintaining another python hackerspace above undocumented and > steadily changing .lyx fileformat. And that's how LyXHTML was born. At first glance LyXHTML is fine, since it heroically preserves, e.g., custom inset information. However, on a closer look LyXHTML turns out to be fundamentally not a document format. The problem is that LyXHTML is XHTML -- it is a format that one _renders_ to (and which browsers further render from), but it is not a document format. This distinction becomes obvious the minute you change a LyX document's document class: the .lyx barely changes, while the LyXHTML export can change sufficiently to break my XSL. And that (document class affecting details of LyXHTML output) is as it should be for a presentation format, but it's a disaster for a document format. Ergo, LyXHTML is not useful as an XML interchange format for LyX. It's fine as output intended for rendering in a browser, but that's of much more limited value than an XML interchange format. Trust me, I've put a fair bit of effort into XSL for changing LyXHTML to XML in a schema I need. It can work within limits, but it's not the solution I'm looking for. Granted, if I had a faithful XML schema equivalent of .lyx then version changes could break my XSLs. But I could work around that via XSLs to deal with version changes, but I think that's quite tolerable (and no different than LyX's existing .lyx version change scripts). (NOTE: this means that converters need to specify what .lyx format versions they consume or produce!) I hope this is as convincing as I think it should be :) > That much for export. Using XML as native .lyx format, apparently holy grail > for people dreaming about various .lyx<->office/whatever conversions, is > hanging around like a ghost for a decade, but IMHO it would be again baked > through C++ parsing routines we have than through external python scripts. That's a matter of opinion. Your (the team's) opinion wins, obviously. I won't belabor this point. In the meantime, however, perhaps my script can help you think about the schema of the LyX native XML format. >> I should explain the specific problem that led me here. I'm trying to >> use LyX to edit and typeset Internet-Drafts and RFCs. To give you an >> example: http://www.rfc-editor.org/info/rfc5059 -- see the .txt and > > This looks interesting. It is somewhat sad that LyXHTML code is not > customizable enough to get it work without creating whole project around. > I keep thinking that tweaking the current code would have been less work > but I really don't know all the issues you encountered. Now, when your > library is more or less written, it's probably too late. See above. Actually, lyx2rfc works well enough, but I've had issues that led me to use the docbook article document class, which can't output labels, so I can't use bibliography environments, and I can't use the citation picker when adding citations. I may switch back to a different document class, but then I'll have to change my XSL; perhaps not a big deal as lyx2rfc is getting fairly mature. But someday I'd like lyx2rfc to output .lyx with metadata from the original converted to .lyx that renders looking like an RFC. Then I'll definitely need a document format that's sufficiently faithful to .lyx that I can preserve the majority of the input as-is. Since I'm already using XML I'd like to keep using XML. Nico --
