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

List:       lyx-devel
Subject:    Re: Official submission of eLyXer for inclusion in LyX
From:       rgheck <rgheck () bobjweil ! com>
Date:       2009-04-29 15:03:47
Message-ID: 49F86C53.5090905 () bobjweil ! com
[Download RAW message or body]

Alex Fernandez wrote:
> Hi Uwe,
>
> On Wed, Apr 29, 2009 at 3:13 AM, Uwe Stöhr <uwestoehr@web.de> wrote:
>   
>> Your eLyXers is much better than tex4ht as far as I tested. I therefore plan
>> to include eLyXer to my Windows installer.
>>     
>
> That is an interesting possibility: not include the code in LyX and
> just redistribute the executable file as is. I'm all for it.
>
>   
The main advantage to going that way, in my opinion, is that I'm not 
sure the LyX team wants to commit to maintaining this converter. Even if 
we made you part of the team (i.e., gave you commit rights), still, 
having one person who's willing to do it isn't sufficient: We, as a 
group, would still have to make suitable changes every time the file 
format changes (which it already has several times in 2.0.svn), which we 
already do for lyx2lyx. The alternative would be to try to integrate it 
with lyx2lyx, as has been suggested several times. But having had a 
quick look at the code, I really don't see how that can be done. The 
whole thing is very dependent upon the 1.6 format. Of course, we can 
export 2.0 to 1.6 and then eLyXer can work on that, but that's a very 
different matter.

And despite the successes so far, which are real, I still have my doubts 
about whether this is the right way to go, longer term. The first issue 
is maintainability. The LyX file format sometimes undergoes big changes, 
and if we weren't moving (slowly, and maybe) to an XML-based format, I'd 
be about to make some more such changes, just to simplify parsing. Not 
to mention that the format changes to support new features. And if we do 
go to XML, which we surely will eventually, then the program needs, from 
what I can tell, a more or less complete rewrite, since it'll want to be 
based upon some XML parser. So maintenance, just to keep eLyXer up to 
date, is not trivial.

What's more problematic, to my mind, is that the framework isn't 
extensible. Yes, I know that the programmer can add support for new 
layout types, etc, but as things now stand even simple layouts like 
Theorem aren't supported. Yes, those could be added. But LyX itself is 
extensible, as LaTeX is, and that's a crucial thing about it. If I 
define some new character styles, or new layouts of some other sort, 
then they're not handled and *can't* be handled without making eLyXer 
aware of what the LaTeX commands that define these styles mean. But then 
we're back to writing a LaTeX to HTML converter. Similarly, I think it 
will be a challenge to provide proper support for math macros, let alone 
for things people do using ERT.

Similarly, at present, so far as I can tell, there is no support for 
BibTeX. Is that right? In my conversions, I get little raised numbers, 
but they don't link to anything.

Also, crossrefs appear as little arrows, which is nice, except that you 
don't get the corresponding text, which makes things like "In [arrow], 
we will discuss..." hard to read.

Let me just be clear about the nature of these criticisms. It may well 
be that eLyXer will be a good program for use by people whose LyX files 
are very basic, don't use much math, don't define custom styles, and the 
like. If so, then so; there are plenty of people for whom that is plenty 
good enough. But if this program is going to be included in LyX, then, 
in my opinion, it needs to handle the LyX format, pretty much without 
exception. Yes, there may be some special cases it doesn't quite handle, 
but, mostly, it should do what LyX does, and it absolutely needs to 
handle math cleanly. Right now, and with all due respect, it doesn't 
come close.

My own view, for what it's worth, is that there is no stable way to go 
here except to have LyX output the LaTeX, which it does well, and then 
convert that. Otherwise, I don't see how you will ever get proper 
handling of math macros, character styles, new layouts, and the like. 
And if I were going to work on that, then I'd work on plastex, which 
seems to me generally to do a pretty good job. At the very least, one 
can use the plastex parser and write a new output routine.

rh

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