Richard Heck wrote: > Alex, do you know C++? I'd be happy to help with this, once exams are over.
this looks like something you can't get completely right. now what i mean 'right' here - right means to get the same version of the document in pdf or html - in the sense of content not appearance... i can't imagine how you would care about various ERTs - imagine reseting some counters etc. now this is the advantage of using latex->conveters, they are prepared for tex, math is done externaly via latex itself etc. if one wants good typography, choose pdf/ps if one wants only structure and semantical part one can choose html, which was never designed for fingerpaintings. i accept that some people didn't like aesthetically the output of the current latex->html tools so i didn't comment on just next convertor to html and in a way i'm not concerned whether it supports all the lyx features - like the list you sen't previously. just a small tool for people not wanting too much of features and a little bit better whistles and bells :) when i commented thats better to use internal lyx code for output i meant that it is better then parsing .lyx file (not .tex file) - i didn't mean we should do that coding! :) if there are problems with lyx->html conversion lets help fix latex->html tools i would say on contrary. to sum it up - i think this project would spend lot of energy, the output would never be total of things you see in pdf output (in semantical sense) and if one doesn't aspire on this totality, the current solutions seems to be quite good now. also i dont think that having such proper and total html output is so much valuable for lyx - i may enter flame here - but html is very bad output format - each few years new version, each browser different interpretation, neither cleanly semantical structure like xml nor fingerpaintings like dvi, but some madhouse inbetween - thats why no need to spend long month for html development. where we are really failing is the sematical part - lyx claims to have support for docbook/sgml output, but last working manual for sgml is targeted on lyx 1.2 and the recurent questions on users list there would interest... the later manuals are doing some ugly sed-like operations on the generated outpu output to get proper xml and i suspect to get this right would be not hard for somebody who knows something about xml. because we dont have this working people tend not to support this formerly (complete?) output format in new features and we dont get feedback from users to fix them either... pavel
