Richard Heck <rgh...@lyx.org> writes: > On 02/28/2014 05:35 AM, Rainer M Krug wrote: >> 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. > > The "building the document" part is already do-able. Every editing > action is an LFUN. Try it in the minibuffer: > layout-section Section 1 > break-paragraph > self-insert This is the contents. > footnote-insert > self-insert This is a footnote. > char-forward > self-insert That's all folks. > There's a bit of a problem here: There's no easy way to insert a space > after the footnote, from what I can see. > > I'm not sure I understand, conceptually, what the API would look like > going the other direction. The obvious way to "provide data about > inset and paragraph contents" would be to send the client a copy of > the LyX file. I mean, we have to serialize the data somehow, which is > something LyX even does internally. And the serialization looks just > like the LyX file. That allows us to reuse the code that reads the LyX > file to read serialized data produced internally.
The main point would be, that this serialized content is independent of the .lyx file format used, i.e. that it stays the same (or at the least is backward compatible) through the conversion to any new file format (xml). The information given out of LyX could also be hierarchical, i.e. that for different requests, different kinds of content are provided an example would be that 1) a request for "text only" returns the text - without bibliography, formating of text (e,g, bold words), graphs, tables, headers as a paragraph, ... 2) a request for "paragraph formats" request returns the type of the paragraphs (Section, Subsection, List, enumeration, ...), which can then be merged into (1) 3) a third request for "character format" would return character formatting (e.g. bold) 4) a fourth request for "bibliograhy" returns where the citations are, the format and the .bib file 5) ... Consequently, the structure would be modular and new features could be easily added and implemented in the round-trip converter. Cheers Rainer > > Richard > > -- Rainer M. Krug email: RMKrug<at>gmail<dot>com
pgpkrMCK05G4g.pgp
Description: PGP signature
