Re: multipage html output

[Orm Finnendahl <orm.finnendahl@selma.hfmdk-frankfurt.de>]

Am Dienstag, den 23. Juli 2024 um 17:10:17 Uhr (+0000) schrieb Ihor Radchenko:
> > 2. If a transcoder for org-data is defined, call that and return nil
> >    from org-export-date.
> >
> >    Otherwise return the transcoded string.
> 
> > 3. In case a string is returned, process it as it is done in
> >    org-export-transcode-page (only that the output string will be
> >    supplied in place of the headline and we will find a better name for
> >    org-export-transcode-page as it is called *after* the transcoding.
> 
> No.
> 
> If a transcoder for org-data is defined, call it and return whatever it
> returns. Otherwise, call `org-export-transcode-page' (adjusted to follow
> transcoder arguments).

Sorry, this is still quite obscure to me: Why should a transcoder for
org-data return anything in the multipage case and who should handle
the return value(s)? The transcoder could return a list of strings
which can get returned by org-export-as and then handled in the
function which called org-export-as. If that's what you mean I can
implement it, although I'm admittedly not really convinced, especially
as there are hairy details to solve, when we really want to use
org-export-data to generate multiple return values:

- what should 'results in org-export-data be when calling the
  transcoding function for multipage? A list of strings returned by
  the transcoding of the individual pages? Shall each string be
  memoized?  How? How to deal with assigning a file-name to each
  string, should we rather return a (filename . transcoded-string)
  alist?

To recapitulate: In my code, org-export-as calls process-multipage in
the backend. This function:

- collects and adds information necessary for org-multipage to do its
  job, splitting the document into different parts, etc. and

- then calls org-export-data on the subtrees and exports each returned
  string to an individual file.

- It finally issues a done string and executes a browser open/visit
  file or simply exits nil.

For me this is rather clean and it seems unnecessary to go through all
the hassle of dealing with a multipage transcoder within
org-export-data. Anyway, I will try to follow your recommendation once
I fully understand what you're up to, although I fear this will open a
can of worms...

> 
> > 1. org-export-data has to be modified to catch the case of
> >    org-export-transcoder being called on org-data in the
> >    multipage-case (after ;; Element/Object with contents.). This seems
> >    a bit complicated as there is memoization going on in
> >    :exported-data of info further down in org-export-data which
> >    probably should get circumvented in the multipage case (e.g. by
> >    checking the value of results).
> 
> I do not fully understand the problem you are describing here, but hope
> that my clarification above resolved it.
>

Unfortunately not :-( Sorry that I can't really make sense of your
explanations. Somehow we seem to think from quite different
perspectives and it is really hard for me to get your point (although
it is also fascinating and I'm not willing to give up ;-)

> > 2. The code has to define/provide a transcoding function in the
> >    multipage case but should *not* provide such a function in the
> >    single page case, which means (in the multipage case) to modify the
> >    alist of the backend on-the-fly before calling org-export-as.
> 
> I propose to allow custom org-data transcoder for single page case as well.
> If there is no need to have custom transcoder for single page, the
> custom transcoder can check :multipage property and fall back to
> calling `org-export-transcode-page' if it is nil.

ok, that much is clear.

--
Orm