Juan Manuel Macías writes:
>>> [...] any suggestion for improvement is very welcome [...]
>>
>> This is a bit too out of context. Improvement of what?
>
> I think it is related to the previous paragraph: "I am very interested
> in all possible improvements in babel so that it integrates as best
Sorry for the late reply.
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>> [...] I am very interested in all possible improvements in babel so that
>> it integrates as best as possible with automatically generated files.
>> Among them are the possibility of using BCP47 codes or using a
Juan Manuel Macías writes:
> [...] I am very interested in all possible improvements in babel so that
> it integrates as best as possible with automatically generated files.
> Among them are the possibility of using BCP47 codes or using a language
> (at least basically) without the need for a
Some new information about Babel that may be of interest to the topic of
this thread.
I have received an email from Javier Bezos (whom I know from the
Spanish-speaking TeX users' mailing list), who is the current babel
mantainer, as well as the person responsible for all the improvements
and new
Juan Manuel Macías writes:
>> I am not sure if I like "russian*" idea. May you explain a bit more
>> about how onchar works? What if language characters are intersecting,
>> and not using exactly the same char sets?
>
> Basically, it's like I said above. According to the Babel Manual:
>
>
Ihor Radchenko writes:
> May we explicitly set the needed font around language environments?
>
> Something like
>
> \setfontforrussian
> \selectlanguage{russian}
>
>
> \setfontforbulgarian
> \selectlanguage{bulgarian}
>
There's no need. With \babelfont you can associate a font with a
Juan Manuel Macías writes:
>> Do I understand correctly that onchar=id will not break anything if text
>> is correctly marked with \selectlanguage{}?
>
> To load language features (hyphen rules, captions, etc.) there is no
> problem. But to load a font associated with a language, the font of the
Ihor Radchenko writes:
> Do I understand correctly that onchar=id will not break anything if text
> is correctly marked with \selectlanguage{}?
To load language features (hyphen rules, captions, etc.) there is no
problem. But to load a font associated with a language, the font of the
last
Juan Manuel Macías writes:
> True. Thanks for pointing it out. Indeed, \babelprovide with the
> ochar=id fonts option only makes sense when 1 foreign language = 1
> script. For example, different variants of Greek cannot be combined
> without an explicit switch.
>
> And something like this
Max Nikulin writes:
> Cyrillic letters may appear not only in Russian just as French and
> Spanish use Latin script. So language detection based on symbol code
> points works only for distinct enough languages. Explicit markup may
> still be necessary to switch hyphenation rules, dash styles,
On 05/09/2023 05:22, Juan Manuel Macías wrote:
\usepackage[english,french,spanish,provide*=*]{babel}
but in that line we cannot put Russian with onchar, etc.
Cyrillic letters may appear not only in Russian just as French and
Spanish use Latin script. So language detection based on symbol
Juan Manuel Macías writes:
>> The idea is to allow
>>
>> #+language: Austrian German, Greek
>> as a valid specifier, in addition to
>>
>> #+language: de-at, el
>>
>> Then, across Org, we will make use of the standardized language
>> abbreviations.
>
> In LaTeX, as I mentioned, things are
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>
>>> #+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
Juan Manuel Macías writes:
>> #+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
Thanks for your comments!
Ihor Radchenko writes:
> Juan Manuel Macías 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
Juan Manuel Macías 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
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
Juan Manuel Macías writes:
> ...In any
> case, the fonts issue is the most delicate part. What default fonts to
> add to the list? Here the user's taste or preferences would influence.
Commonly available libre fonts look like a good candidate.
> It must also be taken into account that if one
Ihor Radchenko writes:
> Juan Manuel Macías writes:
>> The idea is to start from a defcustom that is an alist where each element
>> has the structure (script font). There would also be a default script +
>> font, for example ("latin" "Linux Libertine"). At the moment it would
>> only work for
Juan Manuel Macías writes:
> These days I'm working on some experimental code to try to provide Org
> with some sort of fallbacks fonts on LaTeX export. The functionality
> would (for now) be linked to LuaTeX + babel package, since XeTeX,
> although it has the ucharclasses package, is more
The Unicode TeX engines, LuaTeX and XeTeX, have certain features to
apply fonts to scripts (Greek, Cyrillic, Arabic, etc.), without the need
to switch fonts explicitly. But LaTeX does not include any functionality
for loading 'fallback fonts' out of the box. Seeing things from TeX and
LaTeX this
21 matches
Mail list logo