From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id IJwKET61k2KnLQAAbAwnHQ (envelope-from ) for ; Sun, 29 May 2022 20:02:38 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 8P7mED61k2J9FgAAauVa8A (envelope-from ) for ; Sun, 29 May 2022 20:02:38 +0200 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 7565033501 for ; Sun, 29 May 2022 20:02:37 +0200 (CEST) Received: from localhost ([::1]:49132 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nvNFM-0004w6-M6 for larch@yhetil.org; Sun, 29 May 2022 14:02:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48698) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvNEG-0004vv-KF for emacs-orgmode@gnu.org; Sun, 29 May 2022 14:01:29 -0400 Received: from mout02.posteo.de ([185.67.36.66]:60101) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvNEE-0004zi-8u for emacs-orgmode@gnu.org; Sun, 29 May 2022 14:01:28 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1DA4F24010B for ; Sun, 29 May 2022 20:01:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1653847281; bh=A5/YDvM2/Mq9KUeaT0t8xl7BrlkgFmON6HEuM75Y9GE=; h=From:To:Cc:Subject:Date:From; b=rNOpyDmICDri0MoJfW3JdEpgDgUYJY6TAjSo47MnJo+3rQKwPZ494CuR+dvtHIt6Z 4nM/iioPLPTVVwvFekjnsLurqBeCDcEjgszUtip+gSb/Qx5fGqnQFyNaLSZe52FOum UTOf/AFVitIE8DuFMFA2vSPljL2UHTxmgS8hvZcGz45ovE1jSN7qoPWQEQQLCMygTI X8wwLr0IjpH8ZPB7H9ohJCp5XRqeHdZKrPaP9DgThPX2V1ucvNa7OGjKa8vrYzXBnH E82jYfSXjwPLn23LcsxidE4CLdSmIf3OKAoProi3SzC0pKOyzkDzaeUVrLuczBXqSE QZnlAWU4bWBqg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4LB5vN3vZPz9rxK; Sun, 29 May 2022 20:01:20 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: orgmode Subject: Re: [tip] org-publish to work with (very) large books References: <87y1yovcip.fsf@posteo.net> <87a6b4pil3.fsf@christianmoe.com> <87a6b4zbew.fsf@localhost> <87tu9cv1yw.fsf@posteo.net> <87y1yntxob.fsf@localhost> <87pmjzmcg6.fsf@posteo.net> <871qwee4vr.fsf@localhost> <877d66vxrc.fsf@posteo.net> <87pmjwwn4t.fsf@localhost> Date: Sun, 29 May 2022 18:01:17 +0000 In-Reply-To: <87pmjwwn4t.fsf@localhost> (Ihor Radchenko's message of "Sun, 29 May 2022 20:15:30 +0800") Message-ID: <87k0a49q1e.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=maciaschain@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_H2=-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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1653847357; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=sp6IVrnBQSI8QiVBAbYuRIRGXkEq3JwqnckIhyTAGow=; b=bMgHup64qcK8Gx0LGxB7z6W6CNQpFJ6IrAQaSEDqb4fTAZ90akN7/Ffk18H48WXZfbbV4p P7Ncs1xKwoRKvL9UifnA9WQ0tDSDhy26hJQCmndJ6g3qq0IgD3fcMuthMBLCkp9BNnp/zk RvgA8UgHN7IGJ0HkdIo7A65C0UeloBwwIQc3WMcAItLqOXhVzC6yQFXI4vHm1JxjQtoXkh 5vkAlg/Xv764KVAqGiQWXUSJ0hPLLZz0HYr5/ahTCaWpVqUTnL7rKgXHwzNJJ+PVcZ1nk5 h0p4Sw323GGnnQxc52VpmMDzffUOIWM3esV25I09EY//N9k6KdFYbYfw3KZ56w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1653847357; a=rsa-sha256; cv=none; b=O2VS/ERLVICfPlrkxvg8jLXFaSc8i1DvbmqEsjpRyeaxe33ZBPpqtE3ZMpZKhyKaP30NvI uhODWN9NmzPcPnsn/z3oc7nqgeezSIJ+ahPoMXPu0UCkDxMEtsFVVshYp8xo8N3hU8SThE +BcYmoDr/cHeIN9KyER2LTssSeUccEVBEnIfExqYCA/Mj53gooOjHiLtOjMDwH0izEw5Dv 82xmWzZeVQTWO7KDCqssqzgoajxE++PtLhiwSTVwGI8xIpAtMrspU31CDTIAxCqk789kAl M1HDy1DProjLljwmQukm3XlSi2kXg5rJQd+Z208ZoktLybxsPIOPFl8Vx2aePQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=rNOpyDmI; 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" X-Migadu-Spam-Score: -8.04 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=rNOpyDmI; 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" X-Migadu-Queue-Id: 7565033501 X-Spam-Score: -8.04 X-Migadu-Scanner: scn0.migadu.com X-TUID: PkQ+UR82UElS Ihor Radchenko writes: > Yet, the information is surprisingly scattered. I was unable to find a > single guide on the available possibilities. Mostly unanswered or > partially answered questions from users. Yes you're right. In addition, what I have been testing is not a panacea either. In general, when it comes to long and complex documents, there is no other solution than to arm yourself with patience, launch asynchronous processes and dedicate yourself to doing another task while LaTeX does its job. And, of course, trust that there are no errors. The only advantage to debugging the code of a LaTeX document is how much you learn about LaTeX and TeX in the process. But many times it is something that can become frustrating, and the log file can be more cryptic than a Sumerian inscription. The cause/effect relationship in LaTeX errors can be the most surrealistic things in the world :-D. Luckily, there's texstackexchange, where the LaTeX core and LaTeX package developers themselves write, which is an endless source of help... > Do you have anything from LuaTeX in mind that could improve the current > ox-latex pdf export when LuaTeX is used as the TeX engine? I've thought about it sometimes, but haven't been able to find anything concrete for Org. LuaLaTeX cares that a well-formed LaTeX document is delivered to it, and Org already does that very well. In LuaTeX you can insert lua code between La(TeX) code. For example: \begin{luacode} local x =3D "foo" local y =3D "bar" tex.print (x .. " and " .. y) \end{luacode} But in Org we have all the power of Babel: Org wins. In LuaTeX you can write functions as pre-process filters, and associate these functions with different callbacks. For example, there is a callback_input_buffer, but we already have something like that in Org, and with a larger scope and not limited to output to LaTeX. In general, the advanced features of LuaTeX are more typographical and micro-typographical in nature, and I guess they are of little use to Org. For example, I recently wrote this function that highlights in red the text that is in a language other than the main language of the document (in my case, Spanish, langid 80). Act low-level on the line node, just before LuaTeX does the line break to create the paragraph: \directlua{ w =3D node.new("whatsit","pdf_literal") w.data =3D "1 0 0 rg" z =3D node.new("whatsit","pdf_literal") z.data =3D "0 g" function other_langs(h,c) for n in node.traverse_id(0,h) do for x in node.traverse_id(node.id("glyph"),n.head) do if x.lang < 80 or x.lang > 80 then local before, after =3D node.copy(w), node.copy(z) n.head =3D node.insert_before(n.head,x,before) n =3D node.insert_after(n,x,after) end end end return h end luatexbase.add_to_callback('post_linebreak_filter', other_langs, 'other_lan= gs') } According to the LuaTeX manual, "TeX=E2=80=99s nodes are represented in Lua= as userdata objects with a variable set of fields". What this function does is simply manipulate the .lang field of the glyph nodes in an hlist node (the line with its components). Functions associated with the post_linebreak_filter callback are very useful and productive, but from a purely typographical point of view. At the pure LaTeX level, LuaLaTeX is not very different from LaTeX. Any LaTeX document, generally speaking, can be compiled with LuaLaTeX, as long as it is in utf8 and does not contain some pdfLaTeX- or XelaTeX-specific commands. Today the compatibility between engines is reasonably good, and more and more packages designed exclusively for LuaTeX are uploaded to CTAN. The TeX ecosystem is notorious for its slowness and conformism, but LuaTeX is meant to be the natural replacement for pdfTeX. Sometime in the uncertain future :-) Best regards, Juan Manuel=20