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.
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.
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.
"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?
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'
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.
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
--
Regards,
Cyrille Artho - http://artho.com/
Those who will not reason, are bigots, those who cannot,
are fools, and those who dare not, are slaves.
-- George Gordon Noel Byron
