From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id QHPAMZS6n2Z+qwAAqHPOHw:P1 (envelope-from ) for ; Tue, 23 Jul 2024 14:13:40 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id QHPAMZS6n2Z+qwAAqHPOHw (envelope-from ) for ; Tue, 23 Jul 2024 16:13:40 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=OCf6B4QL; 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=1721744020; 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=3x/9kSlk47aLtKLFXGR84Yu3uWimNXpElzE0EdFKkjg=; b=SoBi46QcAKIzHbtVfdj6uEgnKRxLD8absYotJFf/WPpQzw2OrH2yObqJUgn6a6eDuF4Nzr vdZoVQ2Rc4beflSwe9gGp3yBjKcRN0cLyKfLg8twhBtgbWXApJhQiCtIkpLMkpfoa0vfEI mzn9Z2N33bFzp3oRh/pQnVZ05sMxcq9kPjhX6HPdAovycxPQ6xTlrjKXZiSDnBmMOPzuJ/ DbYHkV1lg5xIJZgYKp98z4ZxU0GdmoTb+kJvN9fWdyN7LLOGKLJrufokdm8iScVRImUY30 GAvZp5rGW5QYOXfIYOan5qtmMULFjJZ+funHFBq2sDACh+mRMJBFjv4b2Bmrew== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=OCf6B4QL; 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=1721744020; a=rsa-sha256; cv=none; b=DWd1OOdmCkHhuDtSM/7RZKlDPkl3Zlmoqks6nJh4IvYEl4Klz3tdDqkvnwJgtiTqN/OrIX 3ICdzJf/RRIujzmqJynLRSvhH9FIrl4g3zl3ZbaOXnoMv8lCpLNZV46MGceaIcB29HLbL5 0NvZFjAqnucu3T/g0Ue/JOWo7IhJO9KRe94kCDC8jEN7xm0pzPfOsDDLfiv5khyY6dxalO TzX6iwB7tgM2JcN9rgYyVgF32qqM3CPP6LirX9GWWHaMlUvk27UMexI+USsh+L8q0aNgPS ZXwM5eMEozIfs61/fMXCJfdS5T29H+hI09teEVbTGKxcZ3g59iSZ3zOmhMKYxQ== 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 57442700A1 for ; Tue, 23 Jul 2024 16:13:40 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWGG0-0008OS-4Y; Tue, 23 Jul 2024 10:12:48 -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 1sWGFt-0007xn-Ip for emacs-orgmode@gnu.org; Tue, 23 Jul 2024 10:12:42 -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 1sWGFp-0006Mz-Ka for emacs-orgmode@gnu.org; Tue, 23 Jul 2024 10:12:41 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 65349240103 for ; Tue, 23 Jul 2024 16:12:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1721743954; bh=V+Qm1M4ziBJRqYDFTUbzdunglJ+qx2oC4nLKUKUI8BU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=OCf6B4QLu2nA4zNOzOwC50wK2mXfuwAxhSSFfINSc+bvfQiqx9jogGk6yZoDmkvtD PRN6qt7+7Z/TaQQhJe9VXFFXx4hYmkvAoCHUbr6Afe5vf3qCRLypRyBNurBnI8G7o4 NQuEttKw4Q19XXvMM3tbgHTuuElJbTdvL6ykw2YUIZ7zZqF944uJdGyWo5VaDg9gH2 Yp0xQpXfgIQAPWR7J7ArmPT302ORmuWhPhNOBb1BY1kuyPvJtLWSr0wS75caJjoAK0 TApJHBOchgWd3llRgadLrWk7FSL6W7W9oPGrywf9/fJ+VClmkUeOeG2bgoe7pC+7Dk GgPbkLFeJ6ApQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WSzcd3fD7z9rxD; Tue, 23 Jul 2024 16:12:33 +0200 (CEST) From: Ihor Radchenko To: Orm Finnendahl Cc: emacs-orgmode@gnu.org Subject: Re: multipage html output In-Reply-To: References: <87o777zxkv.fsf@localhost> <87r0c2781h.fsf@localhost> <87r0c05com.fsf@localhost> <87wmlp38gr.fsf@localhost> <874j8gz9qh.fsf@localhost> Date: Tue, 23 Jul 2024 14:13:53 +0000 Message-ID: <87bk2o2o2m.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-Spam-Score: -9.64 X-Migadu-Queue-Id: 57442700A1 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -9.64 X-TUID: TphPvyo+aelm Orm Finnendahl writes: >> > - added :multipage case to `org-export-as', calling :process-multipage >> > callback submitted in info. In the multipage case, org-export-as >> > returns nil relying on :process-multipage to do the exporting, while >> > in the single page case it returns the transcoded string to the >> > caller from the backend. >> >> Does it mean that you do not want page splitting to be controlled >> globally, in ox.el, as we discussed? > > Not for now (I mention that later in the mail when I talk about > section-filenames and future generalizations, where this definitely > has to be done). In the html multipage export are many peculiarities > which don't apply to other backends, so ox.el wouldn't be the place > for it, so we will need some callback mechanism anyway. > > Right now this gets accomplished with a small branch in org-export-as > in order to change as little as possible. It'll be easy to change if > we find a good way to get this done using a more general approach. But > I'm open for suggestions, if you have an idea how to already do it > now. Then, a more natural way to achieve custom document-wide transcoder will be introducing "org-data" transcoder into `org-export-transcoder': (defun org-export-transcoder (blob info) "Return appropriate transcoder for BLOB. INFO is a plist containing export directives." (let ((type (org-element-type blob))) ;; Return contents only for complete parse trees. (if (eq type 'org-data) (lambda (_datum contents _info) contents) ; <=------------------ (let ((transcoder (cdr (assq type (plist-get info :translate-alist))))) (and (functionp transcoder) transcoder))))) For now, we have a hard-coded identity CONTENTS -> CONTENTS transcoder when exporting the whole document, followed by applying inner/outer templates. We may instead allow the export backends to introduce "org-data" transcoder as a part of exporter definition. When non-nil, it will be used instead of what you extracted into `org-export-transcode-page'. And `org-export-transcode-page' will be used as the fallback. WDYT? >> > - changed that `org-export-numbered-headline-p' always returns t for >> > headlines in the multipage case to ensure headline numbering is >> > collected. >> >> > NOTE: The single-page case will be handled like before, but it might >> > be a better idea to change the behaviour and do it the same way as >> > in the multipage case: Always collect the headline-numbering and >> > only decide at the transcoding stage whether the headline should be >> > numbered in the output. >> >> Why? What if one wants headlines to be not numbered? > > Just set num:nil in the options. But your code ignores num:nil, does it not? (defun org-export-numbered-headline-p (headline info) "Return a non-nil value if HEADLINE element should be numbered. INFO is a plist used as a communication channel." (unless (org-not-nil (org-export-get-node-property :UNNUMBERED headline t)) (let ((sec-num (or (plist-get info :section-numbers) (plist-get info :multipage))) ; <-- overrides num:nil (level (org-export-get-relative-level headline info))) (if (wholenump sec-num) (<= level sec-num) sec-num)))) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at