[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lyx-devel
Subject:    Re: HTML Output for LyX
From:       Guenter Milde <milde () users ! berlios ! de>
Date:       2009-04-30 23:07:03
Message-ID: gtdaun$qv8$1 () ger ! gmane ! org
[Download RAW message or body]

On 2009-04-30, Richard Heck wrote:
>> On Thu, Apr 30, 2009 at 4:13 PM, Richard Heck <rgheck@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

[prev in list] [next in list] [prev in thread] [next in thread]