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 0HCuKc0FjGarBAAAqHPOHw:P1 (envelope-from ) for ; Mon, 08 Jul 2024 15:29:21 +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 0HCuKc0FjGarBAAAqHPOHw (envelope-from ) for ; Mon, 08 Jul 2024 17:29:17 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hVc5y3lx; 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=1720452557; 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=owSGbE28XkeXzSRtAceXpmDtLEXcOQaIC+xZg+voezA=; b=SW0u8qPxaFxKRfVfwGIFx1wruXL0lV5MY29y9LI0wdgRykaSyGgmu7RtrQdJGr0hop23Z5 ZaSk9N+qVlAnyAHlgAhcX1ERR52tUxEA42eyo+lanaW1/defCTElp/dmw3nd9JP2rdgqE/ 57nQ2FWLzj4QQasE/blvrBxs7CR1QOhk80YRewH1mgNYE8MNro4NvptqtgPtoOegY5uoVj 6jbXLA2DHoEPZOEzBsrO+kcf/6hZrif8t1AEvaCgw7pwK5hJ8rqCRQ1z+bSU3sPTO/01cs 4ORjtpz/KDQOOJyLmxb7XEtpK2LlAZzo7YhBt7snJYK0cvpjNK9PTc6Su6mtEA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hVc5y3lx; 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=1720452557; a=rsa-sha256; cv=none; b=lFZ1gEAcKVJaOGepIMR//pg0XuGHScAROpM9d4NnKIVBuJivMqcIGd2P3xL7ZvTU1UH7Un Wi2eP3Sy3yYt5YH3sPKNKuqY7ZKiFaOvTdj5TfVDQq0js4hNz6SE5iqUrlNfIeszyAmCLg D52fQXlEZqbQrqf0A6Jina8MdRXhV0m6V5i4D8YCYcWAtZvueLnD/+3q20Y73ajwwJ+AMl EDsawc302l3CavGO1zQCn1o8ewvvv6IAlHt5q8LopiSGAlAiB1bx72X/8nHbRYUnl69UsI wcDVbbZxPmP3EhZHBsBG6g/pa5EmtyQ9ju9OmV8W4Ws1N/KGRfu//eROu9OeAw== 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 599C4517FC for ; Mon, 8 Jul 2024 17:29:17 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQqHu-00071S-V3; Mon, 08 Jul 2024 11:28: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 1sQqHs-0006rQ-T2 for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 11:28:21 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQqHp-0007cH-S3 for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 11:28:20 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 9F6BF240027 for ; Mon, 8 Jul 2024 17:28:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720452493; bh=8XgIqdEzKBYSSlwmipzphTXzGZRObRZSgWnBKq6NWyA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=hVc5y3lxYCg1CAWoEMlMr0IsU5If4l0KeFuMwK5jR0WNs4owIxM/GyfEjS3SsoFvt F6F93gq7i3oTMmXG11x97Xk3pS0wbwDXx4oURm0KuEMzB74oGXtyWL+qtN2wJsDAxj E4IUNJwl+h2F27GhQFxCfeImCzP+oobOmnprmyONd2BC2u9GmyuGTotG9QkU2PSw4t NOg2v+X5XaOXIo5s0y8JdcpsDl7XDQ8kbHPJncGEKDaZoK2iwLtv8+az9lzftx0Iys 5IC9mcVDDSJ/YRKzNZ3ABQvphZHQhMrqe2/TJRh41RUGm4gobbNgl311cAGyClGZG/ v3Oiz04WuPIgA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WHp0r16cLz9rxD; Mon, 8 Jul 2024 17:28:12 +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> Date: Mon, 08 Jul 2024 15:29:47 +0000 Message-ID: <87v81fzytw.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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, 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: 599C4517FC X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.62 X-Spam-Score: -9.62 X-TUID: FEybbq6Ya3fz 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? > - 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? > - 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? > - 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? > - 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? > In addition I have a question about the html output layout > structure. Here is an example of a file generated with the current > code with some preliminary layout. It might give an idea about my use > case: > > https://www.selma.hfmdk-frankfurt.de/finnendahl/klangsynthesebuch/01_00_00_vorwort.html#orge24571b > > Regardless of the colours, the file has a slightly different hierarchy > than the single page html template of ORGMODE and is more oriented > towards the layout of documentation nowadays with a (hideable) toc at > the side on every page rather than the texinfo oriented layout used by > the orgmode manual. If my code gets accepted/merged to org what should > be the default layout shipped with multipage output? FYI: The > visibility of the toc entries is managed by the css and the whole toc > is included on each page (and its visibility could be managed with js > as well). Should I rather go for the classic texinfo view? Do I understand correctly that your alternative layout is simply a question of custom #+HTML_HEADER? Or is there something more to it? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at