From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id uLQbHcdlS2WEAwAAG6o9tA:P1 (envelope-from ) for ; Wed, 08 Nov 2023 11:41:11 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id uLQbHcdlS2WEAwAAG6o9tA (envelope-from ) for ; Wed, 08 Nov 2023 11:41:11 +0100 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 129503BB18 for ; Wed, 8 Nov 2023 11:41:11 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (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-Seal: i=1; s=key1; d=yhetil.org; t=1699440071; a=rsa-sha256; cv=none; b=mogulMj4IjJPwEINfSVbDXCrGnAU5WaJpb7f6YRuh6IA4kycNXqVxdOfzA4srCE0z7Luw+ PbzjZvusLaBdqP/oCGsF33sAkZotJFyQnzlDNwo1LOnJVOZIF4nBi/ifXdDwkSvL8LRAAA rC4L38e1SsHq4YEmx2Z28vNzeMbEFq6YfOluksCxHx7NOb/NR95lmoHNlVAcsxU8U+vMek 2K6p1oTzCz0VJhfK13RPkrN8aULfFyKokaepKZ1pDo5w9l9fwc1Dyv8uppa8HKRniTt4y1 2zzHyUQ4VBcCj1zsRIgvyl5ZbbwKjBFSNMBb5AkkG/aGvlz32tyuh8oResDOrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1699440071; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=khh4JcfC/1o+1n96tRm9eSz145nZGbaqCoPjt6fozXY=; b=TDeDonpaKvoGb7sm0YjeBgzEVGAfyy0t1tKy66GVf4UnDnz2jjgGU/bTbxfZJbTyG5vvwQ P/92u6/cLEEfKVmB8usHNQQy7g33At4+jGUExAqK65+7EQMH1PgNgbmAb+C6/whlgOO2kl 9EpKZakCYfGnwmcSKMnHCIeCvhg8QxCOxREwDFDG580K4/w06F37V9gNPfzq2Sjv4+zzyu KPWRNXC+wQ0DPSRfe7mg0Y/nNiS2bHukHvmbfUwg3XblUqU8E/NHvzjsc8iQFrtiGv+yv9 KBDJoT/B7rBCT0ZtP7Sp1zDqX44tB1JZoEhd274DOBXXmn6T6TTqQ9pujXIY/A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (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 localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0fyP-0001AT-Cw; Wed, 08 Nov 2023 05:39:49 -0500 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 1r0fyN-0001A5-No for emacs-orgmode@gnu.org; Wed, 08 Nov 2023 05:39:47 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r0fyM-0001Ru-7I for emacs-orgmode@gnu.org; Wed, 08 Nov 2023 05:39:47 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r0fyK-000AMt-2l for emacs-orgmode@gnu.org; Wed, 08 Nov 2023 11:39:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Exporting Hyperlinks ? Date: Wed, 8 Nov 2023 17:39:33 +0700 Message-ID: References: <87y1fc4bog.fsf@localhost> <875y2f43yg.fsf@localhost> <87a5rpoi4c.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird Content-Language: en-US, ru-RU In-Reply-To: Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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-Scanner: mx11.migadu.com X-Spam-Score: 0.40 X-Migadu-Queue-Id: 129503BB18 X-Migadu-Spam-Score: 0.40 X-TUID: XikHzCC/CnS2 On 08/11/2023 15:02, David Masterson wrote: > Max Nikulin writes: > >> On 07/11/2023 19:36, Ihor Radchenko wrote: >>> If \href{file.pdf#anchor} can work, we should indeed use it when >>> publishing org->pdf. >> >> It would be nice to have a LaTeX package that redefines \label to >> generated \hypertarget from its argument. > > This would make it easy to create a PDF "website" that doesn't depend on > a webserver like HTML. A PDF website could easily be put on a USB key > to take with you and access via a mobile phone. This would be secure > because no network interaction. This is the use case I've been working > toward for years. I do not see clear advantages over a set of HTML files with relative links relative links. I am unsure concerning permissions to open sibling files for mobile applications (both HTML and PDF ones). I expect that LaTeX still has issues with generation of PDF files suitable for reflow. With proper CSS styles, HTML are are more flexible in respect to adapting for particular screen size. ePUB is an HTML-based format, but links to other files may be prohibited. >> Ideally, xr-hyper workflow should be supported as well. A downside is >> anchors are not stable and unrelated to labels. > > Stable in the sense that the CUSTOM_ID could be moved to new file? > Could IDs play a roll here? No, I have in mind another case. LaTeX generates anchors like #section.6. If you insert another section, this one becomes #section.7. So all files having doc.pdf#section.6 links must be regenerated. Links based on CUSTOM_ID doc.pdf#export_note continue working even after rearranging structure of the target file. This is especially painful if target file is out of your control. I consider the following link as a stable one: https://www.gnu.org/software/grub/manual/grub/grub.pdf#true When a heading with ID is moved to another file then anyway all files referencing it must be regenerated.