Re: Audio File in beamer and orgmode
Hi Luís,
I think it'd be good if you post your solution here once you got it
figured out, so other people can benefit from your time spent.
--
Orm
Am Mittwoch, den 02. Oktober 2024 um 17:07:07 Uhr (+0200) schrieb luis antunes
pena:
> Thank you, Orm. Now I got it to work in LaTex.
> Next step will be in org-mode.
> Best,
> Luís
> PS: This example works only with Adobe Acrobat,
> but not with Preview on OSX.
>
> On 02.10.24 14:43, Orm Finnendahl wrote:
> > Hi Luís,
> >
> > it doesn't work OOTB in org-mode, but you can always embed LaTex
> > verbatim in Org files using the #+LATEX: prefix.
> >
> > My recommendation: Generate a LaTex file from org beamer with some
> > blind text at a place where you need your link and then check, what
> > you have to input there in order to get working links to audio files
> > by directly rendering from the LaTeX file generated by org.
> >
> > This page might get you there:
> >
> > https://tex.stackexchange.com/questions/51632/embedding-sound-files-into-beamer-presentation-with-media9
> >
> > This part on the page:
> >
> > \includemedia[
> >addresource=igottafever.mp3,
> >flashvars={
> > source=igottafever.mp3
> > &autoPlay=true
> >}
> >
> > has to be marked up in org-mode like this to appear in the latex after
> > export:
> >
> > #+LATEX: \includemedia[
> > #+LATEX: addresource=igottafever.mp3,
> > #+LATEX: flashvars={
> > #+LATEX: source=igottafever.mp3
> > #+LATEX:&autoPlay=true
> > #+LATEX: }
> >
> > Once it works, this could also be put into an elisp function and
> > invoked on a keystroke prompting for the url and its name. I think you
> > can also use #+BEGIN_LATEX: and #+END_LATEX: to avoid repeating the
> > #+LATEX on every line.
> >
> > --
> > Orm
> >
> >
> > Am Mittwoch, den 02. Oktober 2024 um 11:50:10 Uhr (+0200) schrieb luis
> > antunes pena:
> > > Dear all,
> > >
> > > I'm working on a presentation in beamer using
> > > orgmode and couldn´t find information on how to
> > > include an audio file in orgmode to be converted
> > > to beamer and a pdf.
> > >
> > > Is there any example that you could share?
> > >
> > > Thanks in advance.
> > >
> > > Luís
>
> --
> Luís Antunes Pena
> http://luisantunespena.eu
Re: Audio File in beamer and orgmode
Hi Luís,
it doesn't work OOTB in org-mode, but you can always embed LaTex
verbatim in Org files using the #+LATEX: prefix.
My recommendation: Generate a LaTex file from org beamer with some
blind text at a place where you need your link and then check, what
you have to input there in order to get working links to audio files
by directly rendering from the LaTeX file generated by org.
This page might get you there:
https://tex.stackexchange.com/questions/51632/embedding-sound-files-into-beamer-presentation-with-media9
This part on the page:
\includemedia[
addresource=igottafever.mp3,
flashvars={
source=igottafever.mp3
&autoPlay=true
}
has to be marked up in org-mode like this to appear in the latex after
export:
#+LATEX: \includemedia[
#+LATEX: addresource=igottafever.mp3,
#+LATEX: flashvars={
#+LATEX: source=igottafever.mp3
#+LATEX:&autoPlay=true
#+LATEX: }
Once it works, this could also be put into an elisp function and
invoked on a keystroke prompting for the url and its name. I think you
can also use #+BEGIN_LATEX: and #+END_LATEX: to avoid repeating the
#+LATEX on every line.
--
Orm
Am Mittwoch, den 02. Oktober 2024 um 11:50:10 Uhr (+0200) schrieb luis
antunes pena:
> Dear all,
>
> I'm working on a presentation in beamer using
> orgmode and couldn´t find information on how to
> include an audio file in orgmode to be converted
> to beamer and a pdf.
>
> Is there any example that you could share?
>
> Thanks in advance.
>
> Luís
Re: Enhancing the HTML exporter: Create a new backend or contribute to the upstream
Am Sonntag, den 08. September 2024 um 18:42:51 Uhr (+) schrieb Ihor Radchenko: > I agree that including indexer is just a question of adding specific > javascript. > > But I think that it would be useful to provide some default toggle to > include such a tool without having to know the details of what js to > include and where. Just as a simple user option. > whatever. The js is already included in the pagefind distribution, so it is a simple #+HTML_HEAD: in the org file and the searchbar html in the preamble (or wherever). > It should probably work for single page as well. I do not see why > not. sure it works. I just question the raison d'etre, when single page search is already integrated into webbrowsers. But as always there will be people arguing that it is necessary to have a search bar with pop up results integrated into the page and of course there is nothing wrong with that. I use pagefind myself, but the site I'm working on (built with the multipage exporter BTW) currently contains more than 400 files where the browser search can't help. -- Orm
Re: Enhancing the HTML exporter: Create a new backend or contribute to the upstream
Hi, that makes no sense to me whatsoever: Post processing is already possible and built into org-export. pagefind is an external product with its own binaries, not written in elisp nor being by any means connected to emacs and compiling index files on generated HTML files is exactly that: A post process. The javascript needed and all processing scripts can easily be included in the header, so I don't see any point in this, except writing a tutorial, how to integrate pagefind into someone's HTML output with the means already available with the existing backend. And that's not even contemplating, why someone would want to throw a multipage site search indexer onto single page HTML output which doesn't work on static files opened from local disks ;-) -- Orm Am Sonntag, den 08. September 2024 um 22:55:01 Uhr (+0700) schrieb Max Nikulin: > On 08/09/2024 21:46, Max Nikulin wrote: > > On 07/09/2024 18:53, Ihor Radchenko wrote: > > > Then, pagefind can be the default (it is MIT license - GPL compatible), > > > > It might be more tricky: > > Sorry for the noise. Of course, if you are not going to include any pagefind > code into Org then it is not an issue. > > >
Re: multipage html output
Hi, don't know, I understand what you're after. Questions below. Am Samstag, den 17. August 2024 um 14:05:07 Uhr (+) schrieb Ihor Radchenko: > > Let's try to do it differently: > > 1. Introduce a new INFO plist field :multipage-pages - a list of extra >pages to be exported in addition to the main document > > 2. Transcoders can populate the list as needed, in addition to their >normal return value, which may be a link to the page, for example > 3. "pages" in the list, can be constructed using >`org-export-with-backend' or other usual means to export data. > 4. org-export-as will process all the pages from :multipage-pages in >addition to the one returned by `org-export-data'. > What does "in addition to the main document" or "to the one returned by `org-export-data'" mean? In the current multipage code, org-export-data returns a list of strings corresponding to the exported pages. In the case of html multipage output: Should :multipage-pages contain what is supposed to get exported by the multipage-html subbackend, or should the pages to be exported be left as subpages of org-data in the :parse-tree like as it is now? If they are contained in :multipage-pages, we don't need any rendering of the org-data node in the :parse-tree. Should the elements of org-data then just get deleted and we return an empty string from org-export-as in addition to the list of strings from :multipage-pages? > I believe that this approach should be the least breaking and the most > flexible. > > WDYT? Can't tell until I've fully understood your proposal. > With my idea above, we handle the actual page rendering to a custom > backend, which can reuse the normal TOC machinery, possibly encapsulated > into sub-backend parameters. We can provide any additional info that is > necessary within such sub-backend. It's not clear to me, how the encapsulation of parameters is handled, who is writing the output files, etc. Sorry, I'm just confused... > > Do note that we should not assume that each page corresponds to a > headline in ox.el. It may be anything. Sure. -- Orm
Re: multipage html output
Hi, again thanks for checking. Am Montag, den 12. August 2024 um 17:10:25 Uhr (+) schrieb Ihor Radchenko: > > :multipage-split-function should be added to the :translate-alist I > think. It should be documented what :multipage-split-function is > supposed to do in the docstring of `org-export-define-backend'. > > > I do not feel like :multipage-split-function is supposed to be export > _option_. It is more internal. That's why :translate-alist, where the > internals like templates and transcoders lie. That's how I had it before, but I reasoned it is not a transcoding function either, so I was unsure. Anyway I reversed it. > > (defun org-export-transcode-org-page (org-page _ info) > > ... > > (let* ((body-only (org-element-property :body-only org-page)) > >(info (cl-list* ;; add :tl-headline and :tl-headline-number to > info > > :tl-headline headline > > :tl-headline-number > > (alist-get > >headline > >(plist-get info :headline-numbering)) > > info)) > > May you please explain what is the purpose of constructing custom INFO > plist, what all these parameters do, and why you re-do the export again > in the transcoder discarding the CONTENTS argument provided? > The redo of the transcoding was a leftover from debugging an earlier stage. Removed now. :tl-headline and :tl-headline-numbering are needed for constructing the side toc and the footnote section on each page. They are needed in org-html-multipage-toc, called by org-html-multipage-template and in org-html-footnote-section called from org-html-multipage-inner-template. At that stage there is no information about the page, the templates are on. Let me know if you have a better idea how to provide/access that information, I found a temporary addition to info the most natural way. As it will be needed by any multipage backend which wants to determine the footnotes for a page, I think there should be a generic solution in ox.el. As :tl-headline-numbering can be determined from the tl-headline within org-html-multipage-toc, I can get rid of that if you prefer. Let me know how to proceed. > > (defun org-export-transcode-org-data (data body info) > > "Transcode DATA with BODY. Return transcoded string. > > DATA is the top `org-data' node of the parse-tree. INFO is the > > communication channel plist." > > (if (plist-get info :multipage) > > ;;; for multipage output the `org-data' node contains `org-page' > > ;;; pseudo elements as contents, so we call `org-export-data' on > > ;;; each of them and return the collected results. > > (mapcar (lambda (org-page) > > (org-export-data org-page info)) > > (org-element-contents data)) > > This is not a transcoder's job to export its contents. > Please move special handling of org-page AST nodes to `org-export-data'. done. -- Orm
Re: multipage html output
Hi, I made the changes Ihor suggested and made all docstrings compliant with checkdoc. Please check whether this is now how you imagined it. Concerning the options stored in the org-page properties rather than in info I mentioned in an earlier mail, I found out it actually doesn't really change anything substantially or clarifies/reduces the code, so I decided against it. ATM it doesn't make all that much sense to me. If we're nearing code completion, we could also start tackling the documentation. I think there should be an addition for the multipage filter in ox.el (under "Filter System") and maybe some other additions to explain the mechanism for multipage output (where?) Maybe I can also get some assessment what's needed in org-manual and what to change in order to make the doc additions proposals I made compliant with the rest of org-manual. -- Orm Am Sonntag, den 11. August 2024 um 16:44:47 Uhr (+0200) schrieb Orm Finnendahl: > Hi, > > OK, got it, I'll check and implement everything tomorrow when I'm back on my > desk... > > Am 11. August 2024 15:47:30 MESZ schrieb Ihor Radchenko : > >Orm Finnendahl writes: > > > >>> Also, as a side note, this docstring does not follow docstring > >>> conventions. Try M-x checkdoc > >> > >> I corrected it adding your suggestion explicitely. Checkdoc doesn't > >> complain about this one any more, but complains all over the place > >> with other docstrings not written by me as well, so I'm not > >> sure. Please check again. > > > >> (defvar org-export-multipage-split-functions nil > >> "List of functions applied to the parse tree. > >> The functions are applied only, when multipage output is > >> requested. They are called after the parse tree has been split > >> for multipage output. > > > >This is kind of accurate (because of the implementation details), but > >very confusing. Mostly because this docstring also serves as the > >docstring for :filter-multipage-split export option. I'd prefer to be a > >bit more explicit in the design. > > > >Maybe, instead of using the same :filter-multipage-split option both to > >perform the document splitting and to post-process it, we can introduce > >two export options: > > > >1. :multipage-split-function - the function (always one function!) to > > perform the split > > > >2. :filter-multipage - functions applied on document AST after it is > > processed by :multipage-split-function. > > > >>> I do not see `org-export-transcode-multipage' in > >>> https://github.com/ormf/org-mode/tree/org-html-multipage > >>> > >>> Did you forget to push some commits? > >> > >> No, that was a typo in my mail. It should have said: > >> > >>> I factored out org-html-transcode-multipage to > >>> org-export-transcode-org-data and got rid of > >>> org-html-transcode-multipage. > > > >I think you misunderstood what I was asking about. > >My point is that `org-html-transcode-org-page' largely duplicates what > >is already done in `org-export-transcode-org-data' - processing > >'inner-templtate and 'template. My suggestion is to move generic parts > >of `org-html-transcode-org-page' to ox.el and call it > >`org-export-transcode-org-page'. > > > >-- > >Ihor Radchenko // yantar92, > >Org mode contributor, > >Learn more about Org mode at <https://orgmode.org/>. > >Support Org development at <https://liberapay.com/org-mode>, > >or support my work at <https://liberapay.com/yantar92> > > - > Prof. Orm Finnendahl > Komposition > Hochschule für Musik und Darstellende Kunst > Eschersheimer Landstr. 29-39 > 60322 Frankfurt am Main
Re: multipage html output
Hi, OK, got it, I'll check and implement everything tomorrow when I'm back on my desk... Am 11. August 2024 15:47:30 MESZ schrieb Ihor Radchenko : >Orm Finnendahl writes: > >>> Also, as a side note, this docstring does not follow docstring >>> conventions. Try M-x checkdoc >> >> I corrected it adding your suggestion explicitely. Checkdoc doesn't >> complain about this one any more, but complains all over the place >> with other docstrings not written by me as well, so I'm not >> sure. Please check again. > >> (defvar org-export-multipage-split-functions nil >> "List of functions applied to the parse tree. >> The functions are applied only, when multipage output is >> requested. They are called after the parse tree has been split >> for multipage output. > >This is kind of accurate (because of the implementation details), but >very confusing. Mostly because this docstring also serves as the >docstring for :filter-multipage-split export option. I'd prefer to be a >bit more explicit in the design. > >Maybe, instead of using the same :filter-multipage-split option both to >perform the document splitting and to post-process it, we can introduce >two export options: > >1. :multipage-split-function - the function (always one function!) to > perform the split > >2. :filter-multipage - functions applied on document AST after it is > processed by :multipage-split-function. > >>> I do not see `org-export-transcode-multipage' in >>> https://github.com/ormf/org-mode/tree/org-html-multipage >>> >>> Did you forget to push some commits? >> >> No, that was a typo in my mail. It should have said: >> >>> I factored out org-html-transcode-multipage to >>> org-export-transcode-org-data and got rid of >>> org-html-transcode-multipage. > >I think you misunderstood what I was asking about. >My point is that `org-html-transcode-org-page' largely duplicates what >is already done in `org-export-transcode-org-data' - processing >'inner-templtate and 'template. My suggestion is to move generic parts >of `org-html-transcode-org-page' to ox.el and call it >`org-export-transcode-org-page'. > >-- >Ihor Radchenko // yantar92, >Org mode contributor, >Learn more about Org mode at <https://orgmode.org/>. >Support Org development at <https://liberapay.com/org-mode>, >or support my work at <https://liberapay.com/yantar92> - Prof. Orm Finnendahl Komposition Hochschule für Musik und Darstellende Kunst Eschersheimer Landstr. 29-39 60322 Frankfurt am Main
Re: multipage html output
Hi, Am Samstag, den 10. August 2024 um 12:32:12 Uhr (+) schrieb Ihor Radchenko: > I do not see it in > > > (defvar org-export-multipage-split-functions nil > > "List of functions applied to the parse tree after it has been > > split for multipage output. Each function 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.") > > Also, as a side note, this docstring does not follow docstring > conventions. Try M-x checkdoc I corrected it adding your suggestion explicitely. Checkdoc doesn't complain about this one any more, but complains all over the place with other docstrings not written by me as well, so I'm not sure. Please check again. > > > > I factored out org-html-transcode-multipage to > > org-export-transcode-multipage and got rid of > > org-html-transcode-multipage. > > I do not see `org-export-transcode-multipage' in > https://github.com/ormf/org-mode/tree/org-html-multipage > > Did you forget to push some commits? No, that was a typo in my mail. It should have said: > I factored out org-html-transcode-multipage to > org-export-transcode-org-data and got rid of > org-html-transcode-multipage. > > Looking forward. :-) I'll keep you posted... -- Orm
Re: multipage html output
Am Dienstag, den 06. August 2024 um 20:47:22 Uhr (+0200) schrieb Orm Finnendahl: > > I factored out org-html-transcode-multipage to > org-export-transcode-multipage and got rid of > org-html-transcode-multipage. Sorry, I meant "I factored out org-html-transcode-org-data to org-export-transcode-org-data and got rid of org-html-transcode-multipage".
Re: multipage html output
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 (+) 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
Re: multipage html output
Hi Ihor, as always much appreciated. I'll look into that and get back. It might take a bit depending on how complicated it is as I have some other things on my org list right now, but we'll get there ;-) Best, Orm Am Montag, den 05. August 2024 um 18:22:22 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > > attached are the patches for the multipage html export proposal. The > > tgz file contains all commits after branching from the main branch to > > the org-html-multipage branch (see: > > https://github.com/ormf/org-mode/tree/org-html-multipage) > > Thanks! Although creating patches is not necessary in your case - remote > git repo is good enough for me to check things. > > 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. > > > +(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. > > > +(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.") > > 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. > > > +(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'. > > > +(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. > You should probably do it in `org-html-export-to-multipage' instead. > Ideally, split function should do splitting, but not other things. > > > + ;; collect all org-pages to be exported. > > + (plist-put info :multipage-org-pages > > + (cl-loop > > + for file in section-filenames > > + for tl-headline in section-trees > > + collect > > + (list 'org-page > > +(list :output-file (format "%s/%s" dir > > file) > > + :tl-headline tl-headline > > + :tl-headline-number > > + (alist-get > > + tl-headline > > + > > stripped-section-headline-numbering)) > > +nil > > This is awkward. Why not modifying DATA directly? Say, you can > transform it into (org-data (...) (org-page ...) (org-page ...) ...). > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92>
Re: file local filter functions
Hi András, Am Sonntag, den 28. Juli 2024 um 21:56:16 Uhr (+0200) schrieb András Simonyi: > a long shot, but maybe you haven't set the variable > =org-export-allow-bind-keywords= to a non-nil value? that was it, thanks so much! I wasn't aware of that variable. -- Orm
file local filter functions
Hi, I'm trying to define a filter function local to a file for the final output filter, but it doesn't seem to work. This works: #+BEGIN_SRC emacs-lisp :exports results :results none (defun hiho (s backend info) (message "HiHo") s) (add-to-list 'org-export-filter-final-output-functions 'hiho) #+END_SRC But it destructively changes 'org-export-filter-final-output-functions Trying to define a file local filter doesn't work: #+BIND: org-export-filter-final-output-functions (hiho) #+BEGIN_SRC emacs-lisp :exports results :results none (defun hiho (s backend info) (message "HiHo") s) #+END_SRC This is developed based on the explanations in the org manual here: https://orgmode.org/manual/Advanced-Export-Configuration.html#Filters What am I doing wrong? -- Orm
Re: multipage html output
Hi, html multipage output is fully working now in the org-export compliant way sketched by Ihor. There is a small issue with org-export-as from ox.el: On my machine applying the :filter-final-output functions to the final output strings delete their :output-file Text Property. Below is a commented somewhat ugly fix just to show what was necessary to make it work. Maybe you have a better idea about how to change it. (let* ((output (or (org-export-data (plist-get info :parse-tree) info) ""))) (setq output (ensure-list output)) ;; we need to capture the :output-file properties as they ;; might get erased in the following filter stages. (let ((output-files (mapcar (lambda (o) (get-text-property 0 :output-file o)) output))) ;; Call citation export finalizer. (when (plist-get info :with-cite-processors) (setq output (mapcar (lambda (o) (org-cite-finalize-export o info)) output))) (let ((filters (plist-get info :filter-final-output))) ;; Call final-output filter and return result. (setq output (mapcar (lambda (o) (org-export-filter-apply-functions filters o info)) output))) ;; Apply org-export-info property and add back the ;; :output-file property. (setq output (cl-mapcar (lambda (o file) (org-add-props o nil :output-file file 'org-export-info info)) output output-files)) (if (length= output 1) (car output) output))) I will now review the code and test thoroughly before issuing merge requests and adding documentation but it looks good :-) -- Orm
Re: multipage html output
Hi Ihor, that's spot on what I wanted to suggest, thanks! -- Orm Am Samstag, den 27. Juli 2024 um 13:01:12 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > >> 1. You can use :filter-parse-tree in ox-html backend to replace the > >>original (org-data ...) AST with a list of ((org-page ...) > >>(org-page ...) ...) pseudo-elements and populate INFO channel > >>with auxiliary information you now compute in > >>`org-html-process-multipage' > > > > :filter-parse-tree kicks in before > > `org-export--collect-tree-properties' adds the headline-numbering, > > which needs to be present before the multipage code can do its work. > > Your concern raises a more important question on headline numbering > across individual pages. It may or may not be desirable to have > fall-through numbering of headings. I can see how some variants of > multipage export may choose to number headings either using continuous > numbering across the pages or to restart the numbering for each page > individually. > > Moreover, things like :headline-offset or citations may or may not need > to be computed across the pages. :headline-offset should probably be > limited to a single page, for example. For citations, multiple options > may be considered (think about numbered references that may either be > global across the pages or local, per-page). > > To address the above concerns, we will probably need to introduce global > :multipage setting alongside with multiple others (like settings > controlling headline numbering). Further, we will need to make sure that > the splitter runs last, after normal split functions, so that nothing > can interfere with it. > > But for now, let's do minimal required change that does not introduce too > many new things and simply modify `org-export--annotate-info' as the > following > > (setq tree (org-export-filter-apply-functions (plist-get info > :filter-parse-tree) tree info)) > (setq info (org-export--collect-tree-properties tree info)) > > (when (plist-get info :multipage) > (setq tree (org-export-filter-apply-functions (plist-get info > :multipage-split) tree info))) > > (when (plist-get info :with-cite-processors) > (org-cite-process-citations info) > (org-cite-process-bibliography info)) > > > :multipage-split and :multipage are new global export options. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> >
Re: multipage html output
Hi, I can implement everything now with your changes, but not exactly in the way you propose: Am Mittwoch, den 24. Juli 2024 um 10:20:16 Uhr (+) schrieb Ihor Radchenko: > I believe that my changes should allow you to implement multipage export > in the following way: > > 1. You can use :filter-parse-tree in ox-html backend to replace the >original (org-data ...) AST with a list of ((org-page ...) >(org-page ...) ...) pseudo-elements and populate INFO channel >with auxiliary information you now compute in >`org-html-process-multipage' :filter-parse-tree kicks in before `org-export--collect-tree-properties' adds the headline-numbering, which needs to be present before the multipage code can do its work. I can do everything in `org-html-transcode-org-data' (processing the parse-tree and transcoding to lists), but it is semantically not as clean as you propose with org-page pseudo-elements. I see 3 options: 1. I just finish it doing everything in `org-html-transcode-org-data'. 2. We change the order of `org-export--collect-tree-properties' and the call to :filter-parse-tree in ox.el, but that might be breaking other backends. 3. Add another filter function property to be called after `org-export--collect-tree-properties' has been executed (:filter-final-parse-tree?). wdyt? -- Orm
Re: multipage html output
Hi, Am Donnerstag, den 25. Juli 2024 um 10:04:21 Uhr (+) schrieb Ihor Radchenko: > > Do you know the source of the performance problem? When I last checked it was 4.5 Seconds vs 2.2 Seconds and I assume it was due to the gc kicking in, but whatever the reason I checked back and forth between using the temp-buffer and writing directly to file and the difference was consistent. > Are you sure that it is creating the buffer and is not related to > the packages you have installed? I will doublecheck once it is finished. If the difference remains I'll report back. I tweaked some settings after seeing your lecture from last year on EmacsConf and it improved considerably. -- Orm
Re: multipage html output
Hi Ihor, another thing: org-export--write-ouput inserts the output string into a temp-buffer before writing it to file. When exporting to multipage I found out that this imposes a pretty significant performance hit. That's why I write the output string directly to file in my own code. Is it sensitive to set an optional argument to circumvent the buffer insert (or circumvent it altogether)? -- Orm
Re: multipage html output
Hi Ihor, I studied your proposal and changes in ox.el. It is pretty clear now and I agree that this is the right way to do it with regards to the architecture of ox. Thanks for putting in your time. Am Mittwoch, den 24. Juli 2024 um 10:20:16 Uhr (+) schrieb Ihor Radchenko: > > 1. org-data will be transcoded using `org-export-transcode-org-data', >which can be overridden by setting org-data transcoders in the >individual backends. Just for clarification: In the html backend there would be a definition for an org-data transcoder, which checks for the multipage case and either returns a list of output strings with additional information or just calls `org-export-transcode-org-data' for the single-page case, right? I can't do it today but will try to get it done in the next days. -- Orm
Re: multipage html output
Hi Ihor, thanks a lot for the patches and explanations. Your assessment makes sense and I agree that we should stick to the current design as much as possible. I will go ahead and adapt my ox-html.el code the way you propose and use your patched ox.el for this. It shouldn't take too much effort and I will get back as soon as I have results (or questions ;-). -- Orm Am Mittwoch, den 24. Juli 2024 um 10:20:16 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > > 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. > > Currently, org-export-as does the following: > > 1. Compute global export attributes, according to the selected export backend > 2. Copy original buffer into working copy > 3. Process and parse the copy, generating AST > 4. Do the actual export > > You plugged your multipage processing into (4), but what it actually > does involves (3), (4), and also a new kind of post-processing. > I do not think that it is a good design from the point of view of ox.el. > I prefer to reuse or extend the existing mechanisms if at all possible - > this makes new features less confusing for users and backend developers. > > > - collects and adds information necessary for org-multipage to do its > > job, splitting the document into different parts, etc. and > > What you describe here is more or less what :filter-parse-tree filters > do - they can rearrange the parse tree before passing it to the > transcoders. Why not reusing it for multipage export? > > > - then calls org-export-data on the subtrees and exports each returned > > string to an individual file. > > And you simply call `org-export-transcode-page' for this, followed by > writing the returned string to file. > > The first part can fit within `org-export-as', but writing to file is > going a step beyond, duplicating what `org-export-to-file' does. > > > - It finally issues a done string and executes a browser open/visit > > file or simply exits nil. > > ... which again steps beyond `org-export-as' scope - post-processing is > currently done as a part of `org-export-to-file'/`org-export-to-buffer'. > > > > Let me propose the following changes to ox.el: > > 1. org-data will be transcoded using `org-export-transcode-org-data', >which can be overridden by setting org-data transcoders in the >individual backends. > > 2. org-export-as will understand transcoded output to be a list of >strings and will transfer INFO plist as text property in the return >values > > 3. org-export-to-file will make use of the text properties to retrieve >the file name to write. This way, export backend itself can assign >the file names where each exporter string should go. > > I believe that my changes should allow you to implement multipage export > in the following way: > > 1. You can use :filter-parse-tree in ox-html backend to replace the >original (org-data ...) AST with a list of >((org-page ...) (org-page ...) ...) pseudo-elements and populate INFO >channel with auxiliary information you now compute in > `org-html-process-multipage' > > 2. You can define org-page transcoder to render individual pages as > needed > > 3. You can assign :output-file text property to the returned org-page >strings and use org-export-to-file to generate the multipage output >on disk > > 4. You can handle opening exported files by augmenting POST-PROCESS >argument in `org-html-export-to-multipage-html' and calling >`org-export-file' instead of `org-export-as'. > > The tentative patches (against Org mode main branch) implementing my > changes are attached. > > From 540c8ef21c26df79cf48f58afb4e88130985e2f7 Mon Sep 17 00:00:00 2001 > Message-ID: > <540c8ef21c26df79cf48f58afb4e88130985e2f7.1721815865.git.yanta...@posteo.net> > From: Ihor Radchenko > Date: Wed, 24 Jul 2024 11:40:57 +0200 > Subject: [PATCH 1/3] ox: Factor out org-data transcoding into dedicated > overrideable transcoder > > * lisp/ox.el (org-export-transcode-org-data): New function serving as > the default transcoder for org-data export. > (org-export-transcoder): Use `org-export-transcode-org-data'
Re: multipage html output
Am Dienstag, den 23. Juli 2024 um 17:10:17 Uhr (+) 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
Re: multipage html output
Am Dienstag, den 23. Juli 2024 um 17:13:56 Uhr (+) schrieb Ihor Radchenko: > > What I had in mind if using backend-specific :filter-options. > If a backends needs to enable headline numbering unconditionally, when > :multipage is used, it can install :filter-options filter that will set > :section-numbers to t. > > Does it make sense? Yes, but I have to check whether this can be reverted afterwards, as in the :multipage case we still need the information of the initial setting of :section-numbers when transcoding finally happens. It's a bit late today to digest it all, but I'll look into it tomorrow and will get back to you with questions in case I don't get it. -- Orm
Re: multipage html output
Am Dienstag, den 23. Juli 2024 um 16:20:39 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > >> `org-export--collect-headline-numbering' is evaluated unconditionally, > >> regardless of num:t or num:nil settings. > > > > Are you sure? org-export--collect-headline-numbering has this in its > > body: > > > > (org-element-map data 'headline > > (lambda (headline) > > (when (and (org-export-numbered-headline-p headline options) > >(not (org-element-property :footnote-section-p headline))) > >...))) > > > > If num:nil headline numbers don't get collected, or am I missing > > something? > > You are right. > However, changing `org-export-numbered-headline-p' to use :multipage is > not the right approach to achieve what you need. > > If you think that multipage export should use a different set of > options, we need to implement it differently. Is that a semantic problem so we need to implement an option like :always-collect-headline-numbering instead of :multipage in org-export-numbered-headline-p? If on the other hand we define a replacement of org-export--collect-headline-numbering, we also have to do so for all functions up the stack, like org-export--annotate-info and org-export--collect-tree-properties. Or what did you have in mind? -- Orm
Re: multipage html output
Am Dienstag, den 23. Juli 2024 um 15:01:13 Uhr (+) schrieb Ihor Radchenko: > > Multipage export is something I want to see as a part of Org mode. > I thought that you were aiming for upstream from the very beginning. I > never opposed that. Ok, thanks. You're right, I was aiming at that from the very beginning, but it was unclear to me how integration of code is handled in org development and whether my code is considered acceptable or aligns with design guidelines.
Re: multipage html output
tAm Dienstag, den 23. Juli 2024 um 14:19:00 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > > ... I think printing > > headline numbers should get handled in the transcoding stage of the > > backend and not before. > > I am confused here. > What do you mean by "printing"? I mean creating the output string. > `org-export--collect-headline-numbering' is evaluated unconditionally, > regardless of num:t or num:nil settings. Are you sure? org-export--collect-headline-numbering has this in its body: (org-element-map data 'headline (lambda (headline) (when (and (org-export-numbered-headline-p headline options) (not (org-element-property :footnote-section-p headline))) ...))) If num:nil headline numbers don't get collected, or am I missing something? But I will doublecheck just to be sure... -- Orm
Re: multipage html output
Am Dienstag, den 23. Juli 2024 um 12:52:51 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > > Thanks also for the info regarding how to contribute. It'd be nice if > > you could gibe me a go in case you approve the proposal. > > May you please elaborate? Writing documentation and test functions doesn't make a lot of sense if the code doesn't get integrated into an org release and in addition I'd like to start working on the doc after finalizing the design and names, therefore I'm asking (I don't need the documentation for myself and wouldn't write it if it didn't get published ;-) > All you need to do is cloning/forking Org mode repository, making edits > there, and sharing the link to your branch. ok, I will do that. Best, Orm ---------- Prof. Orm Finnendahl Komposition Hochschule für Musik und Darstellende Kunst Eschersheimer Landstr. 29-39 60322 Frankfurt am Main https://www.youtube.com/watch?v=2rWha1HTfFE&list=PLiGfneJSWmNw6dTUvcTHbTkCYOOTiB_N6
Re: multipage html output
Hi, thanks for the quick response! Am Dienstag, den 23. Juli 2024 um 10:24:54 Uhr (+) schrieb Ihor Radchenko: > I will first focus on reviewing changes to ox.el. > > > ox.el > > > > - added `org-export-collect-tree-info', and > > And it is not used anywhere... What is the purpose? That was not cleaned up from a previous stage. Removed, thanks! > > > org-export-transcode-headline, extracted from `org-export-as' > > How does it have anything to do with "headline"? Maybe > `org-export-transcode-page'? changed. > > > - added :multipage case to `org-export-as', calling :process-multipage > > callback submitted in info. In the multipage case, org-export-as > > returns nil relying on :process-multipage to do the exporting, while > > in the single page case it returns the transcoded string to the > > caller from the backend. > > Does it mean that you do not want page splitting to be controlled > globally, in ox.el, as we discussed? Not for now (I mention that later in the mail when I talk about section-filenames and future generalizations, where this definitely has to be done). In the html multipage export are many peculiarities which don't apply to other backends, so ox.el wouldn't be the place for it, so we will need some callback mechanism anyway. Right now this gets accomplished with a small branch in org-export-as in order to change as little as possible. It'll be easy to change if we find a good way to get this done using a more general approach. But I'm open for suggestions, if you have an idea how to already do it now. > This looks reasonable. Maybe even as a separate patch we can merge > earlier. Sure. > > > - changed that `org-export-numbered-headline-p' always returns t for > > headlines in the multipage case to ensure headline numbering is > > collected. > > > NOTE: The single-page case will be handled like before, but it might > > be a better idea to change the behaviour and do it the same way as > > in the multipage case: Always collect the headline-numbering and > > only decide at the transcoding stage whether the headline should be > > numbered in the output. > > Why? What if one wants headlines to be not numbered? Just set num:nil in the options. As mentioned, I think printing headline numbers should get handled in the transcoding stage of the backend and not before. Multipage export behind the scenes is completely dependant on headline numbering, even if headlines aren't displayed, so the code in ox.el first proceeds, as if headline numbering is turned on and moves the check for headline numbering to the transcoding stage. I didn't change the behaviour in the single-page html situation. Although I think that it might make sense that headline-numbering in general only gets checked at the transcoding stage that would affect all backends, so I didn't change anything. Thanks also for the info regarding how to contribute. It'd be nice if you could gibe me a go in case you approve the proposal. -- Orm
Re: multipage html output
Hi, I managed to get the proposal for the multipage output done. Please review it and let me know what you think/would prefer to change. I'm pretty open about it. You can find it here: https://github.com/ormf/ox-html-multipage The code is intended to replace ox.el and ox-html.el. The repository contains a pretty exhaustive CHANGELOG.txt to show what I did. I also found a way to tackle the problem with the correct output template by integrating both approaches into one template with the option of customizing it simply with css. Here are the two layouts, the first being just the plain output with a css styling similar to the plain singlepage output, the second with the navigation elements integrated into the main-text-body: 1. Plain https://www.selma.hfmdk-frankfurt.de/finnendahl/klangsynthesebuch-plain/ 2. Inline navigation https://www.selma.hfmdk-frankfurt.de/finnendahl/klangsynthesebuch/ My code proposal shouldn't break anything in the single-page export for any backend and produce the exact same output as before with one exception: There now is an option :html-numbered-link-format which applies to numbered links to Chapters, Sections or Images. If the link doesn't have a label, in previous versions of ox-html the link label just consisted of a number. With the chenge, the link label will be replaced by a customizable string for the three cases. The default setting now is "Chapter %s", "Section %s" and "Fig. %s", which will get translated using the org-export-dictionary (I added those entries in ox.el). The customizable strings can be set to "%s" if the previous behaviour is preferred, but I consider it an enhancement and assume, the new behaviour is preferred by most users. In addition I found a minor bug regarding infojs and implemented a more general way to determine footnote numbers (which is not a bug in single-page output, but in my opinion a more concise method aligning with the way footnote numbers are created in the first place). The new multipage output will get triggered with 'C-c C-e h m'. Whether the first page opens in a buffer, browser or the output just get written to file can be controlled with the :html-multipage-open option in the file (or as a customized variable). In addition these customizable options are implemented: - :html-multipage-head-include-default-style default css style for multipage documents. - :html-multipage-join-empty-bodies / org-html-multipage-join-empty-bodies Whether to join subheadlines on the same page in case a headline has no body text (I tried to clarify that in the doc string of the defcustom). - :html-multipage-export-directory / org-html-multipage-export-direcotry The directory for the multipage output (relative or absolute). - :html-multipage-nav-format / org-multipage-nav-format Html snippets for the top navigation elements. - :html-multipage-split / org-multipage-split Where to split the document. Possible values are 'toc to split at the toc entries or a number indicating the headline level. - :html-multipage-toc-to-top / org-html-multipage-toc-to-top link destination from toc (either directly to the headline, or to the top of the page, more convenient in the standard case with the navigation on top). I did *not* implement: - Front matter options as I think the standard tools for org mode cover most cases I thought of very elegantly and it seemed somewhat clunky to me. - Page split at section-filenames. The main reason for this is that it needs a longer discussion, how this should get implemented correctly to cover all use cases. In principle it is not very complicated, especially with my better understanding of the underlying principles of ox. But if I understand Ihor's ideas correctly, it is a separate issue altogether which won't be handled properly in the html backend but rather in a general multipage backend which is backend agnostic. I'm perfectly willing to tackle this and to contribute, but currently I think it is better to make the proposed code with applied improvements available, as it is useful and pretty complete for the use case of publishing an org document to multiple html pages. If the code gets reviewed and accepted I have some questions regarding final submittal: 1. How do I provide the code? Is there a mechanism like issuing a merge-request or how is it normally done? 2. How do I add documentation to the org manual? 3. Should there be test functions for the code added and are there recommendations how to do that? I'm glad that I finally got it done. Hope you like it and please let me know what you think. -- Orm
Re: How to fully control parsing of Org mode links during export
Hi, this is how I currently do the debugging of html-export (there may be more elegant ways, but it works well for me): - Copy (defun org-export-as ...) from ox.el into a local elisp buffer of your liking (any buffer with the name .el should do). - In that function add the line (setq info-debug info) just after the comment lines (Lines 2997/2998): ;; Eventually transcode TREE. Wrap the resulting string into ;; a template. (setq info-debug info) - Evaluate the new definition of org-export-as and run the export from your org file once. Now you can access the complete parse tree with (plist-get info-debug :parse-tree) (make sure just to use a small document, otherwise the output might be pretty nasty as the parents of all elements are recursively fully contained in the parse tree). You can extract all links of your document with: (setq all-links (org-element-map (plist-get info-debug :parse-tree) 'link 'identity)) And you can check the output string of html with this: (org-html-link (nth 0 all-links) "" info-debug) You can then check what you have to do to make org-html-link output the desired string, or redefine org-html-link to do what you need and later make a derived backend from the html backend replacing the org-html-link function or simply load the new definition of org-html-link using a mechanism like #+SETUPFILE: in your header. HTH, Orm Am Sonntag, den 21. Juli 2024 um 13:19:29 Uhr (-0400) schrieb Robert Weiner: > Hi Org developers: > > I could really use some help from Org export experts. I have > been trying to tweak export link parsing to do what I want > without any success. Here is a summary of the issues and related > questions I have. > > Usinf Org version "9.8-pre": > > 1. When exporting from an Org file to html, I want this > [[Emacs#Section-One]] or [[file:Emacs::Section-One]] >to be converted into this: > Emacs#Section-One >but instead Org export produces: > Emacs#Section-One > > 2. When exporting from an Org file to html, I want this > "[[One Testing]] Three" >to be converted into this: > "One Testing Three" >but instead Org export produces: > "One Testing Three" > > 3. When exporting from an Org file and I have defined the html export >syntax for mytype: to html, I want this: > [[mytype:MyLink]] > [[Testing]] >to be converted into this: > MyLink > Testing >but instead Org export produces: > MyLink.html">mytype: href="Testing.html">Testing > > My questions are: > > 1. How can I change `org-element-link-parser' in tandem with >ox-html.el to output simple HTML links without any of the text >within double brackets bleeding outside of the HTML link? > > 2. How can I get the exporter to run in my current Emacs process and >spawn a new Emacs so that I can easily debug in-process? I think I have >turned off the async export option but it still runs async and I can't >step through the exporter functions. > > Thanks very much for any help. > > -- rsw
Re: multipage html output
Hi, while doing it, I found out it only needs one function call in org-export-as for splitting, transcoding and writing the file. Currently it's called :process-multipage, but we can change that later. I'll take your advice and use an :export-option for multipage. -- Orm Am Samstag, den 13. Juli 2024 um 10:13:56 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > >> This sounds like some kind of extension to :filter-final-output. > >> I think it should also be an ok option. > > > > :filter-final-output functions could be used, but the name is a bit > > misleading. Therefore I'd suggest to extend the > > org-export-filters-alist with :export-final-output which only gets > > called if non-nil. Otherwise org-export-as will return a single string > > as before, so we don't break anything. > > It is not very clear for me from the name how :export-final-output would > differ from :filter-final-output. Maybe :finalize-export-functions? > > > In the multipage case we still need a hook to split the parse tree > > before transcoding. The place for this should probably be in > > org-export--annotate-info. I don't see any mechanism/alist function to > > use so I would suggest to add an option :multipage-process-hook to > > org-export-filters-alist. > > We should better use a new option, yes. Many existing options can be > modified by users by accident, and we do not want that. > > > In addition the backend will set a :multipage option at the beginning > > of the export, when exporting to multipage. > > It will be more in-line with the existing design to set > :export-options. See `org-export--get-export-attributes'. > > > I will go ahead and implement a proposal. Let me know if something > > sounds bad/unreasonable. > > As you see, nothing major. We can work out the details after you get a > prototype to work with. > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92>
Re: multipage html output
Hi, Am Donnerstag, den 11. Juli 2024 um 12:35:21 Uhr (+) schrieb Ihor Radchenko: > > ok, that's what you mean. I can do this, but don't you think it'd be > > more consistent with the general layout of ox, if org-export-as uses a > > callback function to call on each generated string with the filename > > as argument and we agree on names for multipage file output which have > > to get implemented by multipage backends? > > This sounds like some kind of extension to :filter-final-output. > I think it should also be an ok option. :filter-final-output functions could be used, but the name is a bit misleading. Therefore I'd suggest to extend the org-export-filters-alist with :export-final-output which only gets called if non-nil. Otherwise org-export-as will return a single string as before, so we don't break anything. In the multipage case we still need a hook to split the parse tree before transcoding. The place for this should probably be in org-export--annotate-info. I don't see any mechanism/alist function to use so I would suggest to add an option :multipage-process-hook to org-export-filters-alist. In addition the backend will set a :multipage option at the beginning of the export, when exporting to multipage. I will go ahead and implement a proposal. Let me know if something sounds bad/unreasonable. -- Orm
Re: multipage html output
Am Dienstag, den 09. Juli 2024 um 18:08:10 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > 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. > > Sorry, but I do not understand your concern. If org-export-as returns just one string, then it will reparse the parse tree each time it needs to generate an output string. But as you say below, you rather think org-export-as returns a list of strings for the multipage case. > > 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? > > What I have in mind is that `org-export-as' will return a list of > strings + INFO. INFO will contain data about which files to use for > saving the strings. Then, the caller does the saving and whatever is > necessary. If we write to files from `org-export-as' it will be a > massive breaking change in the expected behavior. ok, that's what you mean. I can do this, but don't you think it'd be more consistent with the general layout of ox, if org-export-as uses a callback function to call on each generated string with the filename as argument nad we agree on names for multipage file output which have to get implemented by multipage backends? Whatever, both ways will do what's needed, just let me know what you prefer and I will provide a suggestion, ok? I try to find time on the weekend, otherwise I'll have time after the end of next week. -- Orm
Re: multipage html output
Am Dienstag, den 09. Juli 2024 um 17:55:51 Uhr (+) schrieb Ihor Radchenko: > > To address such situations, we may, for example, allow an alternative > "multi" version of each export keyword to act specially when multipage > export is used. Consider that there is an export option #+SAMPLEOPTION. > If the document has only "#+SAMPLEOPTION: value", exporter will use it > for both normal and multipage export. However, we may allow an > alternative #+SAMPLEOPTION[multipage]: multipage value that will be used > instead when defined. > > In addition to defining alternative variants of in-buffer settings, we > also need to provide the equivalent feature for custom variables > defining the export options. We can do it by treating the value of such > export-related variables specially - we may allow special values like > [org-export-variants :default default-value :multipage multipage-value] > and provide helper functions like > > (org-export-set-option option-name value) ; :default > (org-export-set-option option-name :multipage value) ; for multipage export > only > (org-export-set-option option-name :singlepage value) ; just for singlepage > export > > (Or can be some other consistent way to define alternatives; feel free > to brainstorm) Yes. Currently I' more concerned with the architecural layout. Everything else is a matter of taste and easily configured (and hopefully agreed upon) once the structure is done. I'm very relaxed and unopinionated about how to handle options as long as they don't involve changing the org document for each export backend. > >> > - 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. > >> > >> This sounds orthogonal to multipage export. May you please illustrate > >> what you want to achieve by introducing this option? Maybe there is an > >> existing feature that can be re-used instead of creating something new? > > > > Could be: The toc as a first page is needed, when you don't want a toc > > on the side of each html page, e.g. when using the classical info > > layout. And it might be necessary to be able to distinguish between a > > separate title page with author and the toc on the next page (or a > > combined page with title and toc or no front matter at all because the > > title appears on every page). If this is possible with already > > existing options, even better. I just think that it might be necessary > > to be able to distinguish between the needs for html output format > > vs. the needs for LaTex or single-page output without having to edit > > the document (I need that as my publishing chain is going to export > > info, html multipage, pdf output and html single-page output using the > > same org file). > > Sorry, but I still do not quite understand. May you please illustrate a > bit more with some kind of simple example? Consider a doucument like this: ** Headline 1 ** Headline 2 *** Subheadline 2.1 In the multipage export you want a front page with booktitle, author, date, etc. (maybe even an image...) and as a second page after the front page you want to have a full toc. Both pages should be reachable by the side toc but shouldn't get numbered so the toc on the side would appear like this: My Booktitle Contents 1 Headline 1 2 Headline 1 2.1 Subheadline 1 On the other hand you might always print the booktitle on every page and as the toc is always at the side you might not need titlepage and toc as seperate pages. Or you like the layout of the info mode with just navigation buttons and no side toc. In these documents, the toc is normally on the first "home" page. This would also imply a seperate html page with a toc and possibly the title on it. As there are always different preferences for this I thought to introduce a list which specifies, what king of documents should appear at the front of the document which aren't counted in the toc. All these are -in my opinion- legitimate decisions not at all unusual in publication situations so I thought I accomodate for that. Is my explanation somewhat clearer? > > >> > - 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) > >> > >> Sorry, but I cannot understand anything from there. May you explain in > >> words? > > > > Consider a case like this: > > > > * Headline 1 > > ** Headline 2 > > *** Headline 3 > > Text for Headline 3 > > > > Without the above option, Headline 1, Headline 2 and Headline 3 would > > be on separate pages with Headline 1 and Headline 2 being empty pages > > with just the Headline. The option puts
Re: multipage html output
Hi Ihor,
Am Montag, den 08. Juli 2024 um 15:56:48 Uhr (+) 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
Re: multipage html output
Am Montag, den 08. Juli 2024 um 15:29:47 Uhr (+) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > > 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). > > I am wondering about the reasoning behind not re-using > #+EXPORT_FILE_NAME: here (its directory part) and simply defaulting to > `default-directory'. > > Is there any situation when you need to export the full document > vs. multipage to different places? Actually that is what I'm currently doing (and what I need for my publishing chain): The single-page document is not in the html folder used for the multipage document. Both files happen to have the same name so it wouldn't work out, if I want to generate single-page along the multipage version, without having to change the document. > > - org-html-multipage-head > > > > (similar to HTML_HEAD but will be used instead of the HTML_HEAD for > > custom css/js) > > Again, why not directly using #+HTML_HEAD? Same as above: My multipage has a completely different css and js and I think this is unavoidable. All this is just for being able to do both exports without interfering. > > - 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. > > This sounds orthogonal to multipage export. May you please illustrate > what you want to achieve by introducing this option? Maybe there is an > existing feature that can be re-used instead of creating something new? Could be: The toc as a first page is needed, when you don't want a toc on the side of each html page, e.g. when using the classical info layout. And it might be necessary to be able to distinguish between a separate title page with author and the toc on the next page (or a combined page with title and toc or no front matter at all because the title appears on every page). If this is possible with already existing options, even better. I just think that it might be necessary to be able to distinguish between the needs for html output format vs. the needs for LaTex or single-page output without having to edit the document (I need that as my publishing chain is going to export info, html multipage, pdf output and html single-page output using the same org file). > > - 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) > > Sorry, but I cannot understand anything from there. May you explain in > words? Consider a case like this: * Headline 1 ** Headline 2 *** Headline 3 Text for Headline 3 Without the above option, Headline 1, Headline 2 and Headline 3 would be on separate pages with Headline 1 and Headline 2 being empty pages with just the Headline. The option puts all three Headlines and the Contents of Headline 3 on the same page. See here: https://www.selma.hfmdk-frankfurt.de/finnendahl/klangsynthesebuch Chapters 4, 4.8, 5, 5.4 and 6 (two Headline levels combined) and Chapter 7 (three Headline levels combined) are examples of joined headlines and the other (sub)chapters are examples, how Chapters containing body text are handled. It's mainly a matter of style but in some situations it doesn't make much sense to me to add content below a headline just to avoid an empty page in multipage html output. > > - org-html-multipage-split > > > > How to split the document. Possible values are > > > > 'toc for generating a page for each toc entry. > > May I guess that the previous option may have something do with > situation when #+TOC: keyword is in the middle of a text? No: In the online document of the link above the page splitting follows the toc (with the exception of the page joining explained above), meaning that each visible toc entry will generate one page. Be aware that this is not obvious on the online page as subfolders are folded automatically using the css (folded elements have the class "toc-hidden"). If you look at the html page source you can see that every page contains the full toc to enable other css or js based styling decisions. > Do I understand correctly that your alternative layout is simply a > question of custom #+HTML_HEADER? Or is there something more to it? In my layout the main difference is that the nav left and nav right elements are part of the page-main-body rather than part of . I'm not positive this is elegantly manageable with css, when the navigation is outside the page-main-body. -- Orm
Re: multipage html output
Hi, Am Montag, den 08. Juli 2024 um 15:05:58 Uhr (+) schrieb Ihor Radchenko: > > We might also consider adding MULTIPAGE as an additional argument to the > API function (just like BODY-ONLY, VISIBLE-ONLY, SUBTREEP that we > already use), but that's probably an implementation idea we may or may > not need to use. Currently I set the :multipage property in info, but that's a detail that can be sorted out later. > Yes, roughly like this. Ideally, we should simply modify > `org-export-as', but handling output file name may be a bit tricky - > it is somewhat awkwardly placed in the current ox.el API (see the > discussion in > https://list.orgmode.org/orgmode/25393.61240.135445.401...@gargle.gargle.howl/T/#u). Today I had a look at ox.el when upgrading my code to 9.8-pre. Unfortunately the code (and behaviour of org-element, etc.) has changed quite a bit and I had to fix many things. Especially in org-export-as the parsing of the tree is now done in the lexical context of a copy of the buffer which makes implementing a multipage backend even more awkward. IMHO the code is just the wrong way around: org-export-to-file calls org-export-as which combines the parsing with generating the output string. The multipage code has to split that part and that doesn't get easier when both parts have to be evaluated in the context of org-export-with-buffer-copy. I'd rather have that turned inside out: Instead of org-export-as being a part of org-export-to-file/buffer/etc., its functionality could be at the top-level and then call org-export-to... appropriately (either for multipage output, single-page output, buffer-output...). I will handle it by splitting org-export-as just before the org-export-with-buffer-copy, but consider it a bit ugly. > I do not think that we need to go too deep into this rabbit hole for > now. A simple toggle based on `org-export-dispatch' might be good > enough. It can be easily extended to something like multi-state switch > (t/nil vs. t -> option A -> option B -> nil -> t -> ...). There is something else: A lot of my energy in the multipage backend went into getting links and footnotes correct. Footnotes aren't a big deal, but I have no idea how to handle cross document links if different backends are present (e.g. linking from html to a pdf document and vice versa ;-) I think this requires quite a bit more thinking and maybe is unrealistic altogether, but at least the framework could be changed to be able to tackle that in the distant future... -- Orm
Re: multipage html output
Hi Ihor, I'm trying to grasp what you are proposing and have some questions to make sure I've understood (please correct me if I'm wrong): - Your idea is to add an option to the backend definition called org-export-pages which is a plist containing information about the way to export the document in case some "multipage" option is chosen in the export dialog. - Am I right that you suggest that all these org-export-pages properties can be overwritten in the header of the org file? - If that is correct I assume multipage export should then be a generic option common to different export backends (if defined) (something like "export-as-multipage") and the question is how to specify that when exporting. Should this option just be listed in the export dialog for every export backend which supports it (like in my current approach for html) and when choosing it the rules of the current definition of org-export-pages in the current context are used? - This implies that the code handling this is done in ox.el like this: The export-pages function in ox.el 1. generates the parse-tree 2. extracts the subtrees according to the rules 3. calls org-export-to-file on the backends for each of them. 4. optionally also exports the whole document, maybe stripped from its exported sections (replaced by links, etc.) If this is the way you suggest it, it doesn't sound too complicated as most of it is done already. My only concern is that in this case org-export-pages is not really backend specific and therefore the place for it semantically shouldn't be in the definition of the backend, but separate from it. The backend should just define a general function for exporting a subtree to a file for the multipage case as this might differ from the definition for single file output of the complete parse-tree (with the name of this general multipage export function being the same in all backends which support multipage output). This would also imply a mechanism to define different org-export-pages plists and select from them before exporting by calling a generic backend-agnostic org-export-to-pages function in ox.el. This is very elegant but also somewhat different from the current layout of org-export which is single-page single-backend centered. Hmm... -- Orm Am Donnerstag, den 04. Juli 2024 um 16:20:29 Uhr (+0000) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > > 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. > > I think that the easiest would be adding a new option to > `org-export-options-alist' - it is already extendable for individual > backends and allows users to tweak things via in-buffer keywords, > properties, variables, and export options. > > The most generic rule would be some kind of function that takes AST > node as input and returns whether that node should be going to a separate > file or not, and if yes, tell (1) which export backend to use to export > that subtree to a file (may as well allow exporting to different > formats, while we are at it); (2) what are the export parameters to be > used for that export, (possibly) including the file path. > > Then, in addition to the most generic (and most flexible) "rule being an > Elisp function", we can allow some simplified semantics to define rules. > > The semantics should probably give a couple of toggles to customize: > (1) which subtrees are selected for export; (2) which export backend is > used (3) how their file names are generated; (4) (optional) how they are > represented when exporting the whole original file; e.g. whether to put > links to exported files in place of their subtrees; (5) (optional) how > the original file is represented in the exported subtrees; e.g. whether > to put backlink to parent file > > The subtree selection may boil down to the usual TAGS matcher (or > function), as described in "11.3.3 Matching tags and properties" section > of the manual. This will cover the previously discussed separation based > on headline level, a tag, or a property. > > The export backend selection may be realized by allowing multiple rules > with each rule defining selection/backend/file name/ > > In terms of the value semantics in Elisp, I am thinking about something > re-using backend definition format: > > (setq org-export
Re: multipage html output
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 (+) 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
Re: Re: multipage html output
Am Sonntag, den 07. Juli 2024 um 10:38:08 Uhr (+) schrieb Ihor Radchenko: > AFAIU, the feature we are discussing here is not about typesetting, but > about producing multi-file output. exactly. -- Orm
Re: multipage html output
Hi, Am Samstag, den 06. Juli 2024 um 07:47:43 Uhr (+0200) schrieb Pedro Andres Aranda Gutierrez: > Sorry for bumping in, I've been more off than on in the last couple of > weeks... > Just a stupid question: have you considered any marker to force a page > break? > That would make this functionality portable to other exporters like LaTeX, > where > you can force a page break with \clearpage or \cleardoublepage. although this is of course possible, currently I'm not planning to implement it. Regarding html export I see some problems with that idea: 1. It would either open a new can of worms if this page would be added to the toc with all sorts of ensuing problems like naming, etc. and getting out of sync with the Latex document's toc. or 2. Those additinal pages don't get added to the toc and are only reachable by navigation elements, which I consider suboptimal (and you'd still have to name them). In any case, currently I'm facing many problems concerning the glorious hairy details and am glad if I can sort them out in a way that they are general enough to be added to ox. Adding additional engines to handle page breaks the way you envision should then be feasible without reinventing the wheel. -- Orm
Re: multipage html output
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 (+) 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
Re: multipage html output
Hi, Am Mittwoch, den 03. Juli 2024 um 11:05:39 Uhr (+) schrieb Ihor Radchenko: > > Not really. ox-publish is more about exporting multiple input > .org/non-.org files into outputs. > > I'd rather see this kind of feature being a part of ox.el - an option to > export one .org to many smaller files. Currently, we only have an option > to export one .org (or part of it) to a single string/file. (And then, > ox-odt has to try various kludges to make things work as expected with > .odt, which consist of multiple files under the hood). that is/was my intention: Basically there was only a very small change to ox.el necessary to make it work (it's mentioned in the comment on top of ox-multipage-html in my github repository): Currently `org-export-as' combines parsing the org document into a global parse tree with all additional options applied and serializing that into the final output target format. My code simply splits the code sections of these tasks into two separate functions, which are called by org-export-as, `org-export--collect-tree-info' and `org-export--transcode-headline'. The advantage of this approach is that it is fully compatible with the prior code, but gives the necessary flexibility to the backend export code to split up the global parse tree before serializing. The multipage html backend (ox-html-multipage.el) takes care of generating the global parse tree with org-export--headline, divides that tree into the subtrees of the individual pages, then calls the serializing function for each of the subtrees and writes the results to file. Is that along the lines of what you meant? In the meantime I thought about the proposed backend. Maybe it's a good idea to integrate the single page *and* the multipage backend into one backend altogether: The Backend *always* produces multipage output, but you can define the level at which the pages are split with an #+OPTION: in the org file. Setting the default level to 0 if the option is not set will generate the exact same output as the old backend without breaking anything for anybody. I'm quite sure it'll work and as I said it's mainly done and wouldn't require a lot of work. What do you think? -- Orm
multipage html output
Hi, after my clunky publishing chain from org to gitbook with multipage page output broke down recently I finally decided to tackle adding an export backend for multipage html output to org-export. It is done now and mainly working. The backend uses all the funcionality of the ox html exporter, only slightly modifying the code in places where it is necessary for multipage output. In addition I tried to make it as general, as possible to enable adding other multipage backends (like for md output) easily. Before sharing it I thought it might be a good idea to think about integrating it properly/officially into org. I would be willing to provide the code, docs, patches, etc. There are a couple of decisions to make (should it be integrated as an option into the html output backend or should it be a separate backend altogether? What options concerning footnotes, toc, etc. should be provided? etc...) and this mail is basically asking about how to proceed. My questions: - Is there widespread interest to fully integrate it into org mode? - If so, whom should I contact, or is it expected that I just go ahead and supply merge requests? I'm a bit hesitant putting in the extra work of fully integrating it without approval by the maintainers to go ahead. In case someone wants to take a peek at the current state of the code you can check out my github repository here: https://github.com/ormf/ox-html-multipage Be aware and warned that the code is in constant flux, not finalized and there still are some open questions for me what would be the best way to integrate the code into the old export engine, like whether adding optional args to the transcoding functions or using properties in the info channel, etc... Once it is finalized, the current single page html export will work exactly as before (it already does, but while checking it out I am modifying the html templates for the multipage navigation, toc, etc.) Hope to hear from you, especially if the maintainers are reading this. -- Orm
Re: Help with my first elisp
Am Mittwoch, den 25. Mai 2022 um 10:24:01 Uhr (+0200) schrieb to...@tuxteam.de: > > Just to avoid confusion: Emacs Lisp does distinguish case. Traditional > Lisp doesn't. I know you know, but people could misunderstand the above. Yes, that was a bit imprecise ;-) Best, Orm ---------- Prof. Orm Finnendahl Komposition Hochschule für Musik und Darstellende Kunst Eschersheimer Landstr. 29-39 60322 Frankfurt am Main https://www.youtube.com/watch?v=2rWha1HTfFE&list=PLiGfneJSWmNw6dTUvcTHbTkCYOOTiB_N6 signature.asc Description: PGP signature
Re: Help with my first elisp
Hi, Am Dienstag, den 24. Mai 2022 um 19:30:40 Uhr (+0200) schrieb Kepa Diez: > (defun focusJump () > (interactive) > (if (equal posicion 1) > (focusPointInter) > (if (equal posicion 2) > (focusPointEnd) > (if (equal posicion 3) > (focusPointStart) maybe you want to cleanup a bit: (defun focusJump (posicion) (interactive "nPosicion: ") (case posicion (1 (focusPointInter)) (2 (focusPointEnd)) (3 (focusPointStart BTW: As lisp doesn't distinguish case, it is common practice in lisp to seperate words in symbols with dashes like 'focus-jump, 'focus-pont-inter, 'focus-point-start, etc. -- Orm
Re: org-capture config broken
Hi, Am Mittwoch, den 25. August 2021 um 18:16:15 Uhr (+0200) schrieb Maxim Nikulin: > > Unfortunately you did not specify version of Org you are currently using. Sorry, it's 9.4.4. > This the old style of Org protocol URI. See > https://orgmode.org/manual/The-capture-protocol.html for an example > of modern variant (it has typos fixed in master branch, some "?" > should be "&"). I am unsure concerning order of parameters in > old-style URLs. Thanks, that helped! In my version the following (which I had tried before following the org manual page you mention) throws an error, as it seems to expect an ampersand after the template name: $ emacsclient org-protocol:/capture?template=m?url=URL&title=TITLE&body=BODY Waiting for Emacs... *ERROR*: No capture template referred to by "m?url" keys This works: emacsclient org-protocol:/capture?template=m&url=URL&title=TITLE&body=BODY Thanks for the hint! If this example is still in the master branch maybe that should get fixed (or the code if it should work with a question mark). Best, Orm
org-capture config broken
Hi,
I use a custom script (dating back to a post from 2013) to capture my
mutt Emails using org-capture. It worked flawlessly but stopped
working some time ago (I don't exactly know, when, probably last
year).
I assume the code has changed and doesn't accept the syntax of the
org-protocol line any more.
I'm calling emacsclient with the following command:
emacsclient
org-protocol:/capture:/m/mutt:ysyuf6skfsbwt...@example.com/mail/%20%20Subject%3A%20test%0A%20%20%20%20From%3A%20Unknown%20%3Cdummy%40example.com%3E
It fails printing "*ERROR*: Wrong type argument: arrayp, nil" in the terminal
and posts
"Greedy org protocol handler. Killing client"
in the minibuffer.
The emacsclient commmand above is generated with a perl script using
uri_escape for everything after /mail/. The single slashes in the
protocol line of the emacsclient command seem strange, but I couldn't
find any hint in the internet how the syntax is supposed to be for a
certain org-capture-template.
Maybe someone can help to debug it? Below is my init.el configuration.
Best,
Orm
(setq org-capture-templates
(quote
(("m"
"Mail"
entry
(file+headline "~/work/gtd.org" "Incoming")
"* %^{Title}\n Source: %u, %:link\n %i"
:empty-lines 1)
;; ... more templates here ...
)))
;; ensure that emacsclient will show just the note to be edited when invoked
;; from Mutt, and that it will shut down emacsclient once finished;
;; fallback to legacy behavior when not invoked via org-protocol.
(add-hook 'org-capture-mode-hook 'delete-other-windows)
(setq my-org-protocol-flag nil)
(defadvice org-capture-finalize (after delete-frame-at-end activate)
"Delete frame at remember finalization"
(progn (if my-org-protocol-flag (delete-frame))
(setq my-org-protocol-flag nil)))
(defadvice org-capture-kill (after delete-frame-at-end activate)
"Delete frame at remember abort"
(progn (if my-org-protocol-flag (delete-frame))
(setq my-org-protocol-flag nil)))
(defadvice org-protocol-capture (before set-org-protocol-flag activate)
(setq my-org-protocol-flag t))
Re: custom time format extension
Hi,
for the record, here's the code if anyone ever comes across this:
(defun same-day-p (timestamp)
"check if start and end of timestamp are on the same day."
(equal
(mapcar (lambda (prop) (or (org-element-property prop timestamp) 0))
'(:day-start :month-start :year-start))
(mapcar (lambda (prop) (or (org-element-property prop timestamp) 0))
'(:day-end :month-end :year-end
(defun org-timestamp-translate (timestamp &optional boundary)
"Translate TIMESTAMP object to custom format.
Format string is defined in `org-time-stamp-custom-formats',
which see.
When optional argument BOUNDARY is non-nil, it is either the
symbol `start' or `end'. In this case, only translate the
starting or ending part of TIMESTAMP if it is a date or time
range. Otherwise, translate both parts.
Return timestamp as-is if `org-display-custom-times' is nil or if
it has a `diary' type."
(let ((type (org-element-property :type timestamp)))
(if (or (not org-display-custom-times) (eq type 'diary))
(org-element-interpret-data timestamp)
(let ((same-day (same-day-p timestamp))
(fmt (funcall (if (org-timestamp-has-time-p timestamp) #'cdr #'car)
org-time-stamp-custom-formats)))
(if (and (not boundary) (memq type '(active-range inactive-range)))
(concat (org-timestamp-format timestamp (if (consp fmt)
(if same-day (cadr fmt)
(car fmt))
fmt))
"--"
(org-timestamp-format timestamp (if (consp fmt)
(if same-day (caddr
fmt) (car fmt))
fmt)
t))
(org-timestamp-format timestamp fmt (eq boundary 'end)))
As mentioned before it should be fully backwards compatible.
--
Orm
Am Mittwoch, den 29. Juli 2020 um 22:16:34 Uhr (+0200) schrieb Orm Finnendahl:
> Hi,
>
> when exporting timestamps it always bothered me that timestamps with
> start and end time on the same day got exported with a full date for
> the start and end times separated by a dash.
>
> After thinking about this for some time I implemented a method today,
> which combines the advantage of being utmost flexible while
> maintaining full backwards compatibility.
>
> This is how it works: The cdr of org-time-stamp-custom-formats
> normally contains a format string for formatting timestamps with
> start/end time. When supplying a list of three strings instead of the
> single format string to the cdr of org-time-stamp-custom-formats, the
> first, second and third elements of that list are interpreted as
> follows:
>
> The first element is the full format in case start and end of the
> timestamp are not on the same day. The second element of the list is
> the format string for the start time of the timestamp. The third
> element of the list is a format string for the end time of the
> timestamp. (BTW: Supplying a list as second element of a dotted list
> is equivalent to supplying a list with four strings to
> org-time-stamp-custom-formats)
>
> Below the mail is a short example for german date strings.
>
> In case somebody is interested, I can provide the code off list. If
> any of the maintainers is reading on this list and thinks it should
> get revised and maybe adopted for orgmode, please let me know how to
> issue pull requests for the code. I tried to be minimally invasive ;-)
>
> --
> Orm
>
> ---
> Example:
>
> (org-time-stamp-custom-formats '("%a %d.%m.%Y" . ("%a %d.%m.%Y %H:%M Uhr"
> "%a %d.%m.%Y %H:%M"
> "%H:%M Uhr")))
>
> Formatting
>
> <2020-11-21 Sa> -> Sa 21.11.2020
>
> <2020-11-21 Sa 10:00-18:00> -> Sa 21.11.2020 10:00--18:00 Uhr
>
>
> <2020-11-21 Sa 10:00>--<2020-11-22 So 18:00> -> Sa 21.11.2020 10:00 Uhr--So
> 22.11.2020 18:00 Uhr
>
custom time format extension
Hi,
when exporting timestamps it always bothered me that timestamps with
start and end time on the same day got exported with a full date for
the start and end times separated by a dash.
After thinking about this for some time I implemented a method today,
which combines the advantage of being utmost flexible while
maintaining full backwards compatibility.
This is how it works: The cdr of org-time-stamp-custom-formats
normally contains a format string for formatting timestamps with
start/end time. When supplying a list of three strings instead of the
single format string to the cdr of org-time-stamp-custom-formats, the
first, second and third elements of that list are interpreted as
follows:
The first element is the full format in case start and end of the
timestamp are not on the same day. The second element of the list is
the format string for the start time of the timestamp. The third
element of the list is a format string for the end time of the
timestamp. (BTW: Supplying a list as second element of a dotted list
is equivalent to supplying a list with four strings to
org-time-stamp-custom-formats)
Below the mail is a short example for german date strings.
In case somebody is interested, I can provide the code off list. If
any of the maintainers is reading on this list and thinks it should
get revised and maybe adopted for orgmode, please let me know how to
issue pull requests for the code. I tried to be minimally invasive ;-)
--
Orm
---
Example:
(org-time-stamp-custom-formats '("%a %d.%m.%Y" . ("%a %d.%m.%Y %H:%M Uhr"
"%a %d.%m.%Y %H:%M"
"%H:%M Uhr")))
Formatting
<2020-11-21 Sa> -> Sa 21.11.2020
<2020-11-21 Sa 10:00-18:00> -> Sa 21.11.2020 10:00--18:00 Uhr
<2020-11-21 Sa 10:00>--<2020-11-22 So 18:00> -> Sa 21.11.2020 10:00 Uhr--So
22.11.2020 18:00 Uhr
[O] Special Characters in verbatim
Hi, I can't get verbatim to work for me with special characters: I want to display a hashmark followed by a single quote in verbatim. I publish to texinfo and from there to html (using makeinfo/texi2any). I tried this: =#'= which renders as is without removing the equality characters. If I don't use any special characters it works well, displaying the text between the equality chars with monospaced font in the html document. I searched the web for quite some time now but none of the suggested methods (escaping, using character entities, etc) work for me. Can someone help? -- Orm
[O] Math equations in html export
Hi, I can't seem to get Math equations exported correctly to html from an org file. Can someone provide me with a full example? I set #+OPTIONS: tex:t on top of the org file and tried these things, but they all render literally: $X^2$ $$X^2$$ \(x^2\) \[x^2\] I know the former two are not recommended, but I tried them nevertheless. I could imagine I have to set some options/variables, but I don't know which. Can someone help? -- Orm
Re: [O] footnotes position in html export
Hi Nicolas, thanks a lot, that sounds quite feasible and your suggestions will probably save me a lot of time! I just started writing the book and first need some more content but will look into coding it while it's growing. I'll post back to the list when I have results in case someone is interested and has a use for it. -- Orm Am Sonntag, den 08. November 2015 um 16:11:03 Uhr (+0100) schrieb Nicolas Goaziou: > Hello, > > Orm Finnendahl writes: > > > ok, thanks. I'll look into it. Maybe it's not too hard to > > implement. > > It shouldn't. Basically, you need to: > > 1. Add an optional argument to `org-html-footnote-section' specifying > the scope of footnotes, skip > `org-export-collect-footnote-definitions' altogether and use > `org-element-map' to find "first footnotes references" (see > `org-export-footnote-first-reference-p') in the scope. > > Then with `org-export-get-footnote-definition', you can build the > footnote section. > > 2. Call `org-html-footnote-section' from `org-html-section', with the > parent headline, if any, or the current section otherwise as the > current scope. > > 3. Create a new variable to toggle behaviour of footnotes. > > HTH, > > Regards, > > -- > Nicolas Goaziou
Re: [O] footnotes position in html export
Am Sonntag, den 08. November 2015 um 12:10:59 Uhr (+0100) schrieb Rasmus: > > I don't think we maintain an org-mode.js. Are you talking about Mooz's > org-js project? Or ox-html.el? sorry, I meant "org-info.js" > > I think this is not possible. See org-html-inner-template. > ok, thanks. I'll look into it. Maybe it's not too hard to implement. The org manual has footnotes on every page if it is exported into different documents. Is there any information somewhere about how the org manual html pages were generated? I couldn't find the sources of the manual. Are they available somewhere? > Greetings from Nordend, I'm also in Nordend, but that's a part of Frankfurt, Germany ;-) Orm
[O] footnotes position in html export
Hi, when exporting an org-file to html using org-mode.js, the footnotes appear at the end of the document. I'd rather have the footnotes at the end of each section. As far as I understand, this can be achieved by distributung the different sections to different .org documents and including those from a master document. Unfortunately in my document are many sections which are rather short and I'd prefer to keep them in a single document. Does anybody know of a way to achieve this? I couldn't find anything related to that on the web. -- Orm
