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 kGdGF8M7jGZADwAA62LTzQ:P1 (envelope-from ) for ; Mon, 08 Jul 2024 19:19:31 +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 kGdGF8M7jGZADwAA62LTzQ (envelope-from ) for ; Mon, 08 Jul 2024 21:19:31 +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=1720466371; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=cE2qmKZoiBZnwFsJUM57gdn6ic6wPPomNE4pZB6IZDo=; b=mwRVhoAaNcWGhCE8Ken3GXBCzkKdA4TQDx66CaSfr5WFbUPg9wXhlgiPnLV9bF+uTHhjWn mBQ9K8Jguep06psRcWTcUdjJRqqxxE+a4Lc8SYWQeC1SY/juS/QrR2tFhPASA1rqUyhFK6 8RU5Srset62LLiyuR+yTKOLQxzKiEw+/PmQtwQf9GPg0lUVjCS+1/0Ouz8y8QgRydhr0lm 5CtErJIFQ4zftohk6omdkDTCBSjY9DRL3bs6YFE1TLpypUkEfc6jJQVIw5hG/eMqrdcK5W gFdk/BOe2Ca65sn5Y3D2wsjgCR+A0+IKBj9WF+mAMcIojZDwSWuoy5JdW79nQQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1720466371; a=rsa-sha256; cv=none; b=NGonzz6PV3jXlg6sM1YHXLMZG1N+z4vm0nLs2Xh0nou0QI96YHGMS5mpZc6RkPUY5l56Cz 4BUpgRM0nD2CEAe652ch/t8ZOty4RgqDPq3eB8TkKOJ1aNiHbTfxoPeWhla5QvwPBOljrC m0HaR7abqa3n9rIYC9vsJwHJfmjAiidWfwHeDkku0tv59W8RQ9VkXztrNRiugNLDlU4kRo +zshaqNz0H7S2MTcKf8STgjzSlJ/DEH9jvUKL34abV4HfXEpbfiNNtY+0vuQn4u5Q8RYSX Zm7Uo/vqM/9TZcmH/SQeKoq1FRtJ8MFY7CjGnJNhKhASGoHhFVV1pLn0bDAHSg== 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 292EC6C4BF for ; Mon, 8 Jul 2024 21:19:30 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQtsi-0003AY-B3; Mon, 08 Jul 2024 15:18:36 -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 1sQtsf-0003AM-QJ for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 15:18:33 -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 1sQtsd-0002GZ-Q7 for emacs-orgmode@gnu.org; Mon, 08 Jul 2024 15:18:33 -0400 Received: by mail.selma.hfmdk-frankfurt.de (Postfix, from userid 113) id 9B5BCF61D28; Mon, 8 Jul 2024 21:18:28 +0200 (CEST) Received: from selma.hfmdk-frankfurt.de (unknown [212.201.35.182]) (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 83BA2F6198A for ; Mon, 8 Jul 2024 21:18:26 +0200 (CEST) Received: by selma.hfmdk-frankfurt.de (Postfix, from userid 1000) id 5322C3960570; Mon, 08 Jul 2024 21:18:26 +0200 (CEST) Date: Mon, 8 Jul 2024 21:18:26 +0200 From: Orm Finnendahl To: emacs-orgmode@gnu.org Subject: Re: multipage html output Message-ID: Mail-Followup-To: emacs-orgmode@gnu.org References: <875xtmd9nz.fsf@christianmoe.com> <87msmypwfw.fsf@localhost> <87zfqxpeog.fsf@localhost> <87sewp9liq.fsf@localhost> <87y16bzzxl.fsf@localhost> <87o777zxkv.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87o777zxkv.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: 292EC6C4BF X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -5.79 X-Spam-Score: -5.79 X-TUID: I7x1A6v+Dl6M Hi Ihor, Am Montag, den 08. Juli 2024 um 15:56:48 Uhr (+0000) schrieb Ihor Radchenko: > > Or we can make `org-export-as' retain INFO channel when returning the > output. Then, we can make `org-export-to-file' make use of the INFO > channel to decide the file name. This way, there will be no need to > decide the file name before running the parsing. Are you sure that works? org-export-as currently returns a string. It could in addition return the parse-tree in info, plus the smaller parts which need to be exported, but we should not forget, that org-export-as is an inferior function called from org-export-to-file or org-export-to-buffer. But maybe I misunderstand what you mean. Here is what is needed from my perspective: 1. parse the tree of the whole document 2. split the tree up. 3. call the export backend on each of the split parts to generate the string and save it to disk or do whatever is appropriate. For me the most natural way would be that a central function (export-according-to-org-property-list) does the parsing and then call the different backend functions to export according to their rules (the trees being converted in the central function or in backend code). If toplevel functions like org-export-to-file use org-export-as, than org-export-as should only be concerned with generating the string but not with reparsing. Alternatively we can do the conversion to a string in the central function as now with org-export-as, but there still needs to be a mechanism to generate the different files for multipage output and call the export backend on them to save them or whatever. Or what did you have in mind? > For links to external pdfs and co, we have discussed what can be done in > https://list.orgmode.org/orgmode/87a5rpoi4c.fsf@localhost/ > TL;DR: In latex, \href{file.pdf#anchor} works; In web, anchors should > also work with pdfjs. Thanks, I'll check that out. -- Orm