From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.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 sIoOJf6twGZhAwAAe85BDQ:P1 (envelope-from ) for ; Sat, 17 Aug 2024 14:04:46 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id sIoOJf6twGZhAwAAe85BDQ (envelope-from ) for ; Sat, 17 Aug 2024 16:04:46 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=pEAblITZ; 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=1723903486; 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=hUbs1RIUAhyjRIaSnT11FP0cElTiV48rxiDIQ5SQHZg=; b=POpJ5Ze9A3kUhXtuSjJGBPPe4kaQ8w/C0S6iHQl+LSlaE65YB9zfAj0CoH5YejhbeaLFho XnDtu1o3mHfvg3iOOyi2d5TVFYeqyEgUtIDu5pvu+yjjpvJNsN3z5SCuiDUVwm44m404f3 RhdDDhD/NV/G/onB8teK5pm221aWoHTmjPA5MD4NRdt1FhoEheahQj+frKciWRUEocfm2V 5tytYT6fmriskLPvGC0gi3/JZTkJJRPEhraUK7mxeYlQyV6Mq2B+CYNM1nADC0zeUWn0Sn Vcx8LCaDq0hSo13IL6JmCGlSAwYvgPZ91S+ZixKW3KdM5mPxYB6JQzwg+hnzeg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1723903486; a=rsa-sha256; cv=none; b=kFmhUe1WveiMN4G1Cyt9uTnTSJlEnivhTmeDyurx1OCqXASDaf3GfcpZyl+Q1ggHQ5Nb6y B3+Wctp/rHW6EH7CS8xRMM6V74y6NrxCa2E7vyvco8IDqUj3+cECseCqiT3sBZ1B+qvFOw DEVj+9d9yXTvc8m3RZZoieOcJcGDD+2qMeKbK8Fk7mQ8oWnUHEmUTutKvAAE7FElPUmrb5 sgxuIg/e99Jwr2wyjiZCh5NAAsxbosEdXiEIYHz9F3NUCIYWLlmEZWVhbudwbUrAbD8wBm PeLTsIg/7tqnyUvtvdlW+qkJUYO+dI4xhq0gQ6RQJlxTPHufSV5kCKmeZaY93w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=pEAblITZ; 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 23EA215CC5 for ; Sat, 17 Aug 2024 16:04:45 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sfK2L-0004Jo-1I; Sat, 17 Aug 2024 10:04:09 -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 1sfK2J-0004Jc-H8 for emacs-orgmode@gnu.org; Sat, 17 Aug 2024 10:04:07 -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 1sfK2H-0000ir-72 for emacs-orgmode@gnu.org; Sat, 17 Aug 2024 10:04:07 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 3C1B4240101 for ; Sat, 17 Aug 2024 16:04:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1723903442; bh=+t/afjZxug/rym9Z4T0olQQQAC5sUtIYhenyzYijxzI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=pEAblITZtM+RdWJYqbOU8nFS+P8MGllBYAmudZkOxJwfdPDC+3jpn0rWuK/qqKkZl NQsVxWi2WdKsUWoABz6gPUKgiga+qqqs32wTTA/1seEMFRqh1j/P6S1MXZa+FuNBxY 1moEXv1dYKlY5f6UUhCs6zCrM1qjuHrIRiaHB8zyIlDvBgd9csfjyjtZHeABt4fLDs zFlNeO3D8FQo/y2ZUwqp1vqwvFpuId14QvKq56AQM61xZXNTRRDywjrc/RWD4W2m2+ vnp7hOmugGqXfkyGpp+6vOTQWHaGUgqUpauJdNtfHdVpwJBfQsVARPA5Tn4+f0MuAE zlfyHq3yhQkhw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WmLFF3SzVz6tyW; Sat, 17 Aug 2024 16:04:01 +0200 (CEST) From: Ihor Radchenko To: Orm Finnendahl Cc: Org mailing list Subject: Re: multipage html output In-Reply-To: References: <87bk2i8w07.fsf@localhost> <87r0b2kext.fsf@localhost> <87zfpk36er.fsf@localhost> <87a5hjxjbh.fsf@localhost> <87le11is5a.fsf@localhost> Date: Sat, 17 Aug 2024 14:05:07 +0000 Message-ID: <87bk1rz1m4.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, T_SCC_BODY_TEXT_LINE=-0.01 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: 23EA215CC5 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.11 X-Spam-Score: -9.11 X-TUID: qrTCPlWCjwt3 Orm Finnendahl writes: >> I do not feel like :multipage-split-function is supposed to be export >> _option_. It is more internal. That's why :translate-alist, where the >> internals like templates and transcoders lie. > > That's how I had it before, but I reasoned it is not a transcoding > function either, so I was unsure. Anyway I reversed it. Thanks! >> This is not a transcoder's job to export its contents. >> Please move special handling of org-page AST nodes to `org-export-data'. > > done. > + ((and (eq (org-element-type data) 'org-data) > + (plist-get info :multipage)) > + (mapcar (lambda (org-page) > + (org-export-data org-page info)) > + (org-element-contents data))) > + ;; Element/Object with contents. I am looking at this, and it feels like a wrong direction to go, especially if we want to generalize multi-file export to non-pages as well (e.g. formula exported as mathml file and as a link inside actual exported .odt file). Let's try to do it differently: 1. Introduce a new INFO plist field :multipage-pages - a list of extra pages to be exported in addition to the main document 2. Transocders can populate the list as needed, in addition to their normal return value, which may be a link to the page, for example 3. "pages" in the list, can be constructed using `org-export-with-backend' or other usual means to export data. 4. org-export-as will process all the pages from :multipage-pages in addition to the one returned by `org-export-data'. I believe that this approach should be the least breaking and the most flexible. WDYT? >> > (info (cl-list* ;; add :tl-headline and :tl-headline-number to info >> > :tl-headline headline >> > :tl-headline-number >> > (alist-get >> > headline >> > (plist-get info :headline-numbering)) >> > info)) >> >> May you please explain what is the purpose of constructing custom INFO >> plist, what all these parameters do, and why you re-do the export again >> in the transcoder discarding the CONTENTS argument provided? >> ... > :tl-headline and :tl-headline-numbering are needed for constructing > the side toc and the footnote section on each page. They are needed in > org-html-multipage-toc, called by org-html-multipage-template and in > org-html-footnote-section called from > org-html-multipage-inner-template. At that stage there is no > information about the page, the templates are on. Let me know if you > have a better idea how to provide/access that information, I found a > temporary addition to info the most natural way. As it will be needed > by any multipage backend which wants to determine the footnotes for a > page, I think there should be a generic solution in ox.el. > > As :tl-headline-numbering can be determined from the tl-headline > within org-html-multipage-toc, I can get rid of that if you > prefer. Let me know how to proceed. With my idea above, we handle the actual page rendering to a custom backend, which can reuse the normal TOC machinery, possibly encapsulated into sub-backend parameters. We can provide any additional info that is necessary within such sub-backend. Do note that we should not assume that each page corresponds to a headline in ox.el. It may be anything. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at