On Tue, Dec 25, 2012 at 7:50 PM, Pavel Sanda <sa...@lyx.org> wrote: > I think we can support your converter via recognition in configure.py > so XML convertor appears in View/Export menus when installed. > We can also put it in contrib section on our ftp server, if you would like.
I've filed a request for enhancement so that external "plugins" can be found by configure.py. Basically a directory under /usr/share/lyx/ or /usr/lib/lyx/ that 3rd parties can drop something into that configure.py will look for, like ~/.lyx/preferences snippets. That should suffice. > If by contribution you mean that we should include it in our development > tree and distribute it as part of LyX itself things became more troublesome. > > The way you approached the whole problem is pretty much against the current > code infrastructure and maintaining separate python scripts would be tiresome, > because any fileformat change have to be separately handled in your scripts > (i.e. .lyx is somewhat living creature and maintain it on more than in one > place, currently C++ codebase, is not wise design choice.) You already have this problem since the .lyx version format conversions are in Python anyways, and any time you make changes to the format you have to go add a script. The good news (for me) is that those scripts document the changes (sort of). > We can discuss it more if some developer stands up to maintain this creature - > note, however, that we already had long threads here both about 1) XML as > native > .lyx format and 2) using external .lyx convertors (elyxer) and your proposal > does not seem to bring new light into the problems encountered... I'm happy either way -- it's only a contribution; I don't need you to take it. However, I was hoping that I could perhaps get you interested in a different approach. I'm not sure how much this approach has been discussed before (yeah, I know, I should have researched the list archives). My particular approach is to use XML and XSLT as the go-between in all conversions where that makes sense. It does mean updating XSLs instead of C++ code when you make document format changes, but IMO that's a lot easier than maintaining C++ code, and a lot more powerful. > On a different note, we have working but somewhat outdated docbook export and > we seek someone to update it to more recent version. > Wouldn't be Docbook 5 output xml-ized enough for your export needs? One of the things I need is extra metadata. I use custom insets for this. Perhaps there's a better way. I guess I should learn more about LyX customization. But as long as I'm adding metadata (and I definitely need it) then I don't see how Docbook is going to help me. Whereas an XML schema that's much more faithful to .lyx will preserve all those custom insets, an anything else I might use for my purposes. In fact, I did begin with LyXHTML output, and I've written XSLs for mapping that to a different schema. But even the LyXHTML output has issues. With a XML schema that corresponds closely to the .lyx format I will have no such problems. Perhaps the best thing to do is for me to keep this separate and take contributions from anyone who finds it useful until it's mature enough for the LyX devel team to reconsider it. In the meantime, if lyx2xml injects energy into the LyX XML discussion I may have contributed anyways. 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 the PDF versions. There's also HTML versions, like http://tools.ietf.org/html/rfc5317 . Now if you look carefully you'll note all sorts of metadata and all sorts of not-terribly-common typesetting choices. Some of the metadata is for author information, which appears in several places: on the front page, more complete towards the end, in the Authors section, and in the footer on every page. My current approach is to use LyXHTML + XSLT to convert into the schema used by a tool called xml2rfc (http://xml.resource.org/), but it's not that great. With a better XML export schema I could do much better, and I could even generate .lyx with the correct front page layout and with footer setup, Authors section, etcetera, then use LyX to finally typeset. All the existing XML export options in LyX fail me in some way; I've filed bugs for some of these issues, and I've asked on the lyx-users about others. I keep coming back to the idea that if I just had a good XML schema for .lyx I wouldn't have any of those issues. To my existing lyx2rfc tooling in action look at https://github.com/nicowilliams/lyx2rfc/ . Another motivation for this approach is that I believe XML diff algorithms can probably be applied (in combination with the XSLs I've mentioned) to produce meaningful .lyx format 3-way diff/merge tools. >From what has been said on the lyx-users list about diff functionality for LyX, it's not very likely that we'd get useful diff functionality anytime soon. But by externalizing the task it might be easier. Happy holidays, Nico --
