From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.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 KJDHAliKhmYhRQAAe85BDQ:P1 (envelope-from ) for ; Thu, 04 Jul 2024 11:41:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id KJDHAliKhmYhRQAAe85BDQ (envelope-from ) for ; Thu, 04 Jul 2024 13:41:12 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ZRDdmR7C; 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=1720093271; 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=KFOFA191MRYWJzkw6/2unCp501pnZalhsI8knf33UYg=; b=Sl05gHHOseK4gnmb0fBrFqWthjwL+InrRmzim+oDcO5J8R02YDR6L6b4OzkuVIC0CJVC2C Y8HlAAFqKNfoR7DY9BYGKEsQpeLDTfhSb61vNqrmBN33DKLCZ6wbUFwPwCkiCjuM/QTwor 4Id+8vpvDViJjzmic64oKu1p5vPyxGgIeRnX6aPS5Lyuz00IJyNeFo9ok/4Ki1tXg03yUq gJTvXsAIClL1xEzqjYqs8PjFJXAva5/T2ZfSsXz7BYn1VHmBuMmv4ZAa04J0wyUrdZD8j+ xEQ5SIpAKqUez5y4FYLo7mapb/3W1kyoXnv1iPzWMKfcFkRFhzDf/e1QhEiFLQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ZRDdmR7C; 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=1720093272; a=rsa-sha256; cv=none; b=AawXutSpPk30CC+TSbB/wfz0oDL6eiTQhAM0qwKwqFSkCMk4y+zbWTwaK0dAXcCmhykG41 xymERMqhVTNOS/zS2CvubNYgMoHbPcDFlqxHX3b7WNc2ii2C+WxIg5H8yWzMvnVbUnOhU8 Gd9nxRKQKpKAvtfwoeRj9RF8EhrG1tRjs4AnbNlcnY+LAKH2IixKg1FW/ItY1Xv8SOxNev vc2J6EEdcBY42R/czVbmZRuvtLO38/b0QqkixPHGEs9c50YIFI5+Jlupt+FaAV8ZUxQwVq V6ONQH3NKgOFiv5L1dPH89K0vCX3oXb1FsFPQHzK0a8ILXsv03Ktxrl9E3E8NQ== 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 93D4526A58 for ; Thu, 4 Jul 2024 13:41:11 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPKoy-0003Ra-Vj; Thu, 04 Jul 2024 07:40:17 -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 1sPKow-0003RF-8Q for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 07:40:14 -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 1sPKoo-0004Eq-K4 for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 07:40:12 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8B313240104 for ; Thu, 4 Jul 2024 13:40:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720093200; bh=wxHvu3L6LG1da2d6DPcZd0lXrbhW3nqP1cZxbFlPptE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=ZRDdmR7CaKasojT6ZfBaFjKqtIe7kwWzKo6AMK/QEZztLj8sVxHklSn7SL8CXYi7m Tc1pZB+PL4sz+Ik1IEkHY1qoJxwYZu8QZ4az92mddED1CAah29Y5lLh8YF7DNpcIVd 2avZpVFKUgV2MpuHNOwa5Z2pCJEBZYm0CmfEWSg8mzw1UAkcPwtPMsuBqRlm5Xbgba 7kzlTL29UMTJatmxcH9A2sWkVw0xf1rhzkqGVH1agrkFARKZ70KgzFOHamaE6UrbqV 2FmnZ7CQE/7ciqxbDkJyq2aFECtZ7h4rK8fnKBEZ0kIgIq55rJoMPYRNhkIIay0xAK x4onWe54hkMyw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WFF7M33hLz9rxF; Thu, 4 Jul 2024 13:39:59 +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> Date: Thu, 04 Jul 2024 11:41:35 +0000 Message-ID: <87zfqxpeog.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, T_SPF_TEMPERROR=0.01 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: -8.11 X-Migadu-Queue-Id: 93D4526A58 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -8.11 X-TUID: fGRZhrhfnarl Orm Finnendahl writes: >> 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. This makes sense. Although, multipage export may imply two different things: 1. An ability to produce multiple pages from parts of the original Org file. 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). That said, even having (1) is a welcome improvement. > 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? Yes, but we also need to carefully discuss the rules how the full parse tree is separated into subtrees. Your proof of concept code hard-codes these rules. > 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. 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. 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. 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. 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. 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. 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at