On Sat, Oct 24, 2009 at 1:19 AM, Pavel Sanda <sa...@lyx.org> wrote: > if its just a question of misunderstanding i can rephrase it clearly: > the code which converts HTML directly from .lyx files is not easy > maintainable in a sense that it needs manual checks/fixes any time > we change output format, while producing output directly from internal > lyx strucutures is not touched by this.
So there we go: there is still opposition to the approach taken by eLyXer, and therefore no place for it in the SVN repo. >From my point of view there is the related issue that I don't like the way conversion is done from within LyX in 1.6.x or in 2.x: while with PDF LyX states clearly that it is using pdflatex or ps2pdf, with HTML it doesn't say if it's eLyXer, htlatex or what. Also, once it finds one HTML tool it doesn't recognize other tools, so users can't compare the output or choose the best tool for the job. There is a tendency to bury eLyXer and similar tools in the "HTML" menu entry without recognizing their existence, maybe because HTML is despised as a format. Then there is the possible confusion between the old "HTML" format and the new "LyX HTML" format. I don't want people to start complaining about eLyXer only to find out that it is not my code; but I do want people to know they are using eLyXer and complain about it when they are. Finally, there is no willingness to acknowledge these as problems or fix them eventually; so even with commit rights it's doubtful I could solve them. Just so that Richard doesn't say I'm not proposing anything: the correct solution IMHO would be to "pollute" the menu with individual entries: "HTML (eLyXer)", "HTML (hevea)" and so on, making clear what package people are using (and allowing for multiple HTML conversors). The new native HTML could be labeled as "HTML (native)". It would be consistent with PDF and probably not much of a burden for most users. If the clutter is excessive then submenus could be added and the last choice remembered, as has been suggested; so if you used HTML (hevea) last, there would be one entry with "HTML (hevea)" and then a submenu "HTML" that contained the rest: "HTML (eLyXer)", "HTML (htlatex)". Note that Jürgen's code hides all that clutter in a submenu already, so it might be less of a problem now. >> 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? > > it tries to defend architecture and details of code, which i'm not currently > concerned about. my attack went on the whole premise of elyxer. In fact I tried to explain why eLyXer is easier to develop and more maintainable than e.g. native HTML output. Or native DocBook support for that matter. I.e. why the approach is right. >> a couple of years it would inevitably decay and rot just like the >> DocBook backend. Talk about "easy maintainable way"... > > and the point you missed completely is that docbook backend is basically > _still_ working although nobody touched single bit of it for years. people are > anoyed because there is no documentation and because it it produces old xml > format, but thats unrelated. I don't see it in LyX 1.6.4 any more. Meanwhile eLyXer works (to the best of my knowledge) with all versions from 1.5.x (July 2007) to 2svn (unreleased). And generating a different format (like HTML 5.0) can be done mostly by modifying a single file. It seems we have quite different notions of "maintainable". Alex.
