Orm Finnendahl <orm.finnend...@selma.hfmdk-frankfurt.de> writes: >> This sounds like some kind of extension to :filter-final-output. >> I think it should also be an ok option. > > :filter-final-output functions could be used, but the name is a bit > misleading. Therefore I'd suggest to extend the > org-export-filters-alist with :export-final-output which only gets > called if non-nil. Otherwise org-export-as will return a single string > as before, so we don't break anything.
It is not very clear for me from the name how :export-final-output would differ from :filter-final-output. Maybe :finalize-export-functions? > In the multipage case we still need a hook to split the parse tree > before transcoding. The place for this should probably be in > org-export--annotate-info. I don't see any mechanism/alist function to > use so I would suggest to add an option :multipage-process-hook to > org-export-filters-alist. We should better use a new option, yes. Many existing options can be modified by users by accident, and we do not want that. > In addition the backend will set a :multipage option at the beginning > of the export, when exporting to multipage. It will be more in-line with the existing design to set :export-options. See `org-export--get-export-attributes'. > I will go ahead and implement a proposal. Let me know if something > sounds bad/unreasonable. As you see, nothing major. We can work out the details after you get a prototype to work with. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
