On 02/07/14, 11:11 , Cyrille Artho wrote: > Dear all, > I think we have had earlier discussions (a few months ago) that touched > some of the problems, but I see some major challenges when having a > roundtrip conversion where extra data cannot be stored in the target > file itself.
To quote Coldplay and Willie Nelson (From "The Scientist"): Nobody said it was easy No one ever said it would be this hard True - we had this discussion before and this is what the entry on the wiki is based on. I agree that there are big difficulties, and especially on the "dark side" (read: the side we are exporting to) as we have no control over it. > > The issue is that the target file will be edited before it's re-imported > (otherwise there is no point in exporting the data to being with). This > can make a clean re-import very challenging. Absolutely. > > For example: > > "Good": lyx -> latex: Store extra data as special LaTeX comments. > > A comment at the beginning of the file can let a LaTeX user know that > some features (starting with %%LyX or such) should not be edited, > because details are lost otherwise. > > The reverse conversion should work well even if the LaTeX file is > changed a lot, as a normal user can be expected to leave the extra > comments where they belong. > Exactly - that is what one can hope for. > > "Bad": lyx -> something rather alien (.docx or such): If you need to > store information in other files, how are the parts going to be > reconstituted after the .docx file has been changed? Same way probably? Using notes and comments, convert these to LyX, as they have a location, they will stay where they are, the post-process the LyX file by applying the %%LyX notes? > > > Regardless of the number of files, the problem is much harder than just > a reversible mapping. It has to survive a certain amount of editing. The > same edits in the original and in the exported version should map to the > same result after re-importing: > > file - > lyx2target -> target > > | | > | edit | edit > V V > > file' <- target2lyx <- target' > I have no idea how this can be done elegantly, but I hope this can be made easier by a) using some type of tags in comments / notes / et al which all programs have and b) a certain discipline by the person editing the documents by not deleting these. This applies to the LaTeX user as well as the Word user. Nothing is foolproof. > > At least for some editing, this should be supported. I don't think it is > necessary to be perfect here, so it can probably be achieved for many > useful practical cases, but I also think it's harder than just > converting back and forth. > You are definitely right here, and that is the reason why this proposal / idea sounds quite vague: it is a difficult problem (especially as I think one should keep the structure very flexible, so that it will be easy to support different backends) and there is no control over the other side of the roundtrip. In LyX one could restrict the features usable, display warnings on ex[port for roundtrip, etc. But there is no way this can be done in e.g. word or LaTeX. And I agree: one has to start with a small subset of features supported, and then they can be extended. That is why on http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014#toc1 there is a list of *suggested* features: #### Features to be included in the round trip are: sections, headers, ... lists emphasis, bold, ... comments track changes tables and figures? footnotes bibliographic references math? cross-references #### So I see the difficulties, but a system like this would be tremendously useful to support roundtrips to many different backends. Cheers, Rainer > > > Vincent van Ravesteijn wrote: >> On Fri, Feb 7, 2014 at 10:02 AM, Rainer M Krug <rai...@krugs.de> wrote: >> >>> The idea would be that a round-trip framework is envisaged, which >>> provides the facilities to easily expand it from one export backend >>> (docx) to another (possibly odt? markdown?). >> >> This sounds like a sort of testing framework which would indicate for >> each export backend which features are exported and imported >> successfully. It would be cool to have some matrix showing how mature >> each of the supported formats is. >> >> >>>> >>>> Perhaps we could define the goals as: >>>> >>>> 1. Define a minimal-lyx feature set (I.e. the supported LyX/LaTeX >>>> features) >>> >>> Agreed. >>> >>>> 2. Write a corresponding lyx-layout >>> >>> As I said, non-supported formats / features should be available to the >>> user and handled gracefully, i.e. stored in a metadata file which will >>> be re-applied when re-iporting the round-trip file. >>> >> >> Would this also solve some of the LyX->LaTeX->LyX roundtrip issues ? >> >>> >>> Yes - although I see one problem which I could not find in any of the >>> .lyx <-> .docx : comments and track changes. These *have to be handled*. >>> I somehow have the feeling, that an inclusion of comments and track >>> changes into pandoc would be the best way forward... >> >> What is the problem you see ? >> >> Vincent >> > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug
signature.asc
Description: OpenPGP digital signature
