From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.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 oHCpMXDYjmZq0QAAe85BDQ:P1 (envelope-from ) for ; Wed, 10 Jul 2024 18:52:33 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id oHCpMXDYjmZq0QAAe85BDQ (envelope-from ) for ; Wed, 10 Jul 2024 20:52:32 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="O/V4IXfW"; 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=1720637552; 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=Cu9GncGmnAg3q4IFkMf+eynnwm4oschJ2esh0jYoxmo=; b=dPE56TEeRof3tWle5d32T/cPIrjn8FbTnE7ZMURmn6A+JqxwvJZ/A2hm+rhpE9wa+8zeWW XpyEm7tGIM6hajBGahn+QNFWqeGpL4DbEY+qT0b4j4oA6zYbk7+2HY9dhE/RcnfGO6eHVX f2zCkVIO7+kVYtJhXoNtA1Dn8ECG2TTfzgDmNWIJWQdbX1qSEg4oQSoIkFDBQ/6tq/zzkH efHccdnjUVaynxpGpK6WMvye5oWLz3IQRppDnOeqFG9hAvZ7bEH+/TLihyNIXmixz7v7Z0 KT0ZZQ7cyOHRHDU0Ciu7oOqLPQs8n4jvFJF3fwNs8yuj3r9IFATZZJZo/Oj9GA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="O/V4IXfW"; 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=1720637552; a=rsa-sha256; cv=none; b=fvPClJnAiGXDbMSOtMDAZxJ16jpryU758ve3PXCC6atQZstNdaFMsNO4d2YN8IySJCaBSW vOkYZwx3ootoDh7JRaHmhCqWo4jtQLMnwm3EYGJ3p4nkD7BNuSh+65SnKD9OsTPsxTT/Ik 6nFcR2fY64w9aP20x3Ev09lgRnSaABhlSbz5xE8erOHf+lkQTwHzy7n9J3oY8ByjX0wd54 smaTufv2BfRdwnzuRGwHqW1QadnY21mTvY+//kaPKlsMkjiyWTYYtg2OMnuVHVJlgVKi53 1SxEQiPzJf7Q1+JgkY+bYP9i0ozaKRarX4fBB1v4xa/9G2K9k6D+TGHNRVqVOA== 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 B65E16C4F1 for ; Wed, 10 Jul 2024 20:52:32 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sRcPq-0008Rh-UY; Wed, 10 Jul 2024 14:51:46 -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 1sRcPn-0008R3-No for emacs-orgmode@gnu.org; Wed, 10 Jul 2024 14:51:43 -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 1sRcPj-00040i-Dl for emacs-orgmode@gnu.org; Wed, 10 Jul 2024 14:51:42 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id DE137240101 for ; Wed, 10 Jul 2024 20:51:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720637494; bh=2ffMZxJsjJbtiUqlaVB/80H4hCHah3lohqoelm0z+xU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=O/V4IXfW211gbHs10XdQh0DBeMdPHfPJZlGR0ViX8z2NKNC1ybPRfzCrXRf4EJdsN j0qq1yshjw6TalQvQy6guanD4Et6MJyeYZXbJp6f7JTeUT1hW0qfvIhIY4Bx3TSMMu leROBmKnrWDImsoxrNecFCohENgtrxf4e02co1zTsFRNYgybA0lVtDuGFZbgr1Sq76 BL/FCpTCWXgenFLXzYt7C1pQ7EmuuNiz1rxxow77M3km9v9oEPL034BS5oYKP1gUO7 Rlh72L78j7pONCYXGAWwK35Pi1Mk2vGOr8q3qo/zUte96ZR0XLP9FS06CYt+1wMLjz hP4IIaLGdfFVg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WK6QZ1wKtz6twR; Wed, 10 Jul 2024 20:51:34 +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> <87ttgy78m0.fsf@localhost> Date: Wed, 10 Jul 2024 18:53:04 +0000 Message-ID: <87y1695ban.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: -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: B65E16C4F1 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.33 X-Spam-Score: -9.33 X-TUID: ilp5vNjYAobg Orm Finnendahl writes: >> >> > - 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. > ... > 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 > ...Is my explanation somewhat clearer? Yup. Clear now. In the nutshell, you want 1. Special export settings for certain pages (inline toc vs. side toc) 2. Extend TOC generation rules to be more automatic than they are now (insert TOC inline automatically for certain headings vs side TOC for the rest) Looks doable using the available means + previously discussed multipage setting ideas. >> 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. Sure. Feel free to do things that work better for you. Just keep in mind the ideas we discuss - we will eventually need to get them going and the preliminary implementation should not cause hard blockers. I am looking forward to your future contributions. (And, BTW, feel free to check out https://orgmode.org/worg/org-contribute.html - we provide some important information about our patch conventions. Please pay attention to https://orgmode.org/worg/org-contribute.html#copyright) > ... >> 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. Ok. More clear now. What you have is {TITLE}
{document body aligned right}
Now, I think I can answer your original question: > 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? For context, the vanilla exported HTML body is (see `org-html-template', `org-html-inner-template', `org-html-toc') {LINK UP} {PREAMBLE}
{TITLE} {TOC} {exported CONTENTS} {Footnotes}
{POSTAMBLE} {JS scripts} I see no major problem customizing TOC position in the HTML template. In fact, it would be rather desirable to provide a set of less bare-bones defaults (as long as they do not get too complex). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at