cmira...@kde-france.org wrote:
I vote also for inclusion.
Let me take this opportunity to explain why I do not, even though Alex
seems to have decided that he'd prefer not to have elyxer included in
lyxsvn.
== 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.
This is true, to be sure. But there are things that can be done inside
LyX that cannot easily, if at all, be done from an external converter.
I've said this several times and given lots of examples. As I see it,
the question is whether we need one converter or two. If the answer is
"one", then the question is: Where can that conversion best be done? The
answer to that is then pretty clear. If the answer is "two", one that
will work on platforms where LyX works and handles the LyX format pretty
completely, and one that works on cell phones and only handles the
basics, then that's a different matter.
But look, if people want to work on elyxer, I'm not trying to stop them.
I do think duplication of effort is kind of silly, and I'm skeptical
about the need for a program that allows LyX files to be viewed on cell
phones, but to each his own. That's the beauty of open source, right?
== 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.
I'm not proposing to do those sorts of things inside layouts. That would
be hardcoded, just as the export of LaTeX for tables is hardcoded.
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.
I wasn't proposing to export to MathML, myself. That would be nice to
have as an option, to be sure. My intention is to export as much as
possible to native HTML, using Unicode if necessary.
For what it's worth, I don't see any major obstacles to handling math in
elyxer. My point was that, *as it now stands*, math support is marginal.
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.
Of course not.
== 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...
Here again, my original point had to do with what elyxer DOES NOW, not
with what it might do in the future. And I myself suggested the use of
the python-bibtex module to parse the bib files. So I don't see that
this makes for any choice between the approaches, other than that we
already have a bib file parser in LyX. It'd be nice to be able to output
the same thing the chosen bst file would, but I doubt that is critical.
And I've recently committed a framework to trunk that (with a bit more
work, which I will do later) allows for user-defined formatting of
bibliography info, as it's presented in LyX, on a per-document and
per-entry-type basis. I'm not sure what more one would want.
So the sort of information you'd need is already available in LyX, or
can readily be made available. Which is a large part of the point. Why
should we program the same thing again? An answer *might* be: To have
something that runs on the iPhone. Well, if that's the goal, then OK.
But I guess one had better make sure the HTML output is the kind of
thing that's readable on an iPhone.
== 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.
How easy it is, is not so obvious. Unless elyxer is being kept up to
date with every format change, then it'll be non-trivial to say the
least. The "internal" approach is very different. It doesn't care about
file format, but only the abstract structure of the file as represented
in the Buffer structure. Of course, new features will require new code
in both cases. But other sorts of file format changes require *no*
change, including....
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 ;-)
...if and when LyX goes to XML. This will be *only* a change in the
format of the file, not in the internal representation.
Though, of course, I agree that XML will make me 25 years younger.
Richard
