From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id yHX2JeCkhmb0GAEAe85BDQ:P1 (envelope-from ) for ; Thu, 04 Jul 2024 13:34:24 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id yHX2JeCkhmb0GAEAe85BDQ (envelope-from ) for ; Thu, 04 Jul 2024 15:34:24 +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=1720100064; 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=SigiFnJ2EYpTJ1Enpiz4aWGvqAogqJHdJj3Vu0tmU2w=; b=sJrehaTm35rCmuHbBC/WlEERQpdfM4d/KUfqUKuLsU999rNQfGt6o0FbfGqqucLlYwikLj xqOIebeW0qdaNy/9L/ysdvD4OQuKdzMC/H0J8hQMoNkTXu7WPUPjK6WnnOhDJinlh4/7Qi Xj4ZI7VAbIYg8MeH8zrsJrwXEOiGlW2nCkFIYLKsedgaO7EcmoSKFAaWF2BGTz/sEKl2jE nz2ttTs5d5fEM4sQxyH4IdPbUmazxB6t9fDUVtjGLk5YIE044DBVd9nftb7Fur4qUrO3Yw rkYF+XWAkWHgV7wPkbv7UgGlNb460dUcZiA9WI2OmCzfZGj4KpP4Peu2Ak8VcQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720100064; a=rsa-sha256; cv=none; b=p6UKg6E4ZiqXVuCnUnn1Bn/FJ2lkL/aS/eBtmM3PA2hrq8zSLWQWXe428mXGgCCideT5oj qzbBX/awWWKxiteTGvCMvyPU97EnHHIe3Yqf2W/5+AS7milp+rFAS8XgV5xoJlorRg1ZAL oAqlxs7zHqirYx3jb0cmps9ov1sZr5EFH3mD0a+Yj0y4T4hmPoC6jLizPxJ7hcfTgXvFJu QcWSiMZE1KFdpx3ENSDJ2lnHkxZN1olVDjK/l0wXwg4SQeClkhMWgWAlxrOoQUoqN5SMGY sswkmOTDa/9y+/2L6SyztOOMpWyjJInTpw9WaCWYEjFNGE6b7c30lzwXNftaIQ== 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 49C711B6E8 for ; Thu, 4 Jul 2024 15:34:23 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPMaQ-00081L-39; Thu, 04 Jul 2024 09:33:22 -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 1sPMaN-00081A-GW for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 09:33:19 -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 1sPMaL-0007Fu-4W for emacs-orgmode@gnu.org; Thu, 04 Jul 2024 09:33:18 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id C160AF62356; Thu, 4 Jul 2024 15:33:13 +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 9453BF617A6 for ; Thu, 4 Jul 2024 15:33:11 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id 0E99B396056D; Thu, 04 Jul 2024 15:33:10 +0200 (CEST) Date: Thu, 4 Jul 2024 15:33:10 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87zfqxpeog.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-Queue-Id: 49C711B6E8 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -5.79 X-Spam-Score: -5.79 X-TUID: QrqP/mZIAc3p Hi Ihor, thanks for your time to study the code and your very valuable input, much appreciated! Am Donnerstag, den 04. Juli 2024 um 11:41:35 Uhr (+0000) schrieb Ihor Radchenko: > > 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). Sure. I'm not at all familiar with the peculiarities of other output backends, but see your point. If you can give any hints or have any ideas *how* we could find general rules for separating the subtrees, which cover foreseeable use cases, or devise a flexible mechanism for doing so, I'd be glad to help setting them up and implementing them. I definitely agree, the code should be as general as possible while providing complete backward compatibility. > 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. Ok. > 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. I'll look into that and maybe I can come up with something. I was hesitant to propose anything as I tried to stay as limited as possible and not get too deep into changing things. If you have suggestions, please let me know. > 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. I'm not sure I fully understand what you mean: Do you mean specifying different :EXPORT_FILE_NAME: properties throughout the same document and then export accordingly? > 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. Very nice idea! MAybe along these lines is that I thought about "Master" org files which combine different documentations by linking to them in some sort of top menu which is included on every page of all these documentations and then being able to generate a single documentation without having to recompile everything. But for now I'd prefer to first get it working and then think about such extensions (I have more ideas for different extensions and "plugins" which could be useful). It shouldn't be too hard to implement at a later point and probably also wouldn't need a complete rewrite. > 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. Exactly. I wanted to make sure, the file names are sorted correctly, are unique and the title is relatable to the section it names on the directory level. I also thought about making it user-configurable, but first wanted to implement a working solution. > 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. Sure, that is the disadvantage of my proposal to make everything a "multipage" document. Another disadvantage is that when the user chooses to open the final document or display it in a buffer the user can't choose whether to only open/display one page or every exported page. In most circumstances it should be advisable to just open/display the first page. We can also just add a switch between single-page and multipage, with multipage always just exporting to file, but that also has disadvantages. As the code I proposed is encapsulated in the html backend and not spreading all over the place, I will now first go ahead to finalize the existing code to a fully working setup. ASFAICT adapting that to other needs shouldn't require a complete rewrite. And I might be around for a while ;-) -- Orm