Rob Oakes <lyx-de...@oak-tree.us> writes: > Dear Developers, > > I've been following this conversation from the shadows, but I had one > thought that they be relevant. > > I think everyone agrees that we want to avoid reimplementing the > internal logic of a LyX document. While thinking about what might be > the best way to implement a converter, it occurred to me that it might > be worthwhile to implement the converters as clients that are able to > use a LyX server session.
This comes close to my thought about an API, but it would be even better in the sense of more versatile and easier usable by external tools. The server - client approach would be the optimal and most flexible approach. > > For export, the server could load a document, provide data about inset > and paragraph contents, and the client could then convert the logical > representation to docx or odf. For import, the process might work in > reverse. The importer reads in the data from the document, translates > it to a logical format that could be consumed by the server, and the > server creates a new document. Document internals remain internal to > LyX, while the server-client communicate over a well-defined protocol > to interactively build the document. This would be the best approach, as the internals are hidden in LyX, and the external clients only ask the same questions to retrieve the content they need to do what they want to do. It would also open many more options, e.g. web based editing. > > If I understand the LyX server pipe, it is already possible to retrieve > information about insets, citations, cross-references, and other > document components. Moreover, there are only a few properties for a > particular type of inset (ID, text, meta, etc.), which provides a > manageable way to handle output data. Might it even be possible to > export the data for a particular inset in a serialized key/value > format? This would allow for insets without a good output format to > main their data as DOCX/ODF metadata which could be faithfully > translated back during import. > > As I've followed the pandoc conversation, I've been concerned about the > introduction of another dependency. If the import/export tools can be > kept to LyX and some processing script, that seems easier to maintain > than a complex chain of tools and external dependencies which we don't > control. Pandoc in the round-trip is definitely a sub-optimal solution due to the reliance on another tool, and quite a few modules for pandoc would have to be written. It is a different topic to use pandoc for export, as in this case only one pandoc would be needed. Cheers, Rainer > > Just my 0.02. > > Cheers, > > Rob > -- Rainer M. Krug email: RMKrug<at>gmail<dot>com
pgp4vzHRb53UD.pgp
Description: PGP signature
