From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.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 UKhwN7xwhma39wAAqHPOHw:P1 (envelope-from ) for ; Thu, 04 Jul 2024 09:51:57 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id UKhwN7xwhma39wAAqHPOHw (envelope-from ) for ; Thu, 04 Jul 2024 11:51:57 +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=1720086716; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=4UxaTR5jwudRN0s0CAXzsKCMHvd3jJpZTAufLo1+6uE=; b=hD161udNpgqk8SvBRUMz/ykuYseDMmxThc7SuXtQL+ZhSuXjgwTge8trH18nEnmCMi+wlz qpA9jQl9aHgVCQm8hxle4J305VeFs6/+gKywb+GI50NowMusLxGNBRdB/C4uJo0g+ARyGT zlTYgJBOJ2DdLqQx4h3wolcOD6LlgQp0ap4WV8PcpuZChbP5KCcHt3HwPpn+6UxDSggyKs 3iH9LbgusN8dvv/nH2OmGOrEkVvBHnPvZ8rxsYaaKpnLgLLzim6CQLc3ZyvJb5lExMppup +SiHp2wqD0MSiWp4VFB/uupAZi2BtZmTAzafxcN16Ot+/5wdQPoIlS+vyIbF6Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720086716; a=rsa-sha256; cv=none; b=uEJ1WvrwogYK7G3FPrSyuJ8dLCavFNVd5VcKLZ5E3SXMXxAzjZGoDK9QbsYvQ2QIphsMTf 24QySXw0YHex6oTIMofTwabqsMBG0o4H2oCJZnGN5HvFZkJr4m3TQXRmJgT1TLFs3MaJw0 d96cSUq4wSiuiA4NxPFLb1ygAFGMqgaJATiP1uMXRwIsvSZJKVbAB5i18iBYVW+NfWHD2N pZYyGJZeKELvUCd7tOH9Mt3il5I4LFW/xVcfjpXp6HdwVapBnbqUK29E7ziWbB0JuLWG0s hu8IRkDfCfpg900kkp1rI7t1xZiB2xw9OieZ/yLc0rGe3oZU2me/2o1gDDefUQ== 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 ABFF977E7F for ; Thu, 04 Jul 2024 11:51:56 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPJ78-0002Ma-Be; Thu, 04 Jul 2024 05:50:54 -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 1sPJ75-0002MP-Tb for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 05:50:51 -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 1sPJ73-0005W5-TI for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 05:50:51 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id 690EAF62356; Thu, 4 Jul 2024 11:50:45 +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 2BF50F60917 for ; Thu, 4 Jul 2024 11:50:43 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id 7DB04396055C; Thu, 04 Jul 2024 11:50:42 +0200 (CEST) Date: Thu, 4 Jul 2024 11:50:42 +0200 From: Orm Finnendahl To: emacs-orgmode@gnu.org Subject: Re: multipage html output Message-ID: Mail-Followup-To: emacs-orgmode@gnu.org References: <875xtmd9nz.fsf@christianmoe.com> <87msmypwfw.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87msmypwfw.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: ABFF977E7F X-Migadu-Scanner: mx11.migadu.com X-TUID: gZMuSo0l+UXv Hi, Am Mittwoch, den 03. Juli 2024 um 11:05:39 Uhr (+0000) 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