emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multipage html output


From: Orm Finnendahl
Subject: Re: multipage html output
Date: Tue, 6 Aug 2024 20:47:22 +0200

Hi Ihor,

 it was easier than I thought, although still nasty:

https://github.com/ormf/org-mode/tree/org-html-multipage

Maybe you can check whether this is along the lines of what you had in
mind.

Am Montag, den 05. August 2024 um 18:22:22 Uhr (+0000) schrieb Ihor Radchenko:
> I am also a bit surprised that you went as far as adding documentation
> to the manual. We are a bit early into the review, so things are still
> going to change. Let's focus on the code first.

Don't be, it was just an exercise, not much work and I expect there
are probably changes. I just thought to present it for commentary.

> > +    (setq tmp-info info)
> > ...
> > +    (setq global-prop org-export-filters-alist)
> 
> I noticed temporary debug statements and some (message ...) statements
> sprinkled around. They are ok for the time being, but will need to be
> removed before merging upstream.

of course. I removed most of them now.

> > +(defvar org-export-multipage-split-functions nil
> > +  "List of functions applied when multipage output has to be split.")
> 
> Please be a bit more specific about what these functions are. Here is an
> example of a complete docstring:
> 
> (defvar org-export-filter-parse-tree-functions nil
>   "List of functions applied to the parsed tree.
> Each filter is called with three arguments: the parse tree, as
> returned by `org-element-parse-buffer', the backend, as
> a symbol, and the communication channel, as a plist.  It must
> return the modified parse tree to transcode.")

done.

> Also, please mention that `org-export-multipage-split-functions' are
> called _only_ when multipage output is requested. This means that
> `org-html-multipage-split' does not need to check :multipage property.

done.

> > +(defun org-html-transcode-org-data (data content info)
> > +  "Transcode the top org-data node of the org file to export.
> > ...
> 
> > +(defun org-html-transcode-multipage (info &optional body-only)
> > +  "Central routine transcoding to multipage output called by
> > +`org-html-transcode-org-data' called from `org-export-as'.
> > ...
> 
> I see nothing specific to HTML in these two functions.  Please, factor
> them out into ox.el. I think that they can be all merged into the
> default `org-export-transcode-org-data'.

I factored out org-html-transcode-multipage to
org-export-transcode-multipage and got rid of
org-html-transcode-multipage.

> > +(defun org-html-multipage-split (data _backend info)
> > ...
> > +        (if (not (file-writable-p dir)) (error "Output dir not writable")
> > +          (let* ((encoding (or org-export-coding-system 
> > buffer-file-coding-system))
> 
> Checking output dir does not belong here.

That was a leftover, I had already fixed but forgot to delete the
condition statement, thanks.

> 
> This is awkward.  Why not modifying DATA directly? Say, you can
> transform it into (org-data (...) (org-page ...) (org-page ...) ...).

I implemented it now by making org-page elements full citizens,
adopting their contents so that you can org-export-data on them. It
was quite nasty concerning link resolution but I found a reasonable
way to solve this.

This is just a proposal to check whether this architecture is the way
to go. I got the idea that it might be feasible to integrate all page
related properties directly into the properties of each org-page
element rather than annotating info with this information. I will look
into that in the following days as it might simplify the code
somewhat, but it won't be a drastic change (just again probably a
chasing of many nasty details ;-).

--
Orm



reply via email to

[Prev in Thread] Current Thread [Next in Thread]