On Tue, Mar 4, 2014 at 12:47 PM, Georg Baum <[email protected]> wrote: > stefano franchi wrote: > >> That may be an option, but, as I mentioned, tex4ht project is very >> complex. I don't think it's a chance that the current maintainers, who >> are both Tex gurus with a deep knowledge of the structures tex4ht >> manipulates, have not released a new version after Eitan Guirari's >> passing in 2009. > > You are probably right, but another possible reason is that they simply have > plenty of other work to do.
True. >> In short, this may be the only way to go for a full exporter, but it >> is a steep climb. > > I admit that I did not look into tex4ht in detail, so I trust your judgement > here. You shouldn't because I haven't looked at it in detail either... I have been discussing with Prannoy how to systematically investigate tex4ht from our own standpoint, so I may know more in the near future. > >> I agree with you here, even though, for the reasons discussed above, >> this point applies to the round-trip converter only. >> I think the XHTML approach gives more guarantees. And the LyX server >> may be an alternative. But reparsing the output of a process we >> control directly seems the wrong way to go. > > What do you mean with the last sentence? I am afraid I don't understand. At > least I did not want to suggest to parse some output generated by LyX. Sorry for the confusion. I was just trying to repeat your point, which I agree with: It makes little sense for LyX to parse its output (the .lyx file) when it has access to the process and data structures that generated it in the first place. Better? At any rate, we agree. I guess we can call this "The LyXHTML approach" to avoid further misunderstandings. Stefano -- __________________________________________________ Stefano Franchi Associate Research Professor Department of Hispanic Studies Ph: +1 (979) 845-2125 Texas A&M University Fax: +1 (979) 845-6421 College Station, Texas, USA [email protected] http://stefano.cleinias.org
