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 8HGOLZl5jWaHDgEAe85BDQ:P1 (envelope-from ) for ; Tue, 09 Jul 2024 17:55:38 +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 8HGOLZl5jWaHDgEAe85BDQ (envelope-from ) for ; Tue, 09 Jul 2024 19:55:37 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="eh2ICQ/L"; dmarc=pass (policy=none) header.from=posteo.net; 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=1720547737; 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=DOwuuido1wb5dAD8TfWR3IpZTnJRO9iicK7qchKjzhA=; b=Gss54YfwnfG88b0Fy4RU+U4D+db1eeREOXBVuaGT6R3mvKgERN4wLqlf8CWwXFWxiI0Mnq 6ZXSe+FD1/cRzsOCXaHk03hzyUcfPOnc0J9imYM9dw5r64qoWRHZQ1O4naoLkSJirWagSL sTvzGm78786PIArQmCkgetWvLHqRihUXuN0PGvQ2BlJyo2hlIK9Pt/8fF5Spqi+uifNk+t 1vE7E/qsFaBPrKiq7I2DpSA6cNRsGkILWzEPxWwazK+tpLD63AdAOQxiETKdl57quUm152 qsf2qwfu8htW84M9JaO9O1M4s3QxM+gUl4/fp/EOMzujzdep9YGeQRZWcIgpZA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720547737; a=rsa-sha256; cv=none; b=BBh0NodJlQBZNd8PzbxEs6OkyoJtcK4eRb94AHXVyZY10rwCmcpHujSMrz8FQgboe+0S2i 4gSaqrrQ5bualnHv3BoHDkPBmbPO9LR0Z3MIPC9fUko1N6B+17NmwnmJzcjUlr1ixAua1y bPGMx4aoo5rCwT+QLLS/g25ZbkJLMZK1XUt5LMhnT2U1BSVMHW+FPFLC0n4pNa1xUrExNy O8gHYEQrRkE1JHP5Ua/y9oYfkgrpalGszmo9/M9T4zYD3KwO+8TPLdNYp3rfcmwaVIMX5p UQDpLJUHFjkbs3jl8MBtMfRsqPQOdaglAGcMhcJdVi4QrKwVc8o8zLi9CAFYlA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="eh2ICQ/L"; dmarc=pass (policy=none) header.from=posteo.net; 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 37F9E3ADC9 for ; Tue, 09 Jul 2024 19:55:37 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sRF31-0004gk-Cm; Tue, 09 Jul 2024 13:54: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 1sRF2y-0004g5-GO for emacs-orgmode@gnu.org; Tue, 09 Jul 2024 13:54:36 -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 1sRF2i-0008Bh-OI for emacs-orgmode@gnu.org; Tue, 09 Jul 2024 13:54:36 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 69BDC240105 for ; Tue, 9 Jul 2024 19:54:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720547658; bh=dHZf4jkr+wSHbcJE7xgRDJjyBG7+ZmyTA5vn0lPiPcg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=eh2ICQ/LKfl6SEb4EGjwyy4IXgQ1hURAbSeaUIaJGGVoNncIDRplxUmIFhcW0OWqu A0xw1tqt1XS+lTuebutQvfS3Nc30wpMHeb44P4Lv3O+4P2JALaMG9Gf0uv48pH3HvR 6f9scimT2oNfVtBYW3xwEVNNJwcgRO4Ka2EA9Vng5wCX196ylhs9oTGt7+Otx7+yFX QGMG58pIR2NX2u6vX7aaMWbFtWOAOo+djexPGkgEm0K+Jk5ikk+7+HWAWocV7NT0aQ x2l9rCZ/geaHJVtLWQSKxzlAUykg5DQec2V2zOkxeSwKO+bun0a6kVmPYeJXR80jKH NIe6OMgbe5zTA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WJTBx4bmlz6tlh; Tue, 9 Jul 2024 19:54:17 +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> <87v81fzytw.fsf@localhost> Date: Tue, 09 Jul 2024 17:55:51 +0000 Message-ID: <87ttgy78m0.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: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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: -5.13 X-Spam-Score: -5.13 X-Migadu-Queue-Id: 37F9E3ADC9 X-Migadu-Scanner: mx11.migadu.com X-TUID: dTVbLg5ithQq Orm Finnendahl writes: >> Is there any situation when you need to export the full document >> vs. multipage to different places? > > Actually that is what I'm currently doing (and what I need for my > publishing chain): The single-page document is not in the html folder > used for the multipage document. Both files happen to have the same > name so it wouldn't work out, if I want to generate single-page along > the multipage version, without having to change the document. If this is the case, users may potentially need similar diverging settings for single- vs. multi- page documents for almost any given export option, not just the ones you mentioned. To address such situations, we may, for example, allow an alternative "multi" version of each export keyword to act specially when multipage export is used. Consider that there is an export option #+SAMPLEOPTION. If the document has only "#+SAMPLEOPTION: value", exporter will use it for both normal and multipage export. However, we may allow an alternative #+SAMPLEOPTION[multipage]: multipage value that will be used instead when defined. In addition to defining alternative variants of in-buffer settings, we also need to provide the equivalent feature for custom variables defining the export options. We can do it by treating the value of such export-related variables specially - we may allow special values like [org-export-variants :default default-value :multipage multipage-value] and provide helper functions like (org-export-set-option option-name value) ; :default (org-export-set-option option-name :multipage value) ; for multipage export only (org-export-set-option option-name :singlepage value) ; just for singlepage export (Or can be some other consistent way to define alternatives; feel free to brainstorm) >> > - org-html-multipage-front-matter >> > >> > A list to specify pages in front of the headlines of the >> > document. Possible values are 'title, 'title-toc and 'toc. title-toc >> > is a combined page containing the title and the toc. Multiple >> > entries are possible. >> >> This sounds orthogonal to multipage export. May you please illustrate >> what you want to achieve by introducing this option? Maybe there is an >> existing feature that can be re-used instead of creating something new? > > Could be: The toc as a first page is needed, when you don't want a toc > on the side of each html page, e.g. when using the classical info > layout. And it might be necessary to be able to distinguish between a > separate title page with author and the toc on the next page (or a > combined page with title and toc or no front matter at all because the > title appears on every page). If this is possible with already > existing options, even better. I just think that it might be necessary > to be able to distinguish between the needs for html output format > vs. the needs for LaTex or single-page output without having to edit > the document (I need that as my publishing chain is going to export > info, html multipage, pdf output and html single-page output using the > same org file). Sorry, but I still do not quite understand. May you please illustrate a bit more with some kind of simple example? >> > - org-html-multipage-join-first-subsection >> > >> > Boolean: Non-nil means that the first subsection of a section >> > without a body will be joined on the section page >> > (recursively). See my generated example pages linked below >> > (Chapters 4, 5 and 7 for a recursive example) >> >> Sorry, but I cannot understand anything from there. May you explain in >> words? > > Consider a case like this: > > * Headline 1 > ** Headline 2 > *** Headline 3 > Text for Headline 3 > > Without the above option, Headline 1, Headline 2 and Headline 3 would > be on separate pages with Headline 1 and Headline 2 being empty pages > with just the Headline. The option puts all three Headlines and the > Contents of Headline 3 on the same page. See here: I see. It sounds useful given that your strategy to split the document into pages is "on each headline on each level". Conceptually, I see this as one of possible customizations for paging strategies. Your `org-html-multipage-join-first-subsection' simply tells to split off pages only when there is non-empty contents inside the containing headings. This also reveals that we may sometimes want more than just to tell how to split the document. After splitting, we may want to rearrange the pages differently (maybe even re-order?). In other words, multipage export may need to: 1. Take document AST 2. Split it into multiple parts 3. Filter the obtained part list (post-process) 4. Perform actual per-page export ... >> > - org-html-multipage-split >> > >> > How to split the document. Possible values are >> > >> > 'toc for generating a page for each toc entry. >> >> May I guess that the previous option may have something do with >> situation when #+TOC: keyword is in the middle of a text? > > No: In the online document of the link above the page splitting > follows the toc (with the exception of the page joining explained > above), meaning that each visible toc entry will generate one page. Be > aware that this is not obvious on the online page as subfolders are > folded automatically using the css (folded elements have the class > "toc-hidden"). If you look at the html page source you can see that > every page contains the full toc to enable other css or js based > styling decisions. Sounds reasonable. I guess that the docstring can be improved :) >> Do I understand correctly that your alternative layout is simply a >> question of custom #+HTML_HEADER? Or is there something more to it? > > In my layout the main difference is that the nav left and nav right > elements are part of the page-main-body rather than part of > . I'm not positive this is elegantly manageable with css, > when the navigation is outside the page-main-body. Sorry, but I am lost. What do you mean by "content" and what do you mean by "page-main-body"? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at