From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id eDX2EEgAjGaEGwEAqHPOHw:P1 (envelope-from ) for ; Mon, 08 Jul 2024 15:05:44 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id eDX2EEgAjGaEGwEAqHPOHw (envelope-from ) for ; Mon, 08 Jul 2024 17:05:44 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=csiaCMOZ; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1720451143; 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:dkim-signature; bh=q/sKLF5QD2zIyAP3TOlIg+zVyl9xhc2b09H4VzBX87U=; b=ZeD9NRxsGUsEn5/KxEXTXWV/kwRtCTKRZRDj5qCmPiuD+TcKixjNWti7KfUDpu6A6qnVwU dE/1sj1B66h6XLxkvw9xEFPSylv8bYCfAC5ecl0pwsTKyH5yoNUUOGJpYgY9lvXzCI1qIZ qRGJG4rZG5dy7ezdAa8vbX/O9T+W3ZlUoC6MZG8iD6KGWCsjEA9FfLXNd4gc/MoXFI4JU1 Z42X1Cr9JV/OlEnhYq7OKf3vuwmjTQNaLeuoL7QtllM8L5+RW7TDYd1kz4pDW6Qcht120Q fRwlZkjfK6HIWECE9B+cC8fCmeJB4pvBt275SIrCPjFWMzhInSGq0u1biRmslg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=csiaCMOZ; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720451143; a=rsa-sha256; cv=none; b=Jvmqv3vkcnHeWV0aGFOHF4rYdORRcIzIeRCn3kv71A4H0Pi7X66RQQiUYybtUgtG9YSD/g O3kzYbkMCxS1kAl1GoUwws4Cm0TLoQ/+hLLY/Lq+lfNIrFzNosY8RVZ4KbglaiM3xU/U2W 2H57CNwIHupybEM030+4dPu35c034YQQ7lsMpSKDxWfxakY3iMFmohYjZYW+KOr8j/Egmb LzbPnwLNnTEqI2wrHeadgqiXjp9+M0cxeZ/7w7meVA+aPTn1Ys3OJH2647BfIsAmiacA3T 8U1daE7JTWt4qMNtZqyWAFpSbKnTWOnQcBZHw/jKAfNvgyAcjsVspKLQ74oCxg== 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 201BC74D83 for ; Mon, 8 Jul 2024 17:05:43 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQpux-0003U6-1F; Mon, 08 Jul 2024 11:04:39 -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 1sQpuv-0003Tw-VP for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 11:04:37 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQpuo-0001Wa-SS for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 11:04:37 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7D573240101 for ; Mon, 8 Jul 2024 17:04:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720451064; bh=PNNZdmuG7sqgeIzlsg1cVZs6vDP3CG5ThTaEzAhIjig=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=csiaCMOZiZRtlAsZW9tTBcRJXZWIIqqSMJUyzZJRcdmS76PrK8meAsPL3oXIcXXaw JbkqPG7spDbxOrSqYT5CTjlfErPj/walHK1j8Wtq7UUSMN/+qZNFlqL+GvfAGwQ/6u QMVXaCnj4tCnwXKDnWRcbtcbk4MG2kyJVin3r+gVU4IqhAUiwwvkamfUwxipy1Bahb T9QpHjCdDINeLVckbBEVnR1GGbaZ5PCYE6zuPhqQrNCIVYMAbRd2a2l1FY8NMXWQuH DCj5f67n5Q/ks4EzBkS+Yto81eGs8XyCgA3h6dFP6JCctAzff2/GmjMllz/ApS/LCR dSEjklRBh73CA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WHnTM5y6vz9rxB; Mon, 8 Jul 2024 17:04:23 +0200 (CEST) From: Ihor Radchenko To: Orm Finnendahl Cc: emacs-orgmode@gnu.org Subject: Re: multipage html output In-Reply-To: References: <875xtmd9nz.fsf@christianmoe.com> <87msmypwfw.fsf@localhost> <87zfqxpeog.fsf@localhost> <87sewp9liq.fsf@localhost> Date: Mon, 08 Jul 2024 15:05:58 +0000 Message-ID: <87y16bzzxl.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -9.62 X-Migadu-Queue-Id: 201BC74D83 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -9.62 X-TUID: pwrJiFUM89bO Orm Finnendahl writes: > 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): (Just for some context, do not take my ideas as something you must follow 100% accurately. I am largely brainstorming here. So, feel free to disagree, propose anything alternative, etc; My main focus in this discussion is that multipage export should be backend-agnostic if possible) > - 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. Yup. Not an "option" in a sense of variable, but a proper export option that can be set via (1) variable; (2) backend option plist (in other words, overridden by backends); (3) in-buffer keyword, locally. > - Am I right that you suggest that all these org-export-pages > properties can be overwritten in the header of the org file? Yes. But that may be controlled by the backends, as with any other export option. To illustrate, there is CREATOR option that ox-html re-defines like the following: ;; Original global definition in ox.el (:creator "CREATOR" nil org-export-creator-string) ;; Override inside ox.el. In this example, it uses a backend-specific ;; customization instead of `org-export-creator-string', but anything ;; at all can be overridden. (:creator "CREATOR" nil org-html-creator-string) In both cases, the :creator export option can be set in buffer via, #+CREATOR: name > - 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? Yes. Something similar to `org-export-visible-only', `org-export-body-only', etc. These customizations can be toggled interactively, from `org-export-dispatch'. A question for future is whether we want more than just "t" or "nil" toggle, but it should not be too hard to generalize if we simply start from just t/nil. 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. > - 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. 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.401251@gargle.gargle.HOWL/T/#u). > 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. I guess that backends may provide some defaults that make more sense for those backends only. But otherwise splitting the full AST before individual page export might be simply handled in ox.el. > 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). All the built-in backends already have such function. For example, (defun org-html-export-to-html (&optional async subtreep visible-only body-only ext-plist) ^^^^^^^^ If subtree export is good enough to handle multi-page export, we may not even need to do much. (Although, deriving the file names is currently hard-coded for subtrees and is not very customizable; see the link I shared above) > 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... 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 -> ...). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at