From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 2NXxBbdo9GQzggAA9RJhRA:P1 (envelope-from ) for ; Sun, 03 Sep 2023 13:06:31 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 2NXxBbdo9GQzggAA9RJhRA (envelope-from ) for ; Sun, 03 Sep 2023 13:06:31 +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 B436A316CE for ; Sun, 3 Sep 2023 13:06:30 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=E4zQZfdZ; 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=1693739191; 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=49siOqFR3sgd6KJxWlrgnYqGHT37BYZfBZFkgBTaGv0=; b=VRDs91DPx0cpCnPQJb+kDZ8p3Z0piWKsne0YNxE3u3BULigdzU7AVflVFnNHHk0PTbjShx M0Q6LYx7cuKkqMn8m2k92xMnc9BKChZayyox/eOv4dAQrLjm+SBVRgyDFKZ1Og5lq57pxl 3/pfC664ZnRoEK2LrEjekvCpiE+2XiUbwDTXQ+yGH0AwTZK4BPxKEKdu+05SL8R9+DQmul RpSdNUeqW2KVysGfyq/aMNmbNy656+6acZH2OR/piYMdkbeBEaDrjF/VwZwIlknAhhHq6o cdCKEYFPjgbm/Y/ndZId+yvjhYSAZhXwNfWy3fQ2u097t8qQ5bD8G0Ki0Ro4eQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693739191; a=rsa-sha256; cv=none; b=K58wbgQ6dg3s+3VaA+CJzOrVRi3B7RPXc6Em8PJNj/84LDGuVEYZ0rff9edDgdsciKt3rH tkFYiCfldbXwNyJq/XomJUL1fdlwoUnDufK91g/rK4ojpMzLudQD7KEhbkxk9MhibHgp20 EUBjvpp+tKRoYxX8rB7sM4v4kfoWSUpSTMrm6/hh9smuVGeVhBMq+bDr/vC71mucGw5YKC I75gQ2IIkG2NuxG9RAP8z2xxIxU90A+BNFQUBvQSsm+8Wt3LH4k62v/s8XAcqe0ujTG7is OrDfbLGyArF1IQli4tnYGJfolgGulsvM/AMFCMsPvEQZDdhdeGlV/0dNTPCQVg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=E4zQZfdZ; 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 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qckvD-0001gi-15; Sun, 03 Sep 2023 07:05:39 -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 1qckv7-0001eo-TM for emacs-orgmode@gnu.org; Sun, 03 Sep 2023 07:05:35 -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 1qckv5-0005Mf-1l for emacs-orgmode@gnu.org; Sun, 03 Sep 2023 07:05:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id AC2AB240103 for ; Sun, 3 Sep 2023 13:05:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693739129; bh=J5DjPwuLXbQ9wI0r0PwXFidAFUTwAwdyHit07D9K2pA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=E4zQZfdZoQiGQuopRaYG1EKMQqqu9Y7eQKEQOvkrSRR0igpvieHpPHcmtEqGqRstJ eNy/8Kf6iCgE3YL56baTf2Ly/y23BIyXz9XY5pcTGlomlWVZiJ/yVzckJj1NO0aBo/ pNgEPwfCUCnvpdoSZxdxVvIyjmW7beyml/a/GLbr8qq2wGhj6UESGKovVLYycH/rGq 6bfEPAKYSL/sVWbu4VH2VLMrBmuFhCOGyHef4tk8gamKod98zIufnZNrBwlRalX0O/ JKaPSNXhF7GZLxeQFXrbnUHsJXTyv+3RWfOt79niZrTTLN1oOjs4QbyF5fA91TSbJA SrcojuMrXRIBw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RdppK1X7Dz6tvc; Sun, 3 Sep 2023 13:05:29 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: orgmode , Timothy Subject: Re: Fallback fonts in LaTeX export for non latin scripts In-Reply-To: <87bkejoh4l.fsf@localhost> (Ihor Radchenko's message of "Sun, 03 Sep 2023 07:22:50 +0000") References: <878r9t7x7y.fsf@posteo.net> <87wmxbvd60.fsf@localhost> <877cpb8mkd.fsf@posteo.net> <877cpatfol.fsf@localhost> <878r9ocl17.fsf@posteo.net> <87bkejoh4l.fsf@localhost> Date: Sun, 03 Sep 2023 11:05:27 +0000 Message-ID: <87il8ra554.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_H5=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-Migadu-Scanner: mx2.migadu.com X-Spam-Score: -9.93 X-Migadu-Queue-Id: B436A316CE X-Migadu-Spam-Score: -9.93 X-TUID: cD+G8q7EQpkS Thanks for your comments! Ihor Radchenko writes: > Juan Manuel Mac=C3=ADas writes: > >> Finally I can upload some usable code here, in this case to be able to >> load and manage fonts for languages with non-Latin scripts, through >> babel and fontspec (in LuaLaTeX). It is an attempt to simplify from Org >> the multiform syntax of babel + fontspec. Of course, it is more limited, >> but for regular use I think it may be enough. > > I can see that you did not add defaults for Chinese, which is one of the > problematic scripts for LaTeX. Can you add it? In that first proof of concept I only put a few scripts, less problematic, simply to show the functionality. In CJK languages things are a little more complicated, but it can be done too. The idea is to cover all scripts. In the next code I submit, when I redo the current one, I will try to introduce the case of CJK scripts. >> ;; #+LaTeX_Header: % !enable-fonts-for ancientgreek:Linux Libertine O(Sc= ale=3DMatchLowercase) >> ;; #+LaTeX_Header: % !enable-fonts-for russian:FreeSerif(Numbers=3DLower= case,Color=3Dblue) :: arabic > > I do not like this approach. I'm not a big fan of doing it like that either. I chose this option because I didn't have to define a new keyword and to be less "intrusive" with the actual code. But on the other hand it adds a new syntax. Well, I discard it, to the detriment of an idea that you mention below. > Would be more consistent to allow multiple languages in #+language + > #+LATEX_FONT keyword to optionally specify per-language font: > #+language: ancientgreek russian arabic Of course, this syntax would be the most appropriate and consistent within Org. The problem is LaTeX, specifically babel, and that certain inconsistencies would be created with the rest of the backends. At first some pitfalls come to mind: - The keyword #+language accepts for now only language codes (es, en, el, ar, ru, etc.). Consistency with other backends should be maintained in this regard: ancientgreek is not a valid language code, but a name that only babel understands. If we put something like (a valid language code): #+language: el-polyton this could be translated in babel as polutonikogreek (in the classic syntax, that is, the languages that are loaded in the options of \usepackage[options]{babel}), or, in the new syntax, ancientgreek and polytonicgreek, which are actually two different languages: the first is ancient polytonic Greek and the second modern polytonic Greek. To add more confusion to the matter, in classical babel syntax greek.ancient and greek.polytonic are also supported. But neither of these things can be deduced by simply putting el-polyton, unless breaking the consistency with the other backends. - Added to this is that Babel has two ways to load languages: the classic syntax and the \babelprovide command, which is the one we are interested in here for languages with non-Latin scripts, because the onchar=3Dids fonts property must be added here. And what happens if the user has already defined several languages with babel, using the current procedure: \usepackage[french, english, AUTO]{babel}? Therefore, the least complicated thing, in my opinion, is to leave the syntax of the keyword #+language as it is. It is not necessary for the user to explicitly define secondary non-latin languages. The idea is that Org is responsible for generating the necessary babel code by simply giving a command like enable font for X language. What we are talking about here is ensuring readability using a series of fonts that LaTeX does not load by default, not even LuaLaTeX. And, after all, Org is monolingual: it does not have multilingual support at the moment; that is, there is nothing in Org to switch languages in the middle of the document. What happens is that here we take advantage of the functionality that Babel has to automatically apply a font for a non-Latin language/script, also loading its properties (hyphen rules, captions, etc.). A new keyword #+latex_language could be created, which would understand the babel names, but I think it is unnecessary and would add more complexity. As I said before, defining the necessary fonts would be enough, since my idea in this is a basic practicality to ensure the readability of the documents. And anyone looking for more advanced functions would have to enter LaTeX code explicitly. > #+latex_font[ancientgreek]: "Linux Libertine O" Scale=3DMatchLowercase > > #+latex_font[russian]: "FreeSerif" Numbers=3DLowercase,Color=3Dblue I like this idea, but with the exception that in the two examples you give the user is declaring two fonts for both languages. In my example there was also Arabic, where the default font for the Arabic script is used. Note that each script would have default fonts, which the user can change or not change in their document. A user could simply put something like "enable the default fonts for ancientgreek, russian, malayalam, georgian, chinese". And nothing more. Or choose some other font with or without options for a specific lang. Could be: #+latex_font: ancientgreek, russian, malayalam, sanskrit-devanagari beside: #+latex_font[arabic]: "FreeSerif" Numbers=3DLowercase,Color=3Dblue This last syntax would also be valid to modify the main default fonts: #+latex_font[main]: "FreeSerif" Numbers=3DLowercase #+latex_font[sans]: "some font" #+latex_font[mono]: "some font" #+latex_font[math]: "some font" A practical use case. Suppose a user has a document in Spanish, which includes passages in Greek and Russian. It would be enough to use the Old Standard font (included in TeX live) for the entire document, ensuring consistency: #+latex_header: \usepackage[AUTO]{babel} #+language:es #+latex_font[main,greek,russian]: Old Standard > Also, I think that it may still make sense to have some kind of fallback > font if the specified fonts are not sufficient. For example, when using > emoji symbols, which do not correspond to any language. Yes I agree. That could also be included in the generated preamble. -- Juan Manuel Mac=C3=ADas https://juanmanuelmacias.com https://lunotipia.juanmanuelmacias.com https://gnutas.juanmanuelmacias.com