From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: orgmode <emacs-orgmode@gnu.org>,
Timothy <orgmode@tec.tecosaur.net>,
Max Nikulin <manikulin@gmail.com>
Subject: Re: Fallback fonts in LaTeX export for non latin scripts
Date: Sun, 24 Sep 2023 18:24:55 +0000 [thread overview]
Message-ID: <87ttrj77k8.fsf@posteo.net> (raw)
In-Reply-To: <87edir294v.fsf@localhost> (Ihor Radchenko's message of "Thu, 21 Sep 2023 09:00:48 +0000")
Sorry for the late reply.
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> 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 prior declaration. These are
>> things already done, but there are others that can still be improved.
>
> Do I understand correctly that babel, in future, may be able to
> auto-detect more languages without explicitly declaring them?
Correct. Indeed, it is possible to use the command \foreignlanguage or
its environment version (otherlanguage*) without having to
declare the language previously. I would say that \foreignlanguage is a
command that covers a high percentage of use cases in multilingual
documents, since it is intended for short fragments of text and only
loads the hyphen rules of the host language.
>> [...] 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 as
possible with automatically generated files[...]"
>> Among the things I agree on is name issue. I am unifying the dice in the
>> CLDR as much as possible, and already, in fact, it is very advanced:
>>
>> https://latex3.github.io/babel/guides/locale-naming.html
>
> AFAIU, the relevant quote is
>
> They are taken from the CLDR. Wherever the CLDR doesn’t provide a name
> (eg, “Medieval Latin”), the pattern followed in practice for other names
> is applied, namely, use the ‘natural’ form in English: medievallatin.
> They should be preferably based on the description field in the IANA
> registry (eg, polytonicgreek), although some simplifications can be
> necessary, because some names are “too” descriptive. See also the
> templates for about 500 locales already available. As a secondary
> source, Glottolog is used, too. (Wikipedia articles can be taken as a
> complementary but unreliable source, and its information must be
> verified; on the other hand, internal data, like this one, is useful for
> both names and tags.)
>
> I am not very sure about "some simplifications" referring to IANA. I
> guess it is referring to language names in
> https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
> like "Puter idiom of Romansh".
>
> From Org perspective, verbosity is not a primary concern as long as we
> provide #+language: completion support. Probably, we should favor names
> that are more likely known (or can be easily found) by the language
> users. IANA and https://glottolog.org/ look like good sources we can
> link to.
>
> We can also provide multiple language name variants though I don't see a
> need to bother unless we get user requests to do such thing.
I agree. I even think it would be a good point to also include the
vernacular name of each language.
By the way, Javier has also told me that he is going to consider the
'onchar=ids fonts' issue related to the case of several languages that
use the same script (already discussed here in past messages).
Best regards,
Juan Manuel
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
next prev parent reply other threads:[~2023-09-24 18:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 8:25 Fallback fonts in LaTeX export for non latin scripts Juan Manuel Macías
2023-08-31 8:17 ` Ihor Radchenko
2023-08-31 11:42 ` Juan Manuel Macías
2023-09-01 9:18 ` Ihor Radchenko
2023-09-02 21:39 ` Juan Manuel Macías
2023-09-03 7:22 ` Ihor Radchenko
2023-09-03 11:05 ` Juan Manuel Macías
2023-09-04 8:09 ` Ihor Radchenko
2023-09-04 22:22 ` Juan Manuel Macías
2023-09-05 10:44 ` Ihor Radchenko
2023-09-20 14:03 ` Juan Manuel Macías
2023-09-21 9:00 ` Ihor Radchenko
2023-09-24 18:24 ` Juan Manuel Macías [this message]
2023-09-26 10:37 ` Ihor Radchenko
2023-09-05 16:42 ` Max Nikulin
2023-09-05 18:33 ` Juan Manuel Macías
2023-09-06 9:29 ` Ihor Radchenko
2023-09-06 14:58 ` Juan Manuel Macías
2023-09-07 10:22 ` Ihor Radchenko
2023-09-07 12:04 ` Juan Manuel Macías
2023-09-08 7:42 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ttrj77k8.fsf@posteo.net \
--to=maciaschain@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=orgmode@tec.tecosaur.net \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).