On 2009-04-30, Richard Heck wrote: >> On Thu, Apr 30, 2009 at 4:13 PM, Richard Heck <rgh...@bobjweil.com> wrote:
>>> You can easily create a LyX document with some BibTeX. And if you >>> want to work on this, then you can probably use the python-bibtex >>> package to parse the files. Good idea. Generally, as eLyXer is written in Python it should be possible to recycle and combine a lot of existing efforts for LaTeX->HTML conversion. >>> 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. >>> 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. > Actually, I'm not that interested in HTML output myself at all. But > there are other people who are: It's a very common request, as you > yourself have seen by the excitement about eLyXer. So, qua developer who > tries to be responsive to users' needs, I'm interested and trying to > figure out how best to do this. HTML and LaTeX are so far apart that there is no "best way". Rather the expectations and needs of the users are so different that there is plenty of room for several translators. Some examples: * Compatibility with old or nonconforming but widespread browsers <--> advanced use of CSS features (e.g. numbering). * Viewable without MathML plugin/capability <--> keeping formulas in a machine readable format. * Preservation of look <--> preservation of semantic. * Simplicity <--> configurability. * Simplicity <--> feature completeness. 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. 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. * Clean HTML that preserves the semantic. Keeps the WYSIWYM idea. * No pixmaps for math (I favour MathML and think there is some work that can be used in the Docutils sandbox (latex-math extension).) >>> LyX will always output to plain text, and that's readily importable >>> in Word. But all structure is lost. >>> If one wants to output to a format that preserves a good bit of the >>> formatting, then latex2rtf does a fine job, so long as you don't >>> have too much math, etc. I expect a good written HTML+CSS to preserve more of the semantic and structure than rtf. ... > My point was much the same as Pavel's: the existing tools actually do > much the same sort of job, and just about as well, though perhaps with > fewer bells and whistles. See above. > What I thought would be the advantage of eLyXer, or some such tool, was > that it would do a BETTER job It does do a DIFFERENT job (better for some tasks). > and support MORE features. sometimes "less is more" (cf. the Unix philosophy of doing one job well). > But eLyXer supports fewer, at present. Maybe it can support more. > That'd be great. What I'm interested in, qua developer, is how to get > the BEST output we can get, in whatever formats people need. ... >>> So the question is: What do we have to do if we're going to get >>> really good HTML output for more than fairly simple LyX files, let >>> alone for LyX's full functionality? Construct an open framework where it is easy to plug in tools that do what you need. >> Nope, sorry. The question is: do you want to do a reasonable >> conversion for 99% of your potential users and support their simple >> needs, or do you want to embark in a hard, difficult, error prone and >> laborious task? For me the answer is clear. > ...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, ... > But even as things are, we very much hope that anyone who uses LyX for > serious work will use it the way it is intended, with as many custom > layouts and character styles as they need to create to produce true > semantic markup. Support for true semantic markup should be easy. HTML + CSS is made for this. Finding nice presentation styles is a different task (quite similar to LyX layouts this requires an deep understanding of two languages...) > 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? >>> 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.) Replicating the eLyXer functionality in LyX/C++ might be easy but the remaining difficulties are similar for both approaches. 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 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). Günter
