From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.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 iBIUFXs6jGb2BAEA62LTzQ:P1 (envelope-from ) for ; Mon, 08 Jul 2024 19:14:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id iBIUFXs6jGb2BAEA62LTzQ (envelope-from ) for ; Mon, 08 Jul 2024 21:14:03 +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=1720466043; 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=fijzfkSsbMAwE8tEHFrYyKMmzI+Zq+5k5FIA+ohUJVQ=; b=Ht0jkOhUXTMJ9znHaJ47+SKE8v+Ua1BAgQQWRyvdh228FbCIDmxSXGL85XitxRuN6BNObY f07YJxVlcRmOMcIqaPfYcAOBR9Cd2nRNoF0pN1i+mi1ntXPlxDPy4UmTvXZ5auaWzx2SzF LOVbRNUal/HYoZTIVw2qerY7Kb8itEIbvlf4jIK5hNQPL7HX01XGbGwrBU8CYFmKBJBCF4 h26gFq79UR6Hdy/0xBOF9wt/lFVlj/xFbKSfDpDpTSzEzJpYKhc3gKOgnLQNQ8WTsZJzWG scHnjcLgU1R1s+a8aBgY4259ilFgqFnivlhQSXmIwJuGBtp7ldmn9KNcM/NsNg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720466043; a=rsa-sha256; cv=none; b=nRgl0CV5LE1rgeLXmXw/wYztA8fvt04E+ZyoFgD/v/hUuuGrYcs66kOOhX1VZ9dtjlzLTo FzxzT6wHZBR/uh8kfiuZA6DHq2GF0KbrwsYm59kA0O02C93cezG1Q5LMdfwSQV9KpVV/jv wObOFRymOZi1Gxbw5VnfdEFDXKFewCcXIErHxsjg+dr7PZhq/PDV2xmi25kepVI0Mb4j8k GP4ezEOyNuXmjxIN6aA42F+8ibPMS/I/UkNz44tGhouS+QVfXJWeBsRY1y10peAowAqvtC rYFz68T6op4sjaWPTDTYP1RGvZSP9lXAK+98/SQrqQuq7XJoG71h3cRrKpBMpQ== 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 0A2C36C147 for ; Mon, 8 Jul 2024 21:14:03 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQtnL-0005qJ-Sg; Mon, 08 Jul 2024 15:13:03 -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 1sQtnJ-0005py-PL for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 15:13:02 -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 1sQtnE-00015B-6b for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 15:13:00 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id 7935BF61D4F; Mon, 8 Jul 2024 21:12:52 +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 3DB59F61C18; Mon, 8 Jul 2024 21:12:50 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id EF9D63960570; Mon, 08 Jul 2024 21:12:49 +0200 (CEST) Date: Mon, 8 Jul 2024 21:12:49 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87v81fzytw.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: 0A2C36C147 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -5.79 X-Spam-Score: -5.79 X-TUID: z/O11bkn7685 Am Montag, den 08. Juli 2024 um 15:29:47 Uhr (+0000) schrieb Ihor Radchenko: > Orm Finnendahl writes: > > > For the backend I'm planning to realize the following options > > (implemented as custom variables, which can be overwritten in the > > document): > > > > - org-html-multipage-export-directory > > > > The directory for the exported files (relative or absolute). > > I am wondering about the reasoning behind not re-using > #+EXPORT_FILE_NAME: here (its directory part) and simply defaulting to > `default-directory'. > > 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. > > - org-html-multipage-head > > > > (similar to HTML_HEAD but will be used instead of the HTML_HEAD for > > custom css/js) > > Again, why not directly using #+HTML_HEAD? Same as above: My multipage has a completely different css and js and I think this is unavoidable. All this is just for being able to do both exports without interfering. > > - 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). > > - 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: https://www.selma.hfmdk-frankfurt.de/finnendahl/klangsynthesebuch Chapters 4, 4.8, 5, 5.4 and 6 (two Headline levels combined) and Chapter 7 (three Headline levels combined) are examples of joined headlines and the other (sub)chapters are examples, how Chapters containing body text are handled. It's mainly a matter of style but in some situations it doesn't make much sense to me to add content below a headline just to avoid an empty page in multipage html output. > > - 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. > 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. -- Orm