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 SNonAbqVn2Zu9QAA62LTzQ:P1 (envelope-from ) for ; Tue, 23 Jul 2024 11:36:26 +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 SNonAbqVn2Zu9QAA62LTzQ (envelope-from ) for ; Tue, 23 Jul 2024 13:36:26 +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=1721734585; 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=BpCr6U2IB17Ed+F4vaIZ9h09oswJ/RUQMM5Tf+0UJeE=; b=Ik/Yy1zFlJKSAo5AFupyjiij7CVCZamHhYbBw3hW3CcgrYaNXUKcHLxPl4s08oIF8Z8OKZ 5lMvO0FjTnyiH8F6maHUwjCS+hOkMUXQRnxgPTAN7C5fjSvQJmC4GbZwQApLwgXksU0VMK My9CDw4FMp4x1cl8KLwxcmGOz65qbDp2Ywr0BW3yWKykXXUaZXLq2C75ADBduEpflkkgMh WkXW3Ay9i6ZHG8UMnEIogOb2cftKsZggV0n/H5c/qF8pAtmE68DDCcY7UkPx+9KRdSg0Oq Hh+z9h03ytqlO5eI4tBVjFrCYCSWPXHcIZ0zltuumQDt2LBjLvpz9Kfkp9bH+A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1721734585; a=rsa-sha256; cv=none; b=P/XyclndalgJ9GM8iSOp2vp0KjycT4lq+fRh3Q2KUSkQVffxJARZd20KzlKgijNMr4nkB3 u7Hp2zDorSbYiZ58X35E5lBPpwwdzGQPtSQ0ddZPyRS/HJZ0jFZYmGh/ZZG3slw4zcMU+m AsLZpTFt0Sl7nGNe8D+NAhZnbylP7k3EU3RQ9UGw06Rey5lCloUKLRyRcbh9EgN1qtSsn1 EU8N89NVjqBJzFzj0uArm042UXnSgYI3lKqCNEZb4HMuZMmplimUEoAQrm/8XV14G4phq8 1mi1gvLzpFwPkAawsQeqleHXbOyUfISPGzcMv/ffjP+f/r5ClXJ0/kmMc4qRFg== 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 B2C5E3762B for ; Tue, 23 Jul 2024 13:36:25 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWDne-00042u-DE; Tue, 23 Jul 2024 07:35: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 1sWDna-0003s0-Jj for emacs-orgmode@gnu.org; Tue, 23 Jul 2024 07:35:18 -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 1sWDnX-0002aV-Uw for emacs-orgmode@gnu.org; Tue, 23 Jul 2024 07:35:18 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id 8D085F60292; Tue, 23 Jul 2024 13:35:12 +0200 (CEST) Received: from selma.hfmdk-frankfurt.de (ip-037-201-128-004.um10.pools.vodafone-ip.de [37.201.128.4]) (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 4A37EF60292; Tue, 23 Jul 2024 13:35:10 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id DB3DA3960515; Tue, 23 Jul 2024 13:35:09 +0200 (CEST) Date: Tue, 23 Jul 2024 13:35:09 +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: <87o777zxkv.fsf@localhost> <87r0c2781h.fsf@localhost> <87r0c05com.fsf@localhost> <87wmlp38gr.fsf@localhost> <874j8gz9qh.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <874j8gz9qh.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: B2C5E3762B X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -5.81 X-Spam-Score: -5.81 X-TUID: 4qtXL04lj2wX Hi, thanks for the quick response! Am Dienstag, den 23. Juli 2024 um 10:24:54 Uhr (+0000) schrieb Ihor Radchenko: > I will first focus on reviewing changes to ox.el. > > > ox.el > > > > - added `org-export-collect-tree-info', and > > And it is not used anywhere... What is the purpose? That was not cleaned up from a previous stage. Removed, thanks! > > > org-export-transcode-headline, extracted from `org-export-as' > > How does it have anything to do with "headline"? Maybe `org-export-transcode-page'? changed. > > > - 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. > This looks reasonable. Maybe even as a separate patch we can merge > earlier. Sure. > > > - 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. As mentioned, I think printing headline numbers should get handled in the transcoding stage of the backend and not before. Multipage export behind the scenes is completely dependant on headline numbering, even if headlines aren't displayed, so the code in ox.el first proceeds, as if headline numbering is turned on and moves the check for headline numbering to the transcoding stage. I didn't change the behaviour in the single-page html situation. Although I think that it might make sense that headline-numbering in general only gets checked at the transcoding stage that would affect all backends, so I didn't change anything. Thanks also for the info regarding how to contribute. It'd be nice if you could gibe me a go in case you approve the proposal. -- Orm