Thanks for your comments! Ihor Radchenko writes:
> Juan Manuel Macías <maciasch...@posteo.net> 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(Scale=MatchLowercase) >> ;; #+LaTeX_Header: % !enable-fonts-for >> russian:FreeSerif(Numbers=Lowercase,Color=blue) :: 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=ids 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=MatchLowercase > > #+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue 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=Lowercase,Color=blue This last syntax would also be valid to modify the main default fonts: #+latex_font[main]: "FreeSerif" Numbers=Lowercase #+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ías https://juanmanuelmacias.com https://lunotipia.juanmanuelmacias.com https://gnutas.juanmanuelmacias.com