Guenter Milde wrote:
Figuring out how the bibliography is supposed to be rendered will be
more difficult,
Not more difficult than writing a bibtex style in the first place.
I suppose an approach similar to biblatex will help: divide the
"extract and sort" from the "render and style" task. The former can
be done by Python, the latter by CSS.
This depends what you are trying to do: Are you trying to render it as
the chosen BibTeX style would? Or do you just want to render it in some
sensible fashion? If the former, then things will be difficult, though
it is an option to parse the bbl file. This, I think, is what plastex
etc do.
though maybe there's not so much of a need to render
it precisely as BibTeX would.
No, it isn't. As long as the semantic is kept, styling can be done
separately.
Styling isn't the issue. Ordering, etc, is.
In my view, the massive interest in eLyXer showed that it fills a niche
quite nicely. I daubt that 90...99% of LyX users will be satisfied, but
also satisfying 30...40% is an achievement. And I see a big potential.
No disagreement there, really. Though I guess I find it depressing if
people are using LyX in such a way that they are happy with so little,
i.e., as if it were Word.
If it were up to me, Edit>Text Style, among other things, would vanish
completely.
The main advantages of eLyXer I see in:
* Size and simplicity: even without a LyX or LaTeX installation, you can
use eLyXer and a HTML-browser as a *.lyx viewer.
* LyX + eLyXer can serve as a WYSIWYM HTML editor.
If this is what one wants, then an HTML "document class" might be a good
idea. Otherwise, you risk using features of LyX that elyxer can't handle.
* Clean HTML that preserves the semantic. Keeps the WYSIWYM idea.
This is also present in other converters.
* No pixmaps for math (I favour MathML and think there is some work that
can be used in the Docutils sandbox (latex-math extension).)
Yes, but at present math isn't very well supported. This is the problem
everyone has.
What I thought would be the advantage of eLyXer, or some such tool, was
that it would do a BETTER job and support MORE features.
sometimes "less is more" (cf. the Unix philosophy of doing one job well).
Well, I'm not sure about that. Less, in this case, means simply not
doing certain things at all.
...I think you vastly overestimate the number of people who don't need
what you call "advanced" features. Most of us here would regard them as
absolutely central to what LyX is.
However, out of the vast number of "advanced" features, you will not
find a majority that agrees on which parts are the most important --
I could not live without math and bibtex, but never needed theorems.
Others depend on need musical notation, chess plays, or listings,
Of course, which means that a lot of people will be missing something,
though different things. But still, a lot of people are missing
different things.
So, well, LyX is a tool, and you can use it to do what you want. But if
you're not using LyX the way described, as your tendency to dismiss
these things you happen not to use as "advanced features" suggests, then
you're really missing out on what LyX is.
I thought LyX was the great tool to concentrate on content and
forget about the details?
Yes, of course. What I meant was: If you're not using BibTeX, and you're
not using custom styles, and you're not using math, and ....
Getting something workable that does as much as eLyXer now does would
be pretty easy, because we already have access to the complete
structure of the document.
If LyX can get the structure of the document by parsing a LyX file, so
should any other program be able to do this as well. (And the switch to
an XML based format should make this even simpler.)
Sure: Write a new parser in python, and then have it do everything LyX
does to update counters, etc, etc. You could do this, but it's insane.
Why re-write LyX in python?
In my view, it is an advantage of eLyXer that it can work independent
of LyX. (Of course this is an argument to keep it separated but
documented and integrated as one of several LyX->HTML converters).
I don't see why that's an advantage. You can use LyX from the command
line, too.
I am not sure it will help LyX if a layout or module designer had to
think in 3 languages (LyX layout, HTML and LaTeX) instead of currently
two. See docbook as example for the "creeping separation" due to
different user groups (again this can serve as argument against an
integration of eLyXer as well as any HTML export tool).
I'm inclined to think that, if we go to three, then that will just make
abstraction necessary that ought to have been done anyway.
rh
