Hi Ihor, Am Montag, den 08. Juli 2024 um 15:56:48 Uhr (+0000) schrieb Ihor Radchenko: > > Or we can make `org-export-as' retain INFO channel when returning the > output. Then, we can make `org-export-to-file' make use of the INFO > channel to decide the file name. This way, there will be no need to > decide the file name before running the parsing.
Are you sure that works? org-export-as currently returns a string. It could in addition return the parse-tree in info, plus the smaller parts which need to be exported, but we should not forget, that org-export-as is an inferior function called from org-export-to-file or org-export-to-buffer. But maybe I misunderstand what you mean. Here is what is needed from my perspective: 1. parse the tree of the whole document 2. split the tree up. 3. call the export backend on each of the split parts to generate the string and save it to disk or do whatever is appropriate. For me the most natural way would be that a central function (export-according-to-org-property-list) does the parsing and then call the different backend functions to export according to their rules (the trees being converted in the central function or in backend code). If toplevel functions like org-export-to-file use org-export-as, than org-export-as should only be concerned with generating the string but not with reparsing. Alternatively we can do the conversion to a string in the central function as now with org-export-as, but there still needs to be a mechanism to generate the different files for multipage output and call the export backend on them to save them or whatever. Or what did you have in mind? > For links to external pdfs and co, we have discussed what can be done in > https://list.orgmode.org/orgmode/87a5rpoi4c.fsf@localhost/ > TL;DR: In latex, \href{file.pdf#anchor} works; In web, anchors should > also work with pdfjs. Thanks, I'll check that out. -- Orm
