From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.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 MBBnA+kIjGbjAwEAe85BDQ:P1 (envelope-from ) for ; Mon, 08 Jul 2024 15:42:33 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id MBBnA+kIjGbjAwEAe85BDQ (envelope-from ) for ; Mon, 08 Jul 2024 17:42:33 +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=1720453352; 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=C7RziNws0bSprN8PWcmVKDvOenlf/fLVYhQox9tgBQs=; b=C3IcuctNj1LxE7QCFcRhxGVV+B4eqQDhSoYrRDw5NuO6ifNakY45F94qLDKwh2vi+KTHU9 FPsWfl4cy3Z/KxqqJcJS4maK9bKd3voWL2ZgBKYTmMGwMPbSwtdu0nMVfgTj5MwOu3YnJC +AO5FQ4RNfoAxQmIGxbso4wzcTe2HLwAlaeNWYCC0q1+x5IsQmpSjKo3ZKB44GvW5UzdNy mcNM92Gjj43s8nOrcj78Zfinu7AC51hA8kqukB4n+sL9vFbvF3DbYVhbMrxmuf3mN+HdZD V6W21Jj/tfjQ8ySc3xMFWZ9HOvOC8cRPqoVvfeUlQci3BK5rY2SIRbkIqPVA1A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720453352; a=rsa-sha256; cv=none; b=U7R9JsJvDElzldyl9dxmh6yNA67wLAeH3Ha0hTpTbAYOb5CXSKGcZwz4rUbLk2rKEylg40 eW3aVmbnK+LHqBOL5MS7X4tdjy7JVsYnHgwW4hz8yyr7rHzt8uq0LskdwevxFQaeZRwp52 cqFyGLrmkhR4wKKpoRr4WxUr7SRNJtwznC/putzMFB0PIHNfIbYreMfLwmYm4FkuDKE9Cz R7oC/zb+GPxEkEZlHqmVG2pPQcg2GETUoRxI3Rs4JEcQbskJah5zpCxL02DUjCVYaMpQwP EVBy59oOgJsu0WLnMto3+6x8VKs6WRkajgTST8KbS+pBjbQBxvFQFxbvjAZt3g== 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 BACADAD65 for ; Mon, 08 Jul 2024 17:42:32 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQqUR-0007Gt-5G; Mon, 08 Jul 2024 11:41:19 -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 1sQqUP-0007Em-Dn for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 11:41:17 -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 1sQqUN-0002N8-2w for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 11:41:17 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id A1904F61D28; Mon, 8 Jul 2024 17:41:11 +0200 (CEST) Received: from selma.hfmdk-frankfurt.de (unknown [212.201.35.182]) (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 8467FF61C18 for ; Mon, 8 Jul 2024 17:41:09 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id 386863960515; Mon, 08 Jul 2024 17:41:09 +0200 (CEST) Date: Mon, 8 Jul 2024 17:41:09 +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> <87zfqxpeog.fsf@localhost> <87sewp9liq.fsf@localhost> <87y16bzzxl.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87y16bzzxl.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: BACADAD65 X-Migadu-Scanner: mx11.migadu.com X-TUID: Dh+O98/5BvH3 Hi, Am Montag, den 08. Juli 2024 um 15:05:58 Uhr (+0000) 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.401251@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