Hi,
this is a report of my current state with the html multipage export
backend: I finished most of the heavy lifting and am currently trying
to integrate it with the old backend into a single file.
For now I plan to use a custom menu-entry ('m') in the export dialog
rather than doing it with an option in the file. The main reason is
that I like to be able to switch between output formats easily without
having to change the document. But that's debatable. I could also
implement it with an option in the document and I'm open for opinions.
For the backend I'm planning to realize the following options
(implemented as custom variables, which can be overwritten in the
document):
- org-html-multipage-export-directory
The directory for the exported files (relative or absolute).
- org-html-multipage-head
(similar to HTML_HEAD but will be used instead of the HTML_HEAD for
custom css/js)
- org-html-multipage-front-matter
A list to specify pages in front of the headlines of the
document. Possible values are 'title, 'title-toc and 'toc. title-toc
is a combined page containing the title and the toc. Multiple
entries are possible.
- org-html-multipage-join-first-subsection
Boolean: Non-nil means that the first subsection of a section
without a body will be joined on the section page (recursively). See
my generated example pages linked below (Chapters 4, 5 and 7 for a
recursive example)
- org-html-multipage-split
How to split the document. Possible values are
'toc for generating a page for each toc entry.
'export-filename for splitting into pages along :EXPORT_FILENAME:
properties. The autogenerated filename mechanism for the other
options will be overwritten in this case.
A number for the depth to split (similar to the value for h: or
toc:) I haven't tested all options yet but will see whether/how it
works.
- org-html-multipage-open
Whether and where to open the first page of the document after
export. Possible values are 'browser 'buffer or nil. (As Ihor
mentioned this is a minor issue).
This is fairly straightforward for me to realize (it's mostly done
already). The suggestions of Ihor are excellent, but IIUC they
implement a larger and more general context, which of course is
desirable. I have to study the ideas more thoroughly to see, how
difficult/time consuming it will be to implement. It might be that it
is better to do it in two steps to keep it manageable for me. I'm
pretty sure that the current approach can be adapted to the larger
context easily so the work is not in vain.
In addition I have a question about the html output layout
structure. Here is an example of a file generated with the current
code with some preliminary layout. It might give an idea about my use
case:
https://www.selma.hfmdk-frankfurt.de/finnendahl/klangsynthesebuch/01_00_00_vorwort.html#orge24571b
Regardless of the colours, the file has a slightly different hierarchy
than the single page html template of ORGMODE and is more oriented
towards the layout of documentation nowadays with a (hideable) toc at
the side on every page rather than the texinfo oriented layout used by
the orgmode manual. If my code gets accepted/merged to org what should
be the default layout shipped with multipage output? FYI: The
visibility of the toc entries is managed by the css and the whole toc
is included on each page (and its visibility could be managed with js
as well). Should I rather go for the classic texinfo view?
And now just a short answer to Ihor's remarks.
Am Donnerstag, den 04. Juli 2024 um 16:20:29 Uhr (+0000) schrieb Ihor
Radchenko:
> While reading your code, I saw that you used some html-specific
> functions for modifications in ox.el. If you start by modifying ox.el in
> Org git repo directly, simply doing "make compile" will warn about
> instances of using functions not defined in ox.el.
> Another advantage of editing the ox.el and using Org repository is that
> you can run "make test" any time and see if you managed to break Org :)
Of course. I never intended to corrupt ox.el with html specific stuff,
that was just preliminary while getting acquainted with the
code. Currently I'm in the process of separating everything and
reducing it to the minimal requirements for change. I'll let you know
when it's done.
--
Orm
