Robert Goldman <rpgold...@sift.info> writes: > On 6/16/11 Jun 16 -3:36 PM, Jambunathan K wrote: >> Eric Schulte <schulte.e...@gmail.com> writes: >> >>> Robert Goldman <rpgold...@sift.info> writes: >>> >>>> On 6/7/11 Jun 7 -3:01 PM, Tassilo Horn wrote: >>>>> Vinh Nguyen <vinhdi...@gmail.com> writes: >>>>> > .... >>>> >>>> I have tried the version here: >>>> https://github.com/twada/org-html5presentation.el >>>> >>>> and it does not seem to be ready for prime-time. Org-babel features >>>> don't work, and there seems to be not a clear integration with the >>>> org-export-preprocessor. See my two issues, one (not satisfactorily) >>>> closed, one open. >>>> >>>> Possibly this should be folded into contrib, so that people could >>>> cooperate on it more easily than when it lives off in a separate git >>>> repo, but it shouldn't be enabled for the unwary until it's been >>>> thoroughly exercised. >>>> >>>> Is there a "tries to use all features" org presentation somewhere that >>>> would serve as a good acid test for an export facility? It would be >>>> very handy to have that. >>>> >>> >>> This export target seems to re-implement much of the org HTML export >>> mechanics which is most likely the reason for the incomplete coverage of >>> Org's large functionality. >>> >>> Perhaps it would be possible to change this so that it works more like >>> org-s5, that is, so that it firsts exports using the existing html >>> export functionality, and then simply manipulates the resulting html. >>> >> >> I haven't looked at or tried either org-s5 or the html5 presentations. >> >> I would like to note that much of the refactoring of the html exporter >> is already done and is ready for prime time. I would very much like to >> see that my code be used for such experimentations. >> >> I will only note that the only way Free Software can thrive is by >> adopting an "embrace and extend" approach. > > Can you explain more about how we should proceed? Are you recommending: > > Your refactoring should be merged into the main branch BEFORE attempting > to re-engineer org-html5presentation? > > Or is there something else? > > Also, does your re-engineering help with the problem that I cited above? > I.e., the fact that org-export-current-backend is used BOTH to load the > export code AND to indicate to the preprocessor how to preprocess. The > problem here is that we can't make two different backends share the same > preprocessing. > > Actually, more generally, I think the problem is that the > export-preprocessor, since it doesn't have anything like methods or > higher-order functions, forces us to build into each preprocessing > function a big conditional based on the value of > org-export-current-backend, which is cumbersome. >
Admittedly I don't know what transformation are required by the html5 presentation mechanism, however I would think that an approach like that taken in org-export-as-s5 [1], in which the existing org-export-as-html is simply wrapped in a let-form which sets variable values uses hooks to post-process, should be the simplest and would leverage as much of the existing machinery as possible. Best -- Eric Footnotes: [1] https://github.com/eschulte/org-S5/blob/master/org-export-as-s5.el#L17 -- Eric Schulte http://cs.unm.edu/~eschulte/