From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id IFqGEwb8imZ9AgAA62LTzQ:P1 (envelope-from ) for ; Sun, 07 Jul 2024 20:35:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id IFqGEwb8imZ9AgAA62LTzQ (envelope-from ) for ; Sun, 07 Jul 2024 22:35:18 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=hfmdk-frankfurt.de (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1720380898; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=h0HqVJ6mm5zq7lEy0A7gRbqnuMHkePtiiTcwR+O1puk=; b=k18fbzwMaq5SYIJ/om38++u5jSAa+LGT7A2QLASBXtAwLnsyEE8tfhZCbq/8OVOSK4DmwZ oqYQXFr8LkwXk15ZaNEyVi4eKWdxvtV9hsrSSraXf88zfDCBv/ujy9398XzXXmuvjgf32f k3ptaYhXNMFEHi2QaNSncjVm3+YIwYvaaDfQe9ZFCBrC0yhDIOXO8KUgGRuHmo3JGQ4eAB MjRs1A1Rhsttk4cg1etV550jIICWGSDpzSih9+DmF+1Bx8DFfvmHbpjQ6rCB63wJXzNCOB tRyEfxfnzLp2pgZtK9SNb6097cqHZypylha3kXBLdzASB9l9Z35NeGaugWoKhw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720380898; a=rsa-sha256; cv=none; b=qLn0ELtM4NKWLwvjoAZTexWJtBBfqorfvRPMJ5ICIuLpfE2krVpN5/GuAZWvpZBbIyXdyd YOseackDI0HnC0eSIStTTj76yeHDWZ1KQnm6MmAcWi4XXGcD4h8yzogNQx1i9XdNhlGwPj 90nMFNhq0tvVq8e6XK1I6FRqFmRPyq6+HGZhBUSJsNZa6XKAuvGeIqh3qH1ZoxwCuTKQlb B80eO09NlSR9MGtvRDxZxhYGVXYurKHxAMF+SBqYe5peKgk6A4JsPi+O9MAJXVG8d+Nvlj Pk7viWciNUmZrVMaVjNiZb8g/j5+i28bGWnNeKm+eKrQ8Pg57kLU68N3MaBfCw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=hfmdk-frankfurt.de (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C481E786F5 for ; Sun, 07 Jul 2024 21:34:58 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQXeC-0002MD-Dc; Sun, 07 Jul 2024 15:34:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQXe8-0002K3-Ng for emacs-orgmode@gnu.org; Sun, 07 Jul 2024 15:34:04 -0400 Received: from www.selma.hfmdk-frankfurt.de ([46.4.92.145] helo=mail.selma.hfmdk-frankfurt.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQXe6-0001cm-H1 for emacs-orgmode@gnu.org; Sun, 07 Jul 2024 15:34:04 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id A99EBF61916; Sun, 7 Jul 2024 21:33:59 +0200 (CEST) Received: from selma.hfmdk-frankfurt.de (ip-037-201-128-004.um10.pools.vodafone-ip.de [37.201.128.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by mail.selma.hfmdk-frankfurt.de (Postfix) with ESMTPSA id 8791FF61916; Sun, 7 Jul 2024 21:33:57 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id 192BB3960515; Sun, 07 Jul 2024 21:33:57 +0200 (CEST) Date: Sun, 7 Jul 2024 21:33:57 +0200 From: Orm Finnendahl To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: multipage html output Message-ID: Mail-Followup-To: Ihor Radchenko , emacs-orgmode@gnu.org References: <875xtmd9nz.fsf@christianmoe.com> <87msmypwfw.fsf@localhost> <87zfqxpeog.fsf@localhost> <87sewp9liq.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87sewp9liq.fsf@localhost> X-Disclaimer: Why are you listening to me? X-Operating-System: GNU/Linux Organization: Hochschule =?utf-8?B?ZsO8?= =?utf-8?Q?r?= Musik und Darstellende Kunst Frankfurt, Frankfurt, Germany Received-SPF: pass client-ip=46.4.92.145; envelope-from=orm.finnendahl@selma.hfmdk-frankfurt.de; helo=mail.selma.hfmdk-frankfurt.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -2.79 X-Spam-Score: -2.79 X-Migadu-Queue-Id: C481E786F5 X-Migadu-Scanner: mx11.migadu.com X-TUID: qp34trH8iejP Hi, this is a report of my current state with the html multipage export backend: I finished most of the heavy lifting and am currently trying to integrate it with the old backend into a single file. For now I plan to use a custom menu-entry ('m') in the export dialog rather than doing it with an option in the file. The main reason is that I like to be able to switch between output formats easily without having to change the document. But that's debatable. I could also implement it with an option in the document and I'm open for opinions. For the backend I'm planning to realize the following options (implemented as custom variables, which can be overwritten in the document): - org-html-multipage-export-directory The directory for the exported files (relative or absolute). - org-html-multipage-head (similar to HTML_HEAD but will be used instead of the HTML_HEAD for custom css/js) - org-html-multipage-front-matter A list to specify pages in front of the headlines of the document. Possible values are 'title, 'title-toc and 'toc. title-toc is a combined page containing the title and the toc. Multiple entries are possible. - org-html-multipage-join-first-subsection Boolean: Non-nil means that the first subsection of a section without a body will be joined on the section page (recursively). See my generated example pages linked below (Chapters 4, 5 and 7 for a recursive example) - org-html-multipage-split How to split the document. Possible values are 'toc for generating a page for each toc entry. 'export-filename for splitting into pages along :EXPORT_FILENAME: properties. The autogenerated filename mechanism for the other options will be overwritten in this case. A number for the depth to split (similar to the value for h: or toc:) I haven't tested all options yet but will see whether/how it works. - org-html-multipage-open Whether and where to open the first page of the document after export. Possible values are 'browser 'buffer or nil. (As Ihor mentioned this is a minor issue). This is fairly straightforward for me to realize (it's mostly done already). The suggestions of Ihor are excellent, but IIUC they implement a larger and more general context, which of course is desirable. I have to study the ideas more thoroughly to see, how difficult/time consuming it will be to implement. It might be that it is better to do it in two steps to keep it manageable for me. I'm pretty sure that the current approach can be adapted to the larger context easily so the work is not in vain. In addition I have a question about the html output layout structure. Here is an example of a file generated with the current code with some preliminary layout. It might give an idea about my use case: https://www.selma.hfmdk-frankfurt.de/finnendahl/klangsynthesebuch/01_00_00_vorwort.html#orge24571b Regardless of the colours, the file has a slightly different hierarchy than the single page html template of ORGMODE and is more oriented towards the layout of documentation nowadays with a (hideable) toc at the side on every page rather than the texinfo oriented layout used by the orgmode manual. If my code gets accepted/merged to org what should be the default layout shipped with multipage output? FYI: The visibility of the toc entries is managed by the css and the whole toc is included on each page (and its visibility could be managed with js as well). Should I rather go for the classic texinfo view? And now just a short answer to Ihor's remarks. Am Donnerstag, den 04. Juli 2024 um 16:20:29 Uhr (+0000) schrieb Ihor Radchenko: > While reading your code, I saw that you used some html-specific > functions for modifications in ox.el. If you start by modifying ox.el in > Org git repo directly, simply doing "make compile" will warn about > instances of using functions not defined in ox.el. > Another advantage of editing the ox.el and using Org repository is that > you can run "make test" any time and see if you managed to break Org :) Of course. I never intended to corrupt ox.el with html specific stuff, that was just preliminary while getting acquainted with the code. Currently I'm in the process of separating everything and reducing it to the minimal requirements for change. I'll let you know when it's done. -- Orm