I vote also for inclusion.
== C++ or Python ==
eLyXer code is easy to understand even for hobbyist programmers like me.
Hacking exporting is something that could be done by power users or
beginner developers. Embedding it in the C++ maze of LyX code would make it
easier for Abdel and the core developper team but harder for everybody
else.
== LyX layouts or Python ==
Having the translation pair inside the layouts looks like a nice idea but it
would, I think, limit converters to very simple one. It is easy to convert
from \emph{} to <i> </i> but much harder for structure like tables or
crossreferences where the logic between LyX and the target language is
different. Converting from one format to another is certainly more complex
than search and replace.
But I agree with Richard, that for custom layouts having a possibility to
add conversion information would be nice.
== Math ==
I think that perfect math translation in HTML / MathML cannnot be a
showstopper. Do you wan't really to convert a complex math document to an
HTML page ? Few browsers (basically only Firefox) can read MathML. The
client must have a good math font on his computer to render the math
symbols.
ELyXer could also use LaTeXMathML (http://math.etsu/edu/LaTeXMathML) a
javascript macro that convert on the fly LaTeX formulas to MathML code.
MathML conversion routine can be later added step by step in ELyXer. There
is nothing in the code that prevents it.
== BibTeX ==
BibTeX is very hard because of the many bst files, gigantic number of
options in natbib, biblatex... Most LaTeX -> HTML converter have very
limited bibtex conversion, generally Plain and the style that the converter
author is using. The only elegant solution is to extract the formatted
reference from the pdf and translate it in HTML code.
It is not impossible to do. The new synctex framework (included with the
latest pdflatex and xelatex) spits a table that maps the lines of the pdf
file and the latex file. Using the synctex information and some intelligent
text search, you can get the result in the pdf file of \cite{Blabla} and
then convert it to html code.
Much simpler than creating in LyX code a C++ parser of bbl and aux files...
plus extra code for biblatex that does not work the same way ... plus extra
code for the ibid., op. cit. mechanisms...
== Maintainability ===
What would be nice is to have a testing suite for elyxer. If the LyX format
change, some tests will fail and it would be easy to correct elyxer.
If LyX goes XML, we will enter in a Golden Age where miraculous XSLT will
transform water to wine, LyX XML to ODF and we will validate all the time
all our files ;-)
Cheers,
Charles
