On Fri, Oct 23, 2009 at 11:05 PM, Pavel Sanda <sa...@lyx.org> wrote:
> at least by me this was considered and in fact was starting point of some
> doubting. project, which you may not be aware of
> (http://www.netmeister.org/apps/lyx2html/), was triggering in me the feeling
> that history is repeating again. one can see that this package is still
> lurking
> in distro repos as a zombie not touched for last 10 years. thats one of
> reasons
> i was from the begining so troublesome when it comes to the question of
> inclusion.
I was acutely aware of lyx2html and other efforts from the beginning;
the first sentence on the eLyXer main page reads:
"eLyXer (pronounced elixir) is a LyX to HTML converter. While there
are a ton of such projects all over the web, eLyXer has a clear focus
on flexibility and elegant output."
I had actually tried most of the HTML converters out there, both from
.lyx and from TeX. The results were painful to look at, and I'm no
aesthete. Thankfully CSS2 had evolved in the meantime, enabling a new
generation of HTML tools of which eLyXer is just an example.
> now this is nothing against you personally - its true for all devs here - when
> one is looks on the lyx project from a wider time range developers come and
> leave and you will have hard time to find most of devs which were 10 years
> before on this list. but the popularity reached a certain threshold so its
> quite probable other new people will contine and will have to handle the code
> we leave... from this point of view its no more question of "what is easier
> to do" but rather "is the code written in easy maintainable way?"
It is a fair concern. Now I have tried to answer all of the points
raised by LyX developers:
- all parsing code is in a separate package,
- all parsed strings is configurable in a single file,
- configurabiliy and modularity have been prime concerns from day one,
- ease of adding features has not slowed down with time:
http://www.nongnu.org/elyxer/changelog.html
- eLyXer returns the maximum format number it supports,
- and there are user and developer guides.
But after all this is said and done, it seems that a small number of
people just go back to "converting HTML from .lyx files is wrong",
which is not very helpful when that is the basic premise of eLyXer. So
I don't really believe that "is the code written in easy maintainable
way?" is the obstacle here; we must have a deeper misunderstanding.
> thats why even if lyx internal html export wouldn't have all whistle and bells
> compared to elyxer once lyx 1.7 comes out i would still consider it more
> promising start from the long term view.
I tried to explain above at length why this point of view is
incorrect. Could you elaborate? Where do you think my rant is wrong?
> we would have another discussion if there was no work on internal support but
> once you provocated Richard to start it, we are on a different grounds. where
> we have utterly failed was to pick up your enthusiasm and convince you to
> cooperate on this project, even worse to make you feel to be attacked by us.
> this way only Richard is envolved on internal html export and aparently
> without
> much sparse time to continue on the half-work-done...
Actually the native HTML project is the wrong approach IMHO, so even
if I felt the LyX dev community was welcoming and nice I would not
want to be involved with this project. It would not matter much if a
host of wizard programmers were hired full-time for the project and
managed to produce beautiful output the kind you make posters with; in
a couple of years it would inevitably decay and rot just like the
DocBook backend. Talk about "easy maintainable way"...
Alex.
