Hi Ihor, thanks for your time to study the code and your very valuable input, much appreciated!
Am Donnerstag, den 04. Juli 2024 um 11:41:35 Uhr (+0000) schrieb Ihor Radchenko: > > 2. An ability to produce multiple pages from a single part of Org file. > For example, consider an Org document with images exported to > ODT. The images should be stored alongside XML content file and > referenced from there. So, export produces multiple files from the > same document/subtree. > > Your approach only addresses (1), but not (2). Sure. I'm not at all familiar with the peculiarities of other output backends, but see your point. If you can give any hints or have any ideas *how* we could find general rules for separating the subtrees, which cover foreseeable use cases, or devise a flexible mechanism for doing so, I'd be glad to help setting them up and implementing them. I definitely agree, the code should be as general as possible while providing complete backward compatibility. > 1. Most of the existing backends are written to produce a single > page. So, our design of ox.el part should be able to handle > those. What you proposed (calling the same backend on pre-split parse > tree) sounds good in this context. Ok. > 2. Some backends, as you proposed, may target multipage export from the > very beginning. So, we need to provide some way for the backend (in > org-export-define*-backend) to specify that it wants to split the > original parse tree. I imagine some kind of option with default > values configured via backend, but optionally overwritten by user > settings/in-buffer keywords. I'll look into that and maybe I can come up with something. I was hesitant to propose anything as I tried to stay as limited as possible and not get too deep into changing things. If you have suggestions, please let me know. > 3. Your suggestion to add a new export option for splitting based on > headline level is one idea. > > Another idea is to split out subtrees with :EXPORT_FILE_NAME: > property. I'm not sure I fully understand what you mean: Do you mean specifying different :EXPORT_FILE_NAME: properties throughout the same document and then export accordingly? > 4. One possible extra feature might be exporting only a part of the > original Org file to separate pages. Say, only pages with specific > tag. The whole original Org file is also exported, replacing the > split-out parts with, for example, links. This will generalize > "index" pages from ox-publish. Very nice idea! MAybe along these lines is that I thought about "Master" org files which combine different documentations by linking to them in some sort of top menu which is included on every page of all these documentations and then being able to generate a single documentation without having to recompile everything. But for now I'd prefer to first get it working and then think about such extensions (I have more ideas for different extensions and "plugins" which could be useful). It shouldn't be too hard to implement at a later point and probably also wouldn't need a complete rewrite. > 5. We need to consider the rules used to generate export file names. > Currently, we choose between :EXPORT_FILE_NAME: property, > #+EXPORT_FILE_NAME: keyword, and the original file name. > > As I see in your code, you also introduced deriving file name from > the headline title. Exactly. I wanted to make sure, the file names are sorted correctly, are unique and the title is relatable to the section it names on the directory level. I also thought about making it user-configurable, but first wanted to implement a working solution. > 6. I can see people flipping between exporting the whole document and > multipage document. We probably need some kind of easy switch in M-x > org-export-dispatch to choose how to export. Sure, that is the disadvantage of my proposal to make everything a "multipage" document. Another disadvantage is that when the user chooses to open the final document or display it in a buffer the user can't choose whether to only open/display one page or every exported page. In most circumstances it should be advisable to just open/display the first page. We can also just add a switch between single-page and multipage, with multipage always just exporting to file, but that also has disadvantages. As the code I proposed is encapsulated in the html backend and not spreading all over the place, I will now first go ahead to finalize the existing code to a fully working setup. ASFAICT adapting that to other needs shouldn't require a complete rewrite. And I might be around for a while ;-) -- Orm
