From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id WDxmN7nSjmb0NwAAqHPOHw:P1 (envelope-from ) for ; Wed, 10 Jul 2024 18:28:10 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id WDxmN7nSjmb0NwAAqHPOHw (envelope-from ) for ; Wed, 10 Jul 2024 20:28:09 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=hfmdk-frankfurt.de (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1720636089; 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; bh=l2itxrulVKTW7HzVaiXEernF/yVk/DcWieWyELZ+O+M=; b=uX+10kJIh1IM6Qs62vKQuIvmmROKbhXo7YAAWnVD8wrm6O8jUhoHB01TZk7Lfvqba/uSzL +p+L82Rm9YOxf3T87OYO+v1/6CvuCDinubmOviBEVL78MTSapMty5A5PwYpq5q96LfHHhN inzPprFUy6HIBNp9s45PTFUjF8rJlx/rU+mFKw24E9TQAM97jGyYtn1A1L1aSsrXHh5PoP XJ9Gm2x3lDxG9uJA6px4vxsXkbAuBlqX8stjq+MHGSLra8asFmCiZblRDPLMQrLPOHuWxQ jEEYtgjiVXrAPoYzvqTBvXJk7mpRn8WzNiAGcETQN9uTHGs6L45dD3XJb0X9gQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=hfmdk-frankfurt.de (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720636089; a=rsa-sha256; cv=none; b=DH+lfrwmz+wXA4r+lgC01Ppw8QPtQV+KvZodqkMoFOC8VY6dBo0b9nBOmjY5lTH9KW6vn1 5O1zduYAkXQ4qaJeqeQxMTRqOHcECKhBzHXCXWhUf2QdCahBui1w+NinROsh2IrfA/pt82 LbjADI0T+XJfXIjNJxhy+dnpMzWxn9EXyPmTcaazq6shQ0E1dLfYKo1AiqUrcJlWecRrEw JZeAjMem6K5Gjud5N9KT8CkNdyJlBaabQ1zBONsykZE0UNty59J5cJIEQSnPEm+ynD7pNM u+ORXK7YpDUHCQDNZEsUic2NfRmth8DKcB8E36LzXJegOg4NZKjS/r+KG504eA== 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 E5D496BBB1 for ; Wed, 10 Jul 2024 20:28:08 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sRbfR-0000jY-4D; Wed, 10 Jul 2024 14:03:49 -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 1sRbfO-0000bE-RY for emacs-orgmode@gnu.org; Wed, 10 Jul 2024 14:03:46 -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 1sRbfM-0003mu-BX for emacs-orgmode@gnu.org; Wed, 10 Jul 2024 14:03:46 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id D3402F622FC; Wed, 10 Jul 2024 20:03:39 +0200 (CEST) Received: from selma.hfmdk-frankfurt.de (dynamic-176-003-027-011.176.3.pool.telefonica.de [176.3.27.11]) (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 8FA5DF61BD3; Wed, 10 Jul 2024 20:03:37 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id 4B34E3960570; Wed, 10 Jul 2024 20:03:32 +0200 (CEST) Date: Wed, 10 Jul 2024 20:03:32 +0200 From: Orm Finnendahl To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: multipage html output Message-ID: Mail-Followup-To: Ihor Radchenko , emacs-orgmode@gnu.org References: <875xtmd9nz.fsf@christianmoe.com> <87msmypwfw.fsf@localhost> <87zfqxpeog.fsf@localhost> <87sewp9liq.fsf@localhost> <87v81fzytw.fsf@localhost> <87ttgy78m0.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87ttgy78m0.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: E5D496BBB1 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -5.80 X-Spam-Score: -5.80 X-TUID: 5AmLgGnu7TQ+ Am Dienstag, den 09. Juli 2024 um 17:55:51 Uhr (+0000) schrieb Ihor Radchenko: > > 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) Yes. Currently I' more concerned with the architecural layout. Everything else is a matter of taste and easily configured (and hopefully agreed upon) once the structure is done. I'm very relaxed and unopinionated about how to handle options as long as they don't involve changing the org document for each export backend. > >> > - 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? Consider a doucument like this: ** Headline 1 ** Headline 2 *** Subheadline 2.1 In the multipage export you want a front page with booktitle, author, date, etc. (maybe even an image...) and as a second page after the front page you want to have a full toc. Both pages should be reachable by the side toc but shouldn't get numbered so the toc on the side would appear like this: My Booktitle Contents 1 Headline 1 2 Headline 1 2.1 Subheadline 1 On the other hand you might always print the booktitle on every page and as the toc is always at the side you might not need titlepage and toc as seperate pages. Or you like the layout of the info mode with just navigation buttons and no side toc. In these documents, the toc is normally on the first "home" page. This would also imply a seperate html page with a toc and possibly the title on it. As there are always different preferences for this I thought to introduce a list which specifies, what king of documents should appear at the front of the document which aren't counted in the toc. All these are -in my opinion- legitimate decisions not at all unusual in publication situations so I thought I accomodate for that. Is my explanation somewhat clearer? > > >> > - 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 > ... yes. we can build a complete machinery around all that, but currently I fear that this gets a bit out of control for me: I really have to get going with other things and currently I'd prefer to realize something that works with the architecture built in way that it is easlily extendable in the future without having to redo everything again. > > >> > - 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"? Look at the tags and ids of the html code on these pages. -- Orm