[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:       Alex Fernandez <elyxer () gmail ! com>
Date:       2009-04-29 22:13:04
Message-ID: 2110ee000904291513t2a177890m480927d8da54918 () mail ! gmail ! com
[Download RAW message or body]

Hi again, Richard,

On Wed, Apr 29, 2009 at 5:03 PM, rgheck <rgheck@bobjweil.com> wrote:
> 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.

Of course I cannot assure that more people of the team will be ready
to dedicate the effort required. All I can do is isolate all format
information so that parsing code is easily located.

> 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.

That we will see when we get there. Up to now it has really been
mostly trivial -- the changes from 1.5.x to 1.6.2 might have been done
in a dot release (say, a week).

> 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.

The framework is extensible in several respects. The first one is of
course with code. But a much better way only requires CSS. Unknown
layouts do not generate errors, but new HTML <div> classes. Adding
support in the CSS is trivial. Similarly, unknown insets generate
<span> tags with a characteristic span. As to new macros, LaTeX
commands and ERT, they are not supported at this point.

If you would be so kind as to send me a sample I would be delighted to
help make theorems work.

> 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.

BibTex is not working at the moment. Again, a sample would be appreciated.

> 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.

A single-pass converter cannot possibly output the actual number of
the linked section, or the text -- it will first find the reference
and a few kb later (once that part of the document is parsed) the
label. A second pass would be required to make labels work properly,
and the second pass is still in the works. But this should work,
eventually.

> 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.

Fair enough. My views are much more simplistic: LyX currently doesn't
do what 99.9% of users need, which is output to different formats
including HTML and/or something importable from within Word. Thus
many, many people don't know about an otherwise wonderful editor. The
needs of these users (and of the majority of current users IMHO) would
be adequately served by an HTML export tool which generates anything
that does not look like garbage. Nobody is volunteering to write a
tool that does what you want, so LyX could very well use what eLyXer
offers. But perhaps as you say integration is not such a good idea.
Separate packaging and distribution might be an enabler for people,
especially if the most popular versions (Windows, Debian) do a joint
distribution.

> 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.

Good luck with that. The problem is orders of magnitude harder than a
LyX to HTML converter. As Kernighan and Plauger put it, "it is much
more useful to do part of the job well than the whole thing badly (or
not in time)".

Thanks,

Alex.
[prev in list] [next in list] [prev in thread] [next in thread]