Re: Some poll about elyxer
Christian Ridderström wrote: LyX is a large piece of software with complicated relationsships to other softwares, and it's used in many different ways by many different types of users. This means that someone new can't have a feeling for the overall picture, actually, I doubt any of the "old" developers really have the overall picture either. It's one of the terrifying things about LyX that no-one, from what I can tell, actually understands everything about how it works. Maybe Andre or JMarc have a fairly synoptic picture of the thing, and Vincent seems to be headed that way. But mostly, we each have our piece, and we get our heads together when we need to. That can lead to some interesting discussions. Richard
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
On 2009-05-10, Alex Fernandez wrote: > Welcome back, Christian, > On Sun, May 10, 2009 at 6:56 PM, Christian Ridderström wrote: >> I'm not sure if the above is what eventually got decided, but if so >> one way to "officially" recognise eLyXer is to let Alex create a web >> page about inside www.lyx.org. and (IMO more important) to document HTML export in the UserGuide (A 1.11. Export and 3.8.2 Output file formats. > I have a pending request to make a better exporter (and copier) from > within LyX, but lack expertise to do a good job currently. In the Unix philosophy of "one tool per task", eLyXer can concentrate to convert one LyX format to HTML and rely on lyx2lyx for the conversion of other LyX formats into the supported one. If there is interest I volunteer to work on the eLyXer - lyx2lyx integration. > My hope is that eLyXer will be distributed along LyX on some major > platforms (Windows, Ubuntu, maybe Mac) and more people will have access > to it. I think there is consensus about this. Günter
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
On Sun, 10 May 2009, Alex Fernandez wrote: Welcome back, Christian, It's nice to be back! (Actually, it's nice to be able to use pine, and to be able to access the lists as news groups :-) Apologies in advance for what became a rather long post. There are no technical insights regarding the actual topic, but instead an attempt to try and explain "softer" issues. With emphasis on "attempt":-) Thanks, I already did the wiki part: http://wiki.lyx.org/Tools/ELyXer The project currently lives on nongnu.org: http://www.nongnu.org/elyxer/ Let me know if you'd like to also have a page in the official site, i.e. www.lyx.org, in which case I'll send you the password for editing those pages (they are actually wiki pages in disguise). I certainly trust you to behave responsibly. As a side note, I am certainly willing to give you commit privileges to the repository. The latter requiers some other stuff (like me figuring out how to actually do that...). Anyway, I think you carried yourself splendidly in the (sometimes, typically on Fridays) harsh world of the LyX developers list. As to what happened, after some time (and with a certain perspective) I can tell you my subjective impressions and we can compare notes afterwards. My offer for integration of eLyXer got quite a hostile reception: some deserved criticism was received, along with some undeserved bashing. Apparently it conflicts with some future switch to an XML format which will solve all problems. In the end very little help was offered (with the honorable exception of Uwe Stöhr) and much infighting was caused so I withdrew the offer. I spent some time reading through most of the posts on these topics today, and as a way of comparing notes I can give you my (outside) view of the matter. First off I should say that I didn't actually consider the actual matter at hand, as anything I'd say would probably be way to late to make a difference. In that respect I'm of course to blame for not following the list, apologies for that. To start with, I can definitely see why you felt that you got a hostile reception. However, my honest view about your reception differs quite a bit from your interpretation I think you got a "great" reception! Now I know that you probably think that's odd to say the least, but consider this: * Lots of developers _cared_ about the work you had done, which is a that what you're working on is something that matters! * Your work (code) was respected! * Developers discussed it, you and your work inspired others to talk about the issues involved in exporting HTML. To phrase it differently: You were treated as just another developer. Yes, there were certainly differences in opinion and philosphy, but as far as I could see that had _nothing_ to do with you. Instead, it was about the actual problem which is simply put ill-posed and generally tricky. You've probably noticed something else as well: On this list people will question your choices in how to do things. You may have to argue for why your solution is bad. As someone who is new (or perhaps I should say "used to be new":-), you'll have to argue more before others will trust your judgement. This lack of trust has nothing to do with you as a person, but rather that "we" don't know how well you know the topic at hand. LyX is a large piece of software with complicated relationsships to other softwares, and it's used in many different ways by many different types of users. This means that someone new can't have a feeling for the overall picture, actually, I doubt any of the "old" developers really have the overall picture either. You (and eLyXer) is certainly solving a problem and acomplishing something. A big question is if it's the right problem that's being solved, and if it is solved in a way that'll keep working in the future, or will this solution be something that in the future leads into a black pit? It's completely unreasonably to expect that you'd be able know the answer to these kinds of questions. I certainly don't, and this business about exporting stuff is especially hairy as I don't think it's a well defined problem. So what happens on the list in this case is that people start discussing it, which in essence is good. Now, I might be a bit too used to the tone of the list on Fridays, but I didn't see any personal attacks on you. In fact, to me it seemed that you were mostly treated with respect, or more specifically, that your work was treated with respect. Right now my efforts are focused on making eLyXer even better, as you can see in the changelog: http://www.nongnu.org/elyxer/changelog.html I have a pending request to make a better exporter (and copier) from within LyX, but lack expertise to do a good job currently. This last part is a bit like greek to me, but I take you'd like to change something inside LyX? I'm sure others will reply to that. My hope is that eLyXer will be distr
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Welcome back, Christian, On Sun, May 10, 2009 at 6:56 PM, Christian Ridderström wrote: > I'm not sure if the above is what eventually got decided, but if so one way > to "officially" recognise eLyXer is to let Alex create a web page about > inside www.lyx.org. Actually, I think we could probably do this regardless > of which path is chosen. Or Alex can of course use the wiki. Thanks, I already did the wiki part: http://wiki.lyx.org/Tools/ELyXer The project currently lives on nongnu.org: http://www.nongnu.org/elyxer/ As to what happened, after some time (and with a certain perspective) I can tell you my subjective impressions and we can compare notes afterwards. My offer for integration of eLyXer got quite a hostile reception: some deserved criticism was received, along with some undeserved bashing. Apparently it conflicts with some future switch to an XML format which will solve all problems. In the end very little help was offered (with the honorable exception of Uwe Stöhr) and much infighting was caused so I withdrew the offer. Right now my efforts are focused on making eLyXer even better, as you can see in the changelog: http://www.nongnu.org/elyxer/changelog.html I have a pending request to make a better exporter (and copier) from within LyX, but lack expertise to do a good job currently. My hope is that eLyXer will be distributed along LyX on some major platforms (Windows, Ubuntu, maybe Mac) and more people will have access to it. (By the way, the switch to elyxer.py has been ready for some time now, Uwe.) Meanwhile some folks are trying to make LyX export HTML directly but haven't started figuring out how. I don't think they will ever release anything, and yet cannot blame them for trying. Alex.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
On Sat, 2 May 2009, Jürgen Spitzmüller wrote: What we should do: * recognize eLyXer as a HTML converter (already done, AFAICS) * communicate whether both in eLyXer or LyX, something could be improved to make their cooperation easier What we could do (given that Alex supports this idea): * provide a separate eLyXer branch in our SVN for its development * distribute eLyXer as a separate tool via our infrastructure (and hence make clear it is a tool we support) Hi everybody, I'm not sure if the above is what eventually got decided, but if so one way to "officially" recognise eLyXer is to let Alex create a web page about inside www.lyx.org. Actually, I think we could probably do this regardless of which path is chosen. Or Alex can of course use the wiki. Best regards, /Christian -- Christian Ridderström Mobile: +46-70 687 39 44
Re: Some poll about elyxer
Alex Fernandez wrote: > As to the first issue, what do you suggest? Maybe a custom copier > could copy images to /tmp? either reuse the the already existing copier(s) in our tree our writing the new one. (i guess that the copiers we already have should be enough. just look only ho other convetors use copiers themselves.) moreover you will probably need it for getting the converted files into EmbeddedObjects.html.LyXconv. > Still I don't very much like this approach, and > would very much do a conversion in place (without going through /tmp). this is the wrong way. you will polute the document directory just because somebody tries view->html. pavel
Re: Some poll about elyxer
Hi Pavel, On Mon, May 4, 2009 at 12:48 PM, Pavel Sanda wrote: >> Sorry, I must have missed the question in the turmoil. Can you give me >> a pointer? > > tools -> preferences -> file formats -> html (elyxer) -> copier > > see copiers section in customization manual. this maybe the cause why images > didn't work for me with your converter. i dont think that file->export > will work without correctly setting this. After a few recompilations and some tinkering I think I know why images are not working. (I used the EmbeddedObjects.lyx guide.) eLyXer is actually working in the /tmp directory, and the result is then copied back to the document directory. Unfortunately there are no images to convert in the /tmp directory, so eLyXer doesn't find them and cannot convert them. Furthermore, the copier takes the /tmp/*/EmbeddedObjects.html file and moves it to a folder called EmbeddedObjects.html.LyXconv, and places the actual file EmbeddedObjects.html inside. So even if the image can be directly embedded inside the HTML (like a PNG), and needs no conversion, the HTML file does not find it. Removing the copier altogether (so that just the plain EmbeddedObjects.html is copied) solved this last problem. As to the first issue, what do you suggest? Maybe a custom copier could copy images to /tmp? I see that other converters place versions of the images there. Still I don't very much like this approach, and would very much do a conversion in place (without going through /tmp). Unfortunately I don't think this is possible. Any ideas? Thanks, Alex.
Re: Some poll about elyxer
Pavel Sanda wrote: > something like the attached; though i don't know where exactly to put it > in annoucement. put it in ANNOUNCE, not status.16x. I'll try to include it in the proper announcement text. Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > > no i mean something different - the correct y-coord is saved even in > > 4.4.3. i want it to have it there by default. my session settings are > > reset every other moment since the developing process... > > I don't know if this (default positioning) is possible, but it would of > course be good if it was (not only for the view toolbar). me neither. Abdel? > have to change our toolbar code. > > > qt 4.5 fixed the x-coord issue fyi. i have plan to write small summary > > paragraph about qt 4.5 and 1.6.3 in status file if i get green ligth from > > you. > > OK, just post a proposal. something like the attached; though i don't know where exactly to put it in annoucement. pavel Index: status.16x === --- status.16x (revision 29534) +++ status.16x (working copy) @@ -18,7 +18,15 @@ What's new == +* Lyx 1.6.3 and Qt 4.5 +Note that Qt comes with some fixes and new features for which LyX 1.6.3 has +been adjusted. Most notably the often reported bug of not remembering correct +toolbar position is gone. Except fixed crash with the new Qt release we enabled +menu support for fullscreen mode in linux and moved close button to each opened +tab of file. + + ** Updates: ***
Re: Some poll about elyxer
On Saturday 02 May 2009 00:30:04 Alex Fernandez wrote: > Thanks to all those who voted for inclusion of eLyXer in LyX. Thanks > go specially to Uwe Stöhr for his whole-hearted support of eLyXer. > > Let me now withdraw my offer to include eLyXer in LyX. There are many > reasons for this; let me explain them the long way since I think the > issue is important. > > First, this discussion (and the many threads around it) are causing > unnecessary division among LyX developers. People are suffering > unnecessary pain because of this. And this because everyone is trying > to do the right thing for LyX, but nobody agrees what this thing is. I > think we all need to take a step back and try to find out what the > best way to help users. Personally I found this discussion to be quite civil. :-) > Second, a poll (despite the obvious good intentions behind it) is the > wrong way to go about an issue like this one. As long as people have > valid concerns they have to be answered; and if those concerns are > invalid then they have to be explained away. But just winning 5-to-4 > is no guarantee that the outcome will be positive. The best way to win one of this discussion is to show code and you have done that. :-) > Third, to make eLyXer as useful as possible it _needs_ to have a > separate life from LyX. Even if it has no meaning without LyX. This is > because the goals of each project are different in a few crucial > respects. For one, eLyXer should support most known versions of LyX > documents _at the same time_. When support for LyX 1.6 was added, the > now obsolete 1.5 format was kept for backwards compatibility. If > eLyXer resided within LyX then that support would be ditched since > lyx2lyx already keeps compatibility. But then an eLyXer user would > need the whole LyX infrastructure to read a LyX document. Similarly, > eLyXer can be a valuable resource for people who want to read LyX > documents but do not have LyX (because they don't want, or because > they cannot run it). Remember, Python runs on many more platforms than > LyX; having a way to visualize documents on those platforms would make > LyX more useful. A technical note, please don't make the mistake to support several lyx file formats at the same time. LyX has done that for some time and I can tell you that the resulting code will be a nightmare to maintain quite soon. My suggestion is for you to take any of the stable release file format and to focus on that. The lyx2lyx code is almost self-contained and in the worst scenario you could keep a private copy of lyx2lyx, the license of lyx2lyx is GPL2+ so it should be possible. Better yet would it be to integrate it with lyx's version of lyx2lyx. Note also that I am quite eager to create a stable API to export to other applications. Here elyxer could a client of the lyx2lyx code. I am open to this possibility. :-) > I naïvely thought that eLyXer could survive integration and still keep > a separate life. Code could be exchanged (as from trunk to branch, and > back) and everyone's codebases and lives would get richer in the > process. After Uwe's exposition I see that it is quite impossible. > > IMHO LyX needs a way to output HTML to maximize its usefulness. If a > new way to output HTML natively emerges then it will probably have > been worth it to cause this infight. Meanwhile joint distribution > would fulfill our common goals nicely. I will support Uwe as much as > possible to bundle eLyXer in the Windows installer, and the same for > Linux distributions, which should eventually reach most users. Joint > distribution might go as far as bundling the main elyxer.py file in > released versions. I agree that a better conversion to html is a bonus. > If the LyX community still wants to integrate eLyXer and it causes no > conflicts (i.e. everyone agrees on it) I will happily offer it again. > But in this circumstances I think it is best if the two codebases stay > separate. I am sorry for all the conflict that I have caused, I should > have thought the thing over (and especially any adverse consequences) > before making my offer. In my eagerness to offer something back to the > community (and also to earn some recognition) I rubbed some people the > wrong way. Now all I can do is apologize and try to help mend the > bridges. Your effort to improve lyx is appreciated. On the other hand note that some of objections drawn here are valid and try to work to solve them. Don't be afraid to ask questions this list is quite friendly (really, I am not making this up). :-) > Thanks for getting this far, If I was an old guy I could tell you that there were previous discussion in the past regarding other issues. Like the fact that lyx2lyx is python and how much time it took to integrate it with LyX. But since I am not I telling you this. ;-) > Alex. Regards, -- José Abílio
Re: Some poll about elyxer
Pavel Sanda wrote: > no i mean something different - the correct y-coord is saved even in > 4.4.3. i want it to have it there by default. my session settings are > reset every other moment since the developing process... I don't know if this (default positioning) is possible, but it would of course be good if it was (not only for the view toolbar). We would probably have to change our toolbar code. > qt 4.5 fixed the x-coord issue fyi. i have plan to write small summary > paragraph about qt 4.5 and 1.6.3 in status file if i get green ligth from > you. OK, just post a proposal. Jürgen
Re: Some poll about elyxer
Vincent van Ravesteijn schrieb: please join this discussion. What do you mean? I've already send about 20 emails about this thread ore more on and off the list. Concerning http://www.lyx.org/trac/ticket/5934 this is not possible due to the reason I stated in the bug report: On Windows you don't have Python installed and we only deliver the Python files we really need - the same way as other programs do like OpenOffice etc. regards Uwe
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > another thing which sukcs in our view/update ui is that the very small > > toolbar is filling up the whole third line of toolbars, effectivelly taking > > the space for workarea. would be better/possible to move it on the right > > side of the rirst toolbar? > > Certainly, that's where I want to have it as well. The problem up to Qt 4.5 > (or for that matter Qt 4.4.4, if that ever is going to be released) is that > this position was not restored (we had a ticket for this). > > If you already use Qt 4.5, it should stick at the correct place over sessions > once you have dragged it with the mouse (I cannot test, I have Qt 4.4.3 here). no i mean something different - the correct y-coord is saved even in 4.4.3. i want it to have it there by default. my session settings are reset every other moment since the developing process... qt 4.5 fixed the x-coord issue fyi. i have plan to write small summary paragraph about qt 4.5 and 1.6.3 in status file if i get green ligth from you. pavel
Re: Some poll about elyxer
Pavel Sanda wrote: > another thing which sukcs in our view/update ui is that the very small > toolbar is filling up the whole third line of toolbars, effectivelly taking > the space for workarea. would be better/possible to move it on the right > side of the rirst toolbar? Certainly, that's where I want to have it as well. The problem up to Qt 4.5 (or for that matter Qt 4.4.4, if that ever is going to be released) is that this position was not restored (we had a ticket for this). If you already use Qt 4.5, it should stick at the correct place over sessions once you have dragged it with the mouse (I cannot test, I have Qt 4.4.3 here). Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > C'mon! there must some major sun's eruption when even germans start to use exclamation mark :) > Maybe, maybe not. In any case, I do not see a way to put it back without > cluttering the menu. i would accepts this cluter; anyway as i said previously i can solve this privately... another thing which sukcs in our view/update ui is that the very small toolbar is filling up the whole third line of toolbars, effectivelly taking the space for workarea. would be better/possible to move it on the right side of the rirst toolbar? pavel
Re: Some poll about elyxer
Alex Fernandez wrote: > > and set elyxer the way you want. you still haven't answered the question > > about using the copiers. > > Sorry, I must have missed the question in the turmoil. Can you give me > a pointer? tools -> preferences -> file formats -> html (elyxer) -> copier see copiers section in customization manual. this maybe the cause why images didn't work for me with your converter. i dont think that file->export will work without correctly setting this. pavel
Re: Some poll about elyxer
On Sunday 03 May 2009 00:04:13 Alex Fernandez wrote: > Done: > http://www.lyx.org/trac/ticket/5934 > > Alex Note that although lyx2lyx was built from ground up to be a python library it is not mostly because of the support for windows. Note that meanwhile you can add the lyx2lyx path to the modules search path and it will work as intended. We used to did it to create the TOC files in 1.6.x (or was it 1.5.x?). -- José Abílio
Re: Some poll about elyxer
Jürgen Spitzmüller writes: > Apparently not. As far as I understand, the problem is that XPDF used a > different method to display T1 fonts (fontspec?). The problem seems to be > well > known. See e.g. > https://bugs.freedesktop.org/show_bug.cgi?id=21061 Nice to know. Thanks. JMarc
Re: Some poll about elyxer
Jean-Marc Lasgouttes wrote: > > I use KPDF (which uses XPDF as a backend). This is fast and renders the > > text as good as acroread. The new okular (with poppler backend) is way > > behind when it comes to rendering (at least LaTeX-generated PDFs). > > This is weird. I thought poppler was just the xpdf code repackaged... Apparently not. As far as I understand, the problem is that XPDF used a different method to display T1 fonts (fontspec?). The problem seems to be well known. See e.g. https://bugs.freedesktop.org/show_bug.cgi?id=21061 Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller writes: > I use KPDF (which uses XPDF as a backend). This is fast and renders the text > as good as acroread. The new okular (with poppler backend) is way behind when > it comes to rendering (at least LaTeX-generated PDFs). This is weird. I thought poppler was just the xpdf code repackaged... JMarc
Re: Some poll about elyxer
Pavel Sanda wrote: > > Remember that up to 1.6.x, you had to enter a submenu for any update view > > action. > > i was not talking about updating actions. if my brain by accident remembers > to use update mechanism, then it rememebers ctrl+shift+t as well ;) And not the corresponding view shortcuts? C'mon! > > (I understand that change is always annoying unless you get used to it.) > > the fact that i was already thinking whether is cheaper to patch my install > scripts to add pdf&ps to menu or put it in my ~/.lyx ui files simply shows > that the new interface sucks more than enough for my usecases. i considered > this as my own problem until Richard raised the voice - maybe it is problem > of wider audience of users. Maybe, maybe not. In any case, I do not see a way to put it back without cluttering the menu. > >You use acroread to view PDF files? Then you don't have my sympathy ;-) > > btw what readers under linux are to be recommended ? I use KPDF (which uses XPDF as a backend). This is fast and renders the text as good as acroread. The new okular (with poppler backend) is way behind when it comes to rendering (at least LaTeX-generated PDFs). There are really very raw occassions when I need acroread. Jürgen
Re: Some poll about elyxer
Hi Pavel, On Mon, May 4, 2009 at 2:55 AM, Pavel Sanda wrote: > i fixed the detection. please update trunk and check lyx detected > and set elyxer the way you want. you still haven't answered the question > about using the copiers. Sorry, I must have missed the question in the turmoil. Can you give me a pointer? Thanks, Alex.
Re: Some poll about elyxer
Alex Fernandez wrote: > Version 0.18 has been published: > http://download.savannah.gnu.org/releases-noredirect/elyxer/ > It contains the desired change from elxer to elyxer.py. i fixed the detection. please update trunk and check lyx detected and set elyxer the way you want. you still haven't answered the question about using the copiers. bye for now pavel
Re: Some poll about elyxer
Hi Uwe, On Sat, May 2, 2009 at 12:14 AM, Uwe Stöhr wrote: >> Good to know. I thought it was cute to remove the extension but >> apparently this is causing problems. I will change this so that the >> main executable file is "elyxer.py", and the main source code file is >> e.g. "main.py". > > Yes, this would be better. Version 0.18 has been published: http://download.savannah.gnu.org/releases-noredirect/elyxer/ It contains the desired change from elxer to elyxer.py. Thanks, Alex.
Re: Some poll about elyxer
Alex Fernandez schreef: On Sun, May 3, 2009 at 12:32 AM, rgheck wrote: This would become even easier if LyX would install lyx2lyx as a normal Python package. It might be worth requesting this explicitly as an enhancement. Surely it can't be that hard. Done: http://www.lyx.org/trac/ticket/5934 Alex Uwe, please join this discussion. Vincent
Re: Some poll about elyxer
Pavel Sanda wrote: You use acroread to view PDF files? Then you don't have my sympathy ;-) btw what readers under linux are to be recommended ? long time ago i tried available free viewers like xpdf for a while and then i respectfully returned back to acroread. i regularly use and need things like fullcreen mode, color exchange for text and background, continuous mode, reasonable caching of pages around so jumping around is fast and very good rendering engine - normal antialias is bad on my lcd screen and adobe soft somehow managed that even small fonts are readable here. only from version 8 the lauch time rapidly increased, so i peek what happened menawhile in foss... I still use kpdf, but then again I'm still on KDE 3.5.x. I don't really care for evince, and I haven't yet seen okular, though I'm going to take the KDE 4 plunge before long, so I guess I'll see it then. rh
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: > Remember that up to 1.6.x, you had to enter a submenu for any _update_ view > action. i was not talking about updating actions. if my brain by accident remembers to use update mechanism, then it rememebers ctrl+shift+t as well ;) > (I understand that change is always annoying unless you get used to it.) the fact that i was already thinking whether is cheaper to patch my install scripts to add pdf&ps to menu or put it in my ~/.lyx ui files simply shows that the new interface sucks more than enough for my usecases. i considered this as my own problem until Richard raised the voice - maybe it is problem of wider audience of users. >You use acroread to view PDF files? Then you don't have my sympathy ;-) btw what readers under linux are to be recommended ? long time ago i tried available free viewers like xpdf for a while and then i respectfully returned back to acroread. i regularly use and need things like fullcreen mode, color exchange for text and background, continuous mode, reasonable caching of pages around so jumping around is fast and very good rendering engine - normal antialias is bad on my lcd screen and adobe soft somehow managed that even small fonts are readable here. only from version 8 the lauch time rapidly increased, so i peek what happened menawhile in foss... pavel
Re: Some poll about elyxer
On 03/05/2009 18:31, Vincent van Ravesteijn wrote: Jürgen Spitzmüller schreef: Pavel Sanda wrote: i didn't like the change made for default format either. i regularly use both pdf and ps generation and it is bit annoying to track it in some submenu now... For one document? Could you elaborate a bit on the rationale for this? Jürgen I'm not complaining, but I'm constantly switching between dvi and pdf (ps2pdf). Previewing with dvi is faster than pdf, but the dvi-viewer on windows (yap) is very slow and frustrating in use. Yap is a pain in the ass. With latest Miktex and Foxit I've found that pdflatex viewing was as fast as dvi on windows. Abdel.
Re: Some poll about elyxer
Pavel Sanda wrote: > i don't claim to have rationale ;) its just that the whole reorganization > was annoying enough to registrate it for the the few occiasions i worked > with trunk recently. Remember that up to 1.6.x, you had to enter a submenu for any _update_ view action. Here we have a clear step forward in trunk: you have both update and view (default) in the main menu. Update for other formats is still in a submenu, unchanged. So "only" the move of view other formats might count as a workflow brake. However, given that update is the more frequent action (at least for me), I think the change rather speeds up the workflow in the end. (I understand that change is always annoying unless you get used to it.) >when i debug output or when i'm in a hurry i tend to use ps just for the > speed reasons - acroread became such a monstrum that i have to wait for > half a minute to launch it. on the other hand i tend to use pdf once it is > in cache or i'm sending the output to my collaborators/publishing > somewhere. You use acroread to view PDF files? Then you don't have my sympathy ;-) Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: > > i didn't like the change made for default format either. i regularly use > > both pdf and ps generation and it is bit annoying to track it in some > > submenu now... > > For one document? Could you elaborate a bit on the rationale for this? i don't claim to have rationale ;) its just that the whole reorganization was annoying enough to registrate it for the the few occiasions i worked with trunk recently. when i debug output or when i'm in a hurry i tend to use ps just for the speed reasons - acroread became such a monstrum that i have to wait for half a minute to launch it. on the other hand i tend to use pdf once it is in cache or i'm sending the output to my collaborators/publishing somewhere. pavel
Re: Some poll about elyxer
Jürgen Spitzmüller schreef: Pavel Sanda wrote: i didn't like the change made for default format either. i regularly use both pdf and ps generation and it is bit annoying to track it in some submenu now... For one document? Could you elaborate a bit on the rationale for this? Jürgen I'm not complaining, but I'm constantly switching between dvi and pdf (ps2pdf). Previewing with dvi is faster than pdf, but the dvi-viewer on windows (yap) is very slow and frustrating in use. So, I often also view as pdf, when I want to scroll through the document quickly, to see whether everything is placed correctly and nicely and to see how the pages break and so forth. Vincent
Re: Some poll about elyxer
Pavel Sanda wrote: > i didn't like the change made for default format either. i regularly use > both pdf and ps generation and it is bit annoying to track it in some > submenu now... For one document? Could you elaborate a bit on the rationale for this? Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: > rgheck wrote: > > Probably. But---no offense---I'm not sure I like the menu as it now is. > > Having "View" and "View (other formats)" initially confused me. I don't > > really have a suggestion to make, though. Could we go back to the older > > version and just have "View (default)" on top, with the rest as they were? > > I wouldn't do this. The rationale is that you usually only need one (the i didn't like the change made for default format either. i regularly use both pdf and ps generation and it is bit annoying to track it in some submenu now... pavel
Re: Some poll about elyxer
rgheck wrote: > Probably. But---no offense---I'm not sure I like the menu as it now is. > Having "View" and "View (other formats)" initially confused me. I don't > really have a suggestion to make, though. Could we go back to the older > version and just have "View (default)" on top, with the rest as they were? I wouldn't do this. The rationale is that you usually only need one (the default) format, while the others just clutter the menu. Also, we now have additional entries in that menu, if you edit a child, namely "View Master" and "Update Master". The menu was already overpopulated before. > It also seems as if there ought to be a single shortcut for View > (default), whatever that might be. Of course, shortcuts are always at a > premium. Yes, definitely. Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: rgheck wrote: I agree. How do you feel about the proposal I made, that we list anything with multiple options as a submenu? In trunk, "View (other formats)" is already a submenu. So your proposal would generate sub-submenus, which is no good idea, IMHO. I hadn't actually looked at that before, but now I remember you're doing this. Having said that, maybe putting the entries in the already existing submenu is good enough? Probably. But---no offense---I'm not sure I like the menu as it now is. Having "View" and "View (other formats)" initially confused me. I don't really have a suggestion to make, though. Could we go back to the older version and just have "View (default)" on top, with the rest as they were? It also seems as if there ought to be a single shortcut for View (default), whatever that might be. Of course, shortcuts are always at a premium. Richard
Re: Some poll about elyxer
rgheck wrote: > I agree. How do you feel about the proposal I made, that we list > anything with multiple options as a submenu? In trunk, "View (other formats)" is already a submenu. So your proposal would generate sub-submenus, which is no good idea, IMHO. Having said that, maybe putting the entries in the already existing submenu is good enough? Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: Pavel Sanda wrote: Exactly. It does not complement at all, it just would be the right consequence of the eLyXer separation. does it mean you agree with Richard's proposal? Principally, yes. However, this is nothing for 1.6.3. We first have to find out how this fits our UI (menu cluttering might be a real problem). I agree. How do you feel about the proposal I made, that we list anything with multiple options as a submenu? rh
Re: Some poll about elyxer
Pavel Sanda wrote: > > Exactly. It does not complement at all, it just would be the right > > consequence of the eLyXer separation. > > does it mean you agree with Richard's proposal? Principally, yes. However, this is nothing for 1.6.3. We first have to find out how this fits our UI (menu cluttering might be a real problem). Jürgen
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: > Exactly. It does not complement at all, it just would be the right > consequence > of the eLyXer separation. does it mean you agree with Richard's proposal? pavel
Re: Some poll about elyxer
rgheck wrote: > > hehehe i see it will be bit hard to get some agreement here since thats > > complentary draft to Juergens... :) > > > > > > Yes, I know. But I think J"urgen meant more "why do this one special?" > whereas I mean: We should do them all differently. Exactly. It does not complement at all, it just would be the right consequence of the eLyXer separation. Actually, the same counts for makeindex vs. xindy and bibtex vs. bibtex8 (vs. biber). But that's another (more difficult) story, to which I'll come back soon. Jürgen
Re: Some poll about elyxer
Am Sonntag 03 Mai 2009 schrieb rgheck: > Alex Fernandez wrote: > > Hi Guenter, > > > > On Sat, May 2, 2009 at 11:10 PM, Guenter Milde wrote: > >> It should be mentioned that (AFAIK), lyx2lyx works (and can be > >> installed) independent of LyX. At least I could successfully use a > >> lyx2lyx from trunk to import "1.6" documents with 1.5.4. > > > > Hmmm, that is interesting. It certainly puts what Kornel suggested in > > a new light. If eLyXer could find lyx2lyx and make it work for > > itself... > > Maybe the easiest thing for you to do would just be to borrow the > lyx2lyx code, and update that from trunk periodically. Then you just > make it part of your executable and you don't have to worry about > finding it. This is also important if you want eLyXer to be fully > independent of LyX, i.e., to work for people who don't even have LyX > installed. Looks like a good solution for users. Even for Alex the update could be made automated. > rh Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Alex Fernandez: > Hi again, > > On Sat, May 2, 2009 at 9:22 PM, Kornel Benko wrote: > > I meant something like: I (elyxer) understand lyx-formats up to 329. > > Our actual format in trunk is 354, while lyx 1.6.3 writes format 345. > > > > So it _is_ important to know, what elyxer supports. > > Seen this way it is. What I meant was: eLyXer should understand > formats up to 354. I would not like LyX to output a special format for > eLyXer since then there is no incentive to support the latest version. But for trunk and each future lyx-version it has to be this special format then. Will it eventually change? If yes, how should lyx know? > Alex. Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer
On Sun, May 3, 2009 at 12:32 AM, rgheck wrote: >> This would become even easier if LyX would install lyx2lyx as a normal >> Python package. > > It might be worth requesting this explicitly as an enhancement. Surely it > can't be that hard. Done: http://www.lyx.org/trac/ticket/5934 Alex
Re: Some poll about elyxer
Alex Fernandez wrote: Hi Guenter, On Sat, May 2, 2009 at 11:10 PM, Guenter Milde wrote: It should be mentioned that (AFAIK), lyx2lyx works (and can be installed) independent of LyX. At least I could successfully use a lyx2lyx from trunk to import "1.6" documents with 1.5.4. Hmmm, that is interesting. It certainly puts what Kornel suggested in a new light. If eLyXer could find lyx2lyx and make it work for itself... Maybe the easiest thing for you to do would just be to borrow the lyx2lyx code, and update that from trunk periodically. Then you just make it part of your executable and you don't have to worry about finding it. This is also important if you want eLyXer to be fully independent of LyX, i.e., to work for people who don't even have LyX installed. rh
Re: Some poll about elyxer
Guenter Milde wrote: This would become even easier if LyX would install lyx2lyx as a normal Python package. It might be worth requesting this explicitly as an enhancement. Surely it can't be that hard. It should be mentioned that (AFAIK), lyx2lyx works (and can be installed) independent of LyX. At least I could successfully use a lyx2lyx from trunk to import "1.6" documents with 1.5.4. Yes, lyx2lyx is utterly independent of LyX itself. So is tex2lyx, for that matter. rh
Re: Some poll about elyxer
Pavel Sanda wrote: Richard Heck wrote: Set up formats for each one. hehehe i see it will be bit hard to get some agreement here since thats complentary draft to Juergens... :) Yes, I know. But I think J"urgen meant more "why do this one special?" whereas I mean: We should do them all differently. rh
Re: Some poll about elyxer
Hi Guenter, On Sat, May 2, 2009 at 11:10 PM, Guenter Milde wrote: > It should be mentioned that (AFAIK), lyx2lyx works (and can be > installed) independent of LyX. At least I could successfully use a > lyx2lyx from trunk to import "1.6" documents with 1.5.4. Hmmm, that is interesting. It certainly puts what Kornel suggested in a new light. If eLyXer could find lyx2lyx and make it work for itself... Alex.
Re: Some poll about elyxer
On 2009-05-02, rgheck wrote: > Kornel Benko wrote: >> Am Samstag 02 Mai 2009 schrieb rgheck: >>> Jürgen Spitzmüller wrote: > That said, solving this problem is basically trivial. eLyXer need do > nothing more than call lyx2lyx on the input file with the right > arguments to get the format it wants. This would become even easier if LyX would install lyx2lyx as a normal Python package. > You don't have to integrate the programs to do this. In *nix, it's as > simple as a two-line shell script. There is no need to go via the shell to combine two Python programs. If lyx2lyx were a package in the PYTHONPATH, something like import lyx2lyx.LyX doc = lyx2lyx.LyX.File(input = args[0], dest=elyxer_format) doc.convert() should do. It should be mentioned that (AFAIK), lyx2lyx works (and can be installed) independent of LyX. At least I could successfully use a lyx2lyx from trunk to import "1.6" documents with 1.5.4. Günter
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Hi again, On Sat, May 2, 2009 at 9:22 PM, Kornel Benko wrote: > I meant something like: I (elyxer) understand lyx-formats up to 329. > Our actual format in trunk is 354, while lyx 1.6.3 writes format 345. > > So it _is_ important to know, what elyxer supports. Seen this way it is. What I meant was: eLyXer should understand formats up to 354. I would not like LyX to output a special format for eLyXer since then there is no incentive to support the latest version. Alex.
Re: Some poll about elyxer
Abdelrazak Younes wrote: >> No one raised size as an issue. Maintainability, comprehensiveness, etc, >> were the issues. > > As long as LyX doesn't depend on eLyXer I don't see any problem. We also > have scons and cmake in that situation don't we? not that we should aim at maintainig three different build systems, two different installers and next another two parallel html outputs ;) pavel
Re: Some poll about elyxer
Richard Heck wrote: > Set up formats for each one. hehehe i see it will be bit hard to get some agreement here since thats complentary draft to Juergens... :) pavel
Re: Some poll about elyxer
Pavel Sanda wrote: Richard Heck wrote: I'm not proposing we list each one separately, but find some way to detect them all and then configure things appropriately. i dont understand this proposal. we detect them all. then what? Set up formats for each one. So you'd have html1, which used hevea, html2, which used latex2html, and however many others are detected, and then each would appear on the Export menu. As I said, this could get to be too many, but maybe there could be submenus on the menu, instead, so you'd have something like: Exports-->PDF -->ps2pdf pdflatex dvipdf HTML-->hevea plastex eLyXer and so forth, for whatever options there are. Richard
Re: Some poll about elyxer
On 02/05/2009 01:30, Alex Fernandez wrote: First, this discussion (and the many threads around it) are causing unnecessary division among LyX developers. Don't worry about that. LyX developers have a pretty thick skin :-) People are suffering unnecessary pain because of this. And this because everyone is trying to do the right thing for LyX, but nobody agrees what this thing is. I think we all need to take a step back and try to find out what the best way to help users. This paragraph justifies that we grant you svn access Alex :-) Cheers, Abdel.
Re: Some poll about elyxer
On 01/05/2009 21:06, rgheck wrote: Abdelrazak Younes wrote: I vote for full inclusion for three reasons: 1) the social aspect: Alex looks like a nice and proactive guy. He _is_ a nice recrue, no doubt about that. We are not being very inviting with all this fuss about inclusion or not. How long did Vincent have to wait for commit access? Way too long IMO. You propose to give Alex commit access tomorrow? Yes, Alex is bringing a full converter, certainly enough to justify an svn access. We should just tell him to restrain to commit anything else than to elyxer in the first weeks, that's all. As you know I don't buy this purgatory period argument before getting svn access ;-) 2) the user aspect: it is so much easier for the user and the packager to not have to install this additional few kilobytes. Come on guys, this is only a tiny python script! The fact that we include it doesn't mean that we endorse it as *the* one and only html converter. The user don't need to know, the two things are separate. No one raised size as an issue. Maintainability, comprehensiveness, etc, were the issues. As long as LyX doesn't depend on eLyXer I don't see any problem. We also have scons and cmake in that situation don't we? 3) Alex will get more help with development when it is integrated. Elyxers really makes no sense without LyX, as simple as that. Kept external, Alex can decide who helps him. Nothing precludes any of us from doing so. Nothing but yet another repository to track... Anyway, nuf said. I'll have now to read the hundred mails since yesterday :-) Abdel.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Richard Heck wrote: > I'm not proposing we list each one separately, but find some way to detect > them all and then configure things appropriately. i dont understand this proposal. we detect them all. then what? pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Pavel Sanda wrote: Jürgen Spitzmüller wrote: Pavel Sanda wrote: As said, I do not understand why eLyXer should be separated from that paradigma. i tried to explain - difference in technology and target too (mainly based what can (not) be read from latex output). Yes, but I'm not convinced by this at all. tex4ht is at least as far away from hevea in this regard. The fact that eLyXer reads a lyx file does not matter at all, IMHO. The conversion chain does not matter. Who cares that tex4ht actually does DVI->HTML conversion? i dont know the look of hevea output so i dont know... maybe some other devs want to share their opinion too? Actually, my own view is that we ought to be able to offer as many options as possible. For example, why do we have three pdf formats, but only one html option? Why not have HTML (hevea), HTML (tex4ht), and so on and so forth? I guess the answer is probably: It'd crowd the menu. But esp with HTML, having as many different options as possible is probably good, since each of the choices has its own pros and cons. I'm not proposing we list each one separately, but find some way to detect them all and then configure things appropriately. Richard
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Alex Fernandez: > Hi Kornel, > > On Sat, May 2, 2009 at 4:52 PM, Kornel Benko wrote: > > Yes, we should. It is yet not possible for autoconfigure to determine > > which format elyxer supports. > > > > Maybe some elyxer-parameter, like --print-format. Alex? > > No need to. eLyXer, being in the more-or-less-unique position of > consuming LyX output, can recognize and parse different LyX formats > _at the same time_. For example when I added support for LyX 1.6 > cites: > \\begin_inset CommandInset citation > I kept 1.5 around: > \\begin_inset LatexCommand cite > so eLyXer can parse a mix of 1.5 and 1.6, for all it cares. Of course > it has to support _all_ formats to be really useful, but that is not > as hard as some devs think. And it should be even easier with a few > changes I want to implement. Any layouts not supported can be reported > and will be added. > > So the short answer is (if I understood the problem right): eLyXer > doesn't care about the format either. I meant something like: I (elyxer) understand lyx-formats up to 329. Our actual format in trunk is 354, while lyx 1.6.3 writes format 345. So it _is_ important to know, what elyxer supports. > Thanks, > > Alex. Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Hi Kornel, On Sat, May 2, 2009 at 4:52 PM, Kornel Benko wrote: > Yes, we should. It is yet not possible for autoconfigure to determine which > format elyxer supports. > > Maybe some elyxer-parameter, like --print-format. Alex? No need to. eLyXer, being in the more-or-less-unique position of consuming LyX output, can recognize and parse different LyX formats _at the same time_. For example when I added support for LyX 1.6 cites: \\begin_inset CommandInset citation I kept 1.5 around: \\begin_inset LatexCommand cite so eLyXer can parse a mix of 1.5 and 1.6, for all it cares. Of course it has to support _all_ formats to be really useful, but that is not as hard as some devs think. And it should be even easier with a few changes I want to implement. Any layouts not supported can be reported and will be added. So the short answer is (if I understood the problem right): eLyXer doesn't care about the format either. Thanks, Alex.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > >As said, I do not understand why eLyXer should be separated from that > > > paradigma. > > > > i tried to explain - difference in technology and target too (mainly based > > what can (not) be read from latex output). > > Yes, but I'm not convinced by this at all. tex4ht is at least as far away > from > hevea in this regard. The fact that eLyXer reads a lyx file does not matter > at > all, IMHO. The conversion chain does not matter. Who cares that tex4ht > actually does DVI->HTML conversion? i dont know the look of hevea output so i dont know... maybe some other devs want to share their opinion too? pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Pavel Sanda wrote: > >As said, I do not understand why eLyXer should be separated from that > > paradigma. > > i tried to explain - difference in technology and target too (mainly based > what can (not) be read from latex output). Yes, but I'm not convinced by this at all. tex4ht is at least as far away from hevea in this regard. The fact that eLyXer reads a lyx file does not matter at all, IMHO. The conversion chain does not matter. Who cares that tex4ht actually does DVI->HTML conversion? Jürgen
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Jürgen Spitzmüller wrote: > Uwe Stöhr wrote: > > Thanks for changing this. But shouldn't we now give the html format the > > name "HTML (tex4ht)" to tell the users what program they are using, like we > > do for PDF? > > It's not necessarily tex4ht. It can also be latex2html or hevea. yes, i use latex2html here. >As said, I do not understand why eLyXer should be separated from that >paradigma. i tried to explain - difference in technology and target too (mainly based what can (not) be read from latex output). of course thats more of feeling than of some clear argument, so if more devs think it should be just one of the converters (the first one/the last one btw?) let it be that way. pavel
Re: Some poll about elyxer
Am Samstag 02 Mai 2009 schrieb rgheck: > > > > Well, the other thing no-one mentioned, which does matter, is that we'd > like the tools we distribute to work not just with the formats of the > major releases but also with intermediate ones. Well, ok... > That said, solving this problem is basically trivial. eLyXer need do > nothing more than call lyx2lyx on the input file with the right > arguments to get the format it wants. You don't have to integrate the > programs to do this. In *nix, it's as simple as a two-line shell script. Either way, it is trivial. Hopefully the itch (to direct export to html) will grow :) Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Uwe Stöhr wrote: > Thanks for changing this. But shouldn't we now give the html format the > name "HTML (tex4ht)" to tell the users what program they are using, like we > do for PDF? It's not necessarily tex4ht. It can also be latex2html or hevea. As said, I do not understand why eLyXer should be separated from that paradigma. Jürgen
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Uwe Stöhr wrote: > i understand the problem. my problem is - are you really sure running > src/elyxer.py is the same as running ./elyxer? No, both are different but Alex will re-add the file extension to the latter and rename the one in src/ now. > elyxhtml is not to be seen anywhere in the menu, but as i said previously > i have no problem to call it html2. Thanks for changing this. But shouldn't we now give the html format the name "HTML (tex4ht)" to tell the users what program they are using, like we do for PDF? That's probably a good idea. rh
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
> i understand the problem. my problem is - are you really sure running > src/elyxer.py is the same as running ./elyxer? No, both are different but Alex will re-add the file extension to the latter and rename the one in src/ now. > elyxhtml is not to be seen anywhere in the menu, but as i said previously > i have no problem to call it html2. Thanks for changing this. But shouldn't we now give the html format the name "HTML (tex4ht)" to tell the users what program they are using, like we do for PDF? regards Uwe
Re: Some poll about elyxer
Kornel Benko wrote: Am Samstag 02 Mai 2009 schrieb rgheck: Jürgen Spitzmüller wrote: It's not LyX's task to deliver the correct format to eLyXer. This is eLyXers duty. +1. Now I am outnumbered. But only partly convinced :) Well, the other thing no-one mentioned, which does matter, is that we'd like the tools we distribute to work not just with the formats of the major releases but also with intermediate ones. That said, solving this problem is basically trivial. eLyXer need do nothing more than call lyx2lyx on the input file with the right arguments to get the format it wants. You don't have to integrate the programs to do this. In *nix, it's as simple as a two-line shell script. Richard
Re: Some poll about elyxer
Am Samstag 02 Mai 2009 schrieb rgheck: > Jürgen Spitzmüller wrote: > > It's not LyX's task to deliver the correct format to eLyXer. This is > > eLyXers duty. > > +1. Now I am outnumbered. But only partly convinced :) > rh Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller: > Kornel Benko wrote: > > > Still, LyX's autoconfigure should work with any version of a program, > > > if possible. > > > > Yes, we should. It is yet not possible for autoconfigure to determine > > which format elyxer supports. > > Only eLyXer knows. And it should issue lyx2lyx in order to get that > specific format. Hmmm, yes. I only wanted to be pragmatic. > Jürgen Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Kornel Benko wrote: > > Still, LyX's autoconfigure should work with any version of a program, if > > possible. > > Yes, we should. It is yet not possible for autoconfigure to determine which > format elyxer supports. Only eLyXer knows. And it should issue lyx2lyx in order to get that specific format. Jürgen
Re: Some poll about elyxer
Pavel Sanda wrote: Alex Fernandez wrote: First, this discussion (and the many threads around it) are causing unnecessary division among LyX developers. People are suffering unnecessary pain because of this. And this because everyone is trying .. If the LyX community still wants to integrate eLyXer and it causes no conflicts (i.e. everyone agrees on it) I will happily offer it again. .. I am sorry for all the conflict that I have caused, I should the friday flamming posts are not so unique and they have very long tradition on this list (no smile day) - so please dont feel scared; the painful part had noting to do with elyxer per se and you are not responsible at all for it... And vigorous discussion is a hallmark of this list. It's rare that anyone ends up really feeling offended, though of course things have gotten out of hand on those rare occasions. Certainly I'd be shocked if anyone here felt Alex had caused conflict. And it seems to me that we've come to a conclusion everyone can live with, i.e., the one Jurgen suggested. Richard
Re: Some poll about elyxer
Jürgen Spitzmüller wrote: It's not LyX's task to deliver the correct format to eLyXer. This is eLyXers duty. +1. rh
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller: > Kornel Benko wrote: > > > > Well, this is certainly the case for many other alternative programs > > > > as well. > > > > > > my feeling was that this is somewhat on the level of pdf/1/2/3 though. > > I'd rather see it on the level of latex2html/tex4ht. > > pdf1/2/3 involves specific file conversion handling and such. Which in case of elyxer will be done without too much pain. > Jürgen Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller: > Kornel Benko wrote: > > I learned today, tha elyxer supports lyx1.6. It was not soo difficult to > > change my preferences to reflect this upgrade. > > > > And we do not change the format too often for the public. > > Still, LyX's autoconfigure should work with any version of a program, if > possible. Yes, we should. It is yet not possible for autoconfigure to determine which format elyxer supports. Maybe some elyxer-parameter, like --print-format. Alex? > It's not LyX's task to deliver the correct format to eLyXer. This is > eLyXers duty. We deliver the correct format to pdflatex too. But you have a point. > Jürgen Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Kornel Benko wrote: > > > Well, this is certainly the case for many other alternative programs as > > > well. > > > > my feeling was that this is somewhat on the level of pdf/1/2/3 though. I'd rather see it on the level of latex2html/tex4ht. pdf1/2/3 involves specific file conversion handling and such. Jürgen
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Kornel Benko wrote: > I learned today, tha elyxer supports lyx1.6. It was not soo difficult to > change my preferences to reflect this upgrade. > > And we do not change the format too often for the public. Still, LyX's autoconfigure should work with any version of a program, if possible. It's not LyX's task to deliver the correct format to eLyXer. This is eLyXers duty. Jürgen
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller: > Kornel Benko wrote: > > There were no need for elyxer to be aware of lyx2lyx. I for one am using > > it this way since some weeks. > > However, this would mean that the eLyXer format needed to be frozen. I learned today, tha elyxer supports lyx1.6. It was not soo difficult to change my preferences to reflect this upgrade. And we do not change the format too often for the public. > Jürgen Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Pavel Sanda: > Jürgen Spitzmüller wrote: > > Pavel Sanda wrote: > > > it makes sense to have both export possibilities - the > > > standard via-latex-tools preserves much better the math, structure with > > > contents etc, on the other way lyxer has more attractive visual > > > appearance. so for different documents you would use different output. > > > > Well, this is certainly the case for many other alternative programs as > > well. > > my feeling was that this is somewhat on the level of pdf/1/2/3 though. +1 > pavel Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > it makes sense to have both export possibilities - the > > standard via-latex-tools preserves much better the math, structure with > > contents etc, on the other way lyxer has more attractive visual appearance. > > so for different documents you would use different output. > > Well, this is certainly the case for many other alternative programs as well. my feeling was that this is somewhat on the level of pdf/1/2/3 though. pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Pavel Sanda wrote: > it makes sense to have both export possibilities - the > standard via-latex-tools preserves much better the math, structure with > contents etc, on the other way lyxer has more attractive visual appearance. > so for different documents you would use different output. Well, this is certainly the case for many other alternative programs as well. Jürgen
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Jürgen Spitzmüller wrote:
> * checkViewer should go to checkFormatsEntries method, not
> checkConvertersEntries().
but i wanted this to be function to be called only if checkProg('eLyXer
converter'... proceed. (it shouldn't be displayed when user have no
interest in lyxer). so the position is correct.
> * the program call syntax question needs to be clarified
yes, i didn't intend to backport before new release from Alex with
the change elyxer->elyxer.py.
> * why do we need a specific elyxhtml format?
because this tool works in a different way than the other html convertors -
without the latex phase. it makes sense to have both export possibilities - the
standard via-latex-tools preserves much better the math, structure with
contents etc, on the other way lyxer has more attractive visual appearance. so
for different documents you would use different output.
> In any case, I'd like to see a patch.
i will send it.
pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Pavel Sanda wrote: > > * recognize eLyXer as a HTML converter (already done, AFAICS) > > do you agree to backport this into branch? principally yes, but the change has some flaws: * checkViewer should go to checkFormatsEntries method, not checkConvertersEntries(). * the program call syntax question needs to be clarified * why do we need a specific elyxhtml format? In any case, I'd like to see a patch. Jürgen
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Kornel Benko wrote: > There were no need for elyxer to be aware of lyx2lyx. I for one am using it > this way since some weeks. However, this would mean that the eLyXer format needed to be frozen. Jürgen
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Samstag 02 Mai 2009 schrieb Pavel Sanda: > Kornel Benko wrote: > > > The problem is that I have to give it a file extension to make Python > > > recognize it. When I do this also the problem I had with missing > > > includes disappears. > > > > You mean, calling python is not sufficient? > > it is, but the question was different - is it possible to run "elyxer" as > executable without any extension win? i think its not. We don't _need_ to run elyxer without call python directly. > > ... > > > > > "elyxhtml" implies that it is not HTML. To avoid such > > > misinterpretations, we use for PDF output pdf2, pdf3, and so on. This > > > works well and I therefore would like to have it for HTML accordingly > > > (html is tex4ht, html2 is eLyXer). > > > > May I repeat my proposal? > > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg148941.html > > how is it different from Uwe's vision? There were no need for elyxer to be aware of lyx2lyx. I for one am using it this way since some weeks. > pavel Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer
Alex Fernandez wrote: > First, this discussion (and the many threads around it) are causing > unnecessary division among LyX developers. People are suffering > unnecessary pain because of this. And this because everyone is trying .. > If the LyX community still wants to integrate eLyXer and it causes no > conflicts (i.e. everyone agrees on it) I will happily offer it again. .. > I am sorry for all the conflict that I have caused, I should the friday flamming posts are not so unique and they have very long tradition on this list (no smile day) - so please dont feel scared; the painful part had noting to do with elyxer per se and you are not responsible at all for it... after all welcome to our party :) pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Kornel Benko wrote: > > The problem is that I have to give it a file extension to make Python > > recognize it. When I do this also the problem I had with missing includes > > disappears. > > You mean, calling python is not sufficient? it is, but the question was different - is it possible to run "elyxer" as executable without any extension win? i think its not. > ... > > "elyxhtml" implies that it is not HTML. To avoid such misinterpretations, > > we use for PDF output pdf2, pdf3, and so on. This works well and I > > therefore would like to have it for HTML accordingly (html is tex4ht, html2 > > is eLyXer). > > May I repeat my proposal? > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg148941.html how is it different from Uwe's vision? pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Jürgen Spitzmüller wrote: > What we should do: > > * recognize eLyXer as a HTML converter (already done, AFAICS) do you agree to backport this into branch? pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Alex Fernandez wrote: > Good to know. I thought it was cute to remove the extension but > apparently this is causing problems. I will change this so that the > main executable file is "elyxer.py", and the main source code file is > e.g. "main.py". as i see it: 1. for smooth working we need elyxer.py in the root directory so both linux and win versions work 2. for linux version it is still good idea to have "elyxer" command - afair in .tgz archive it is possible to maintain softlinks so this would be one solution. the second one would be to have proper make install, which will produce the link... make us now, when the new release happen, so we adjust our sources. pavel
Re: Some poll about elyxer
cmira...@kde-france.org wrote: > > == Math == > > showstopper. Do you wan't really to convert a complex math document to an > HTML page ? exactly that i want. it would be nightmare to recheck all expresions or equations whether they are typeset in the same way as in pdf. pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Pavel Sanda wrote: > > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg150476.html > > "In any case, it might be a good idea to integrate it a bit more in one way > or the other" > > "in any case ..." i read as "if it is included or not" Yes, this is what I meant. Let me a bit more clear: I think eLyXer (although I have not really tried it myself) is a great initiative, LyX users already love it, although it is still quite young. Alex proved to be very responsive to all feedback and requests. Therefore, I think we should aim at making the cooperation between LyX and this tool as smooth as possible. One key requirement, though, on the eLyXer side, would be version awareness (i.e., lyx2lyx awareness). As others (and, apparently, Alex himself), I'm not really sure merging into the LyX source would be the best way. This means we would always have to take care about eLyXer for releases, and this _might_ become problematic in times when Alex does not have time for the project and when no other developers care for the code. What we should do: * recognize eLyXer as a HTML converter (already done, AFAICS) * communicate whether both in eLyXer or LyX, something could be improved to make their cooperation easier What we could do (given that Alex supports this idea): * provide a separate eLyXer branch in our SVN for its development * distribute eLyXer as a separate tool via our infrastructure (and hence make clear it is a tool we support) Jürgen
Re: Some poll about elyxer
cmira...@kde-france.org wrote:
I vote also for inclusion.
Let me take this opportunity to explain why I do not, even though Alex
seems to have decided that he'd prefer not to have elyxer included in
lyxsvn.
== C++ or Python ==
eLyXer code is easy to understand even for hobbyist programmers like me.
Hacking exporting is something that could be done by power users or
beginner developers. Embedding it in the C++ maze of LyX code would make it
easier for Abdel and the core developper team but harder for everybody
else.
This is true, to be sure. But there are things that can be done inside
LyX that cannot easily, if at all, be done from an external converter.
I've said this several times and given lots of examples. As I see it,
the question is whether we need one converter or two. If the answer is
"one", then the question is: Where can that conversion best be done? The
answer to that is then pretty clear. If the answer is "two", one that
will work on platforms where LyX works and handles the LyX format pretty
completely, and one that works on cell phones and only handles the
basics, then that's a different matter.
But look, if people want to work on elyxer, I'm not trying to stop them.
I do think duplication of effort is kind of silly, and I'm skeptical
about the need for a program that allows LyX files to be viewed on cell
phones, but to each his own. That's the beauty of open source, right?
== LyX layouts or Python ==
Having the translation pair inside the layouts looks like a nice idea but it
would, I think, limit converters to very simple one. It is easy to convert
from \emph{} to but much harder for structure like tables or
crossreferences where the logic between LyX and the target language is
different. Converting from one format to another is certainly more complex
than search and replace.
I'm not proposing to do those sorts of things inside layouts. That would
be hardcoded, just as the export of LaTeX for tables is hardcoded.
But I agree with Richard, that for custom layouts having a possibility to
add conversion information would be nice.
== Math ==
I think that perfect math translation in HTML / MathML cannnot be a
showstopper. Do you wan't really to convert a complex math document to an
HTML page ? Few browsers (basically only Firefox) can read MathML. The
client must have a good math font on his computer to render the math
symbols.
I wasn't proposing to export to MathML, myself. That would be nice to
have as an option, to be sure. My intention is to export as much as
possible to native HTML, using Unicode if necessary.
For what it's worth, I don't see any major obstacles to handling math in
elyxer. My point was that, *as it now stands*, math support is marginal.
ELyXer could also use LaTeXMathML (http://math.etsu/edu/LaTeXMathML) a
javascript macro that convert on the fly LaTeX formulas to MathML code.
MathML conversion routine can be later added step by step in ELyXer. There
is nothing in the code that prevents it.
Of course not.
== BibTeX ==
BibTeX is very hard because of the many bst files, gigantic number of
options in natbib, biblatex... Most LaTeX -> HTML converter have very
limited bibtex conversion, generally Plain and the style that the converter
author is using. The only elegant solution is to extract the formatted
reference from the pdf and translate it in HTML code.
It is not impossible to do. The new synctex framework (included with the
latest pdflatex and xelatex) spits a table that maps the lines of the pdf
file and the latex file. Using the synctex information and some intelligent
text search, you can get the result in the pdf file of \cite{Blabla} and
then convert it to html code.
Much simpler than creating in LyX code a C++ parser of bbl and aux files...
plus extra code for biblatex that does not work the same way ... plus extra
code for the ibid., op. cit. mechanisms...
Here again, my original point had to do with what elyxer DOES NOW, not
with what it might do in the future. And I myself suggested the use of
the python-bibtex module to parse the bib files. So I don't see that
this makes for any choice between the approaches, other than that we
already have a bib file parser in LyX. It'd be nice to be able to output
the same thing the chosen bst file would, but I doubt that is critical.
And I've recently committed a framework to trunk that (with a bit more
work, which I will do later) allows for user-defined formatting of
bibliography info, as it's presented in LyX, on a per-document and
per-entry-type basis. I'm not sure what more one would want.
So the sort of information you'd need is already available in LyX, or
can readily be made available. Which is a large part of the point. Why
should we program the same thing again? An answer *might* be: To have
something that runs on the iPhone. Well, if that's the goal, then OK.
But I guess one had better make sure the HTML output is the k
Re: Some poll about elyxer
Thanks to all those who voted for inclusion of eLyXer in LyX. Thanks go specially to Uwe Stöhr for his whole-hearted support of eLyXer. Let me now withdraw my offer to include eLyXer in LyX. There are many reasons for this; let me explain them the long way since I think the issue is important. First, this discussion (and the many threads around it) are causing unnecessary division among LyX developers. People are suffering unnecessary pain because of this. And this because everyone is trying to do the right thing for LyX, but nobody agrees what this thing is. I think we all need to take a step back and try to find out what the best way to help users. Second, a poll (despite the obvious good intentions behind it) is the wrong way to go about an issue like this one. As long as people have valid concerns they have to be answered; and if those concerns are invalid then they have to be explained away. But just winning 5-to-4 is no guarantee that the outcome will be positive. Third, to make eLyXer as useful as possible it _needs_ to have a separate life from LyX. Even if it has no meaning without LyX. This is because the goals of each project are different in a few crucial respects. For one, eLyXer should support most known versions of LyX documents _at the same time_. When support for LyX 1.6 was added, the now obsolete 1.5 format was kept for backwards compatibility. If eLyXer resided within LyX then that support would be ditched since lyx2lyx already keeps compatibility. But then an eLyXer user would need the whole LyX infrastructure to read a LyX document. Similarly, eLyXer can be a valuable resource for people who want to read LyX documents but do not have LyX (because they don't want, or because they cannot run it). Remember, Python runs on many more platforms than LyX; having a way to visualize documents on those platforms would make LyX more useful. I naïvely thought that eLyXer could survive integration and still keep a separate life. Code could be exchanged (as from trunk to branch, and back) and everyone's codebases and lives would get richer in the process. After Uwe's exposition I see that it is quite impossible. IMHO LyX needs a way to output HTML to maximize its usefulness. If a new way to output HTML natively emerges then it will probably have been worth it to cause this infight. Meanwhile joint distribution would fulfill our common goals nicely. I will support Uwe as much as possible to bundle eLyXer in the Windows installer, and the same for Linux distributions, which should eventually reach most users. Joint distribution might go as far as bundling the main elyxer.py file in released versions. If the LyX community still wants to integrate eLyXer and it causes no conflicts (i.e. everyone agrees on it) I will happily offer it again. But in this circumstances I think it is best if the two codebases stay separate. I am sorry for all the conflict that I have caused, I should have thought the thing over (and especially any adverse consequences) before making my offer. In my eagerness to offer something back to the community (and also to earn some recognition) I rubbed some people the wrong way. Now all I can do is apologize and try to help mend the bridges. Thanks for getting this far, Alex.
Re: Some poll about elyxer
Alex Fernandez schrieb: On Fri, May 1, 2009 at 9:30 PM, Uwe Stöhr wrote: The problem is that I have to give it a file extension to make Python recognize it. When I do this also the problem I had with missing includes disappears. Good to know. I thought it was cute to remove the extension but apparently this is causing problems. I will change this so that the main executable file is "elyxer.py", and the main source code file is e.g. "main.py". Yes, this would be better. regards Uwe
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Hi Uwe, On Fri, May 1, 2009 at 9:30 PM, Uwe Stöhr wrote: > The problem is that I have to give it a file extension to make Python > recognize it. When I do this also the problem I had with missing includes > disappears. Good to know. I thought it was cute to remove the extension but apparently this is causing problems. I will change this so that the main executable file is "elyxer.py", and the main source code file is e.g. "main.py". Let me explain a bit how it works. The code resides in a few source files distributed in packages. Since Python is often unable to find those packages, before distribution all source code is coalesced into a single file, which is then made executable. This eases distribution pains (since a single file contains everything) and at the same time allows for development in a modular fashion. Thanks, Alex.
Re: Some poll about elyxer
I vote also for inclusion.
== C++ or Python ==
eLyXer code is easy to understand even for hobbyist programmers like me.
Hacking exporting is something that could be done by power users or
beginner developers. Embedding it in the C++ maze of LyX code would make it
easier for Abdel and the core developper team but harder for everybody
else.
== LyX layouts or Python ==
Having the translation pair inside the layouts looks like a nice idea but it
would, I think, limit converters to very simple one. It is easy to convert
from \emph{} to but much harder for structure like tables or
crossreferences where the logic between LyX and the target language is
different. Converting from one format to another is certainly more complex
than search and replace.
But I agree with Richard, that for custom layouts having a possibility to
add conversion information would be nice.
== Math ==
I think that perfect math translation in HTML / MathML cannnot be a
showstopper. Do you wan't really to convert a complex math document to an
HTML page ? Few browsers (basically only Firefox) can read MathML. The
client must have a good math font on his computer to render the math
symbols.
ELyXer could also use LaTeXMathML (http://math.etsu/edu/LaTeXMathML) a
javascript macro that convert on the fly LaTeX formulas to MathML code.
MathML conversion routine can be later added step by step in ELyXer. There
is nothing in the code that prevents it.
== BibTeX ==
BibTeX is very hard because of the many bst files, gigantic number of
options in natbib, biblatex... Most LaTeX -> HTML converter have very
limited bibtex conversion, generally Plain and the style that the converter
author is using. The only elegant solution is to extract the formatted
reference from the pdf and translate it in HTML code.
It is not impossible to do. The new synctex framework (included with the
latest pdflatex and xelatex) spits a table that maps the lines of the pdf
file and the latex file. Using the synctex information and some intelligent
text search, you can get the result in the pdf file of \cite{Blabla} and
then convert it to html code.
Much simpler than creating in LyX code a C++ parser of bbl and aux files...
plus extra code for biblatex that does not work the same way ... plus extra
code for the ibid., op. cit. mechanisms...
== Maintainability ===
What would be nice is to have a testing suite for elyxer. If the LyX format
change, some tests will fail and it would be easy to correct elyxer.
If LyX goes XML, we will enter in a Golden Age where miraculous XSLT will
transform water to wine, LyX XML to ODF and we will validate all the time
all our files ;-)
Cheers,
Charles
Re: Some poll about elyxer
Am Freitag 01 Mai 2009 schrieb rgheck: > > i understand the problem. my problem is - are you really sure running > > src/elyxer.py is the same as running ./elyxer? > > > > > > I think it's quite definitely not the same. And I think, it is the same. Elyxer seems to be the collection of the other python files. Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Am Freitag 01 Mai 2009 schrieb Uwe Stöhr: > the nitpicking part for Uwe: > >> There is no binary for Windows and Mac, while the Python file works on > >> all platforms. > > > > there is no binary for linux either. just look into the directory - > > "elyxer" is normal python script and the documentation says to use this > > script. > > The problem is that I have to give it a file extension to make Python > recognize it. When I do this also the problem I had with missing includes > disappears. You mean, calling python is not sufficient? ... > "elyxhtml" implies that it is not HTML. To avoid such misinterpretations, > we use for PDF output pdf2, pdf3, and so on. This works well and I > therefore would like to have it for HTML accordingly (html is tex4ht, html2 > is eLyXer). May I repeat my proposal? http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg148941.html Kornel signature.asc Description: This is a digitally signed message part.
Re: Some poll about elyxer
Pavel Sanda wrote: Uwe Stöhr wrote: The problem is that I have to give it a file extension to make Python recognize it. When I do this also the problem I had with missing includes disappears. i understand the problem. my problem is - are you really sure running src/elyxer.py is the same as running ./elyxer? I think it's quite definitely not the same. rh
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
Uwe Stöhr wrote: > The problem is that I have to give it a file extension to make Python > recognize it. When I do this also the problem I had with missing includes > disappears. i understand the problem. my problem is - are you really sure running src/elyxer.py is the same as running ./elyxer? > "elyxhtml" implies that it is not HTML. To avoid such misinterpretations, > we use for PDF output pdf2, pdf3, and so on. This works well and I > therefore would like to have it for HTML accordingly (html is tex4ht, html2 > is eLyXer). elyxhtml is not to be seen anywhere in the menu, but as i said previously i have no problem to call it html2. > > not to mention the fairy tales about commiting access for other people; > > just today we have third developer (Georg) without commit access ;) > > I'm surprised too that Lars had not give him commit rights. Has anyone yet > reached Lars or cannot also JMarc give him an account as in the past? Lars gave accounts to all people, the problem are most probably the passwords for new accounts if they had not been sent to him in the short time window he was communicating with us. pavel
Re: Some poll about elyxer (was: Integration of eLyXer to LyX)
the nitpicking part for Uwe: >> There is no binary for Windows and Mac, while the Python file works on all >> platforms. > > there is no binary for linux either. just look into the directory - "elyxer" > is normal python script and the documentation says to use this script. The problem is that I have to give it a file extension to make Python recognize it. When I do this also the problem I had with missing includes disappears. > well, one can't have one target for different outputs and the naming of the > target is quite arbitrary. if you strive for "html2" instead of "elyxhtml" > no problem for me. i have chosen this just to mimic the way we have "wordhtml" > in configure.py now. "elyxhtml" implies that it is not HTML. To avoid such misinterpretations, we use for PDF output pdf2, pdf3, and so on. This works well and I therefore would like to have it for HTML accordingly (html is tex4ht, html2 is eLyXer). > not to mention the fairy tales about commiting access for other people; > just today we have third developer (Georg) without commit access ;) I'm surprised too that Lars had not give him commit rights. Has anyone yet reached Lars or cannot also JMarc give him an account as in the past? regards Uwe
Re: Some poll about elyxer
Abdelrazak Younes wrote: On 01/05/2009 18:24, Pavel Sanda wrote: Uwe Stöhr wrote: No it was not. What you did was detecting eLyXer but this is not necessary when it is integrated. which we haven't agreed upon anyway lets turn this into something more constructive - could the people involved write clearly their standpoint now, when i guess all the arguments and (possible) plans in the previous thread have been given ? i'm now inclined to the Richard's point of view, that we shouldn't include it by default. I vote for full inclusion for three reasons: 1) the social aspect: Alex looks like a nice and proactive guy. He _is_ a nice recrue, no doubt about that. We are not being very inviting with all this fuss about inclusion or not. How long did Vincent have to wait for commit access? You propose to give Alex commit access tomorrow? 2) the user aspect: it is so much easier for the user and the packager to not have to install this additional few kilobytes. Come on guys, this is only a tiny python script! The fact that we include it doesn't mean that we endorse it as *the* one and only html converter. The user don't need to know, the two things are separate. No one raised size as an issue. Maintainability, comprehensiveness, etc, were the issues. 3) Alex will get more help with development when it is integrated. Elyxers really makes no sense without LyX, as simple as that. Kept external, Alex can decide who helps him. Nothing precludes any of us from doing so. rh
