Answers inline
Enviado desde mi iPad
> El 30 nov 2025, a las 19:06, Ihor Radchenko <[email protected]> escribió:
>
> Pedro Andres Aranda Gutierrez <[email protected]> writes:
>
>> Are we talking about everything or just about babel configuration?
>
> 1. Everything in terms of the way values are defined
Sorry for trying to provide flexibility… this seems to be the source of most of
your confusion.
> 2. Whether things should be consolidated to a single variable is not
> something I worry *too* much about
>
>> What is too complex in the following config for fontspec?
>>
>> ((org-mode
>> . ((org-latex-multi-lang . "fontspec")
>> (org-latex-fontspec-default-features
>> . (("Scale" . "MatchLowercase")))
>> (org-latex-fontspec-config
>> . (("main" :font "TeXGyreSchola"
>> :fallback (("emoji" . "AppleColorEmoji:mode=harf")))
>> ("sans" :font "TeXGyreHeros")
>> ("mono" :font "DejaVu Sans Mono" :features "Scale=MatchLowercase)
>> ("math" :font "Stix Two Math"))))))
>
> 1. default-features is defined as list of cons, while fontspec features
> is a string while fallback font features is defined with font itself.
> All different! I find this confusing.
OK, we put everything as strings.
> 2. I am not a big fan of nesting :fallback. Some users tend to get lost
> in complex structures (me too). We had discussions with Emacs devs on
> this topic and the general suggestion is sticking to plists. Either
> directly in variables, or, at least, using some macro helpers to set
> complex variables.
In this case, we really need them. This allows us to grow as we go.
Go back to the MWE sent to the list by a user how wanted to add emojis.
>
>> Do you have an idea to make fallback configuration easier?
>
> ((org-mode
> . ((org-latex-multi-lang . "fontspec")
> (org-latex-fontspec-default-features . "Scale=MatchLowercase,...")
Again, OK, we use strings only, no problem
> (org-latex-fontspec-fonts
> . (("TeXGyreSchola" :family "main")
> ("AppleColorEmoji" :family "main" :onchar "emoji" :features
> "mode=harf")
> ("TeXGyreHeros" :family "sans")
For me, fallbacks are subordinate fonts. Having a prop in the fonts that marks
the fallback fonts makes it easier to identify them in the LaTeX export. I
don’t identify them as easily with your proposal. Well, actually I’m confused
by this proposal. Honestly.
> ("DejaVu Sans Mono" :family "mono" :features "Scale=MatchLowercase")
> ("Stix Two Math" :family "math"))))))
These we already have.
>
>>> For other options, things like shorthands, babelhyphenation, digits, etc.
>>> We do not really need to implement them now. :provide is enough. But
>>> others can be added if users ask for them.
>>
>> With this spirit, the fontspec part could have been added ages ago...
>
> extra parameters for babel will be much easier to add.
>
>>>> Yup, it is more appealing to me. Moreover, it has a potential to merge
>>>>> all font-related settings into a single customization. After all, what
>>>>> are chances that you would need different fonts for the same language
>>>>> for babel vs. polyglossia?
>>>>
>>>> Contributions to conferences vs. book chapters, for example. Has happened
>>>> to me.
>>>
>>> Could you elaborate? Your example is a documentclass. How does it have
>>> anything to do wrt babel vs. polyglossia?
>>
>> Of course I can. I have contributed to conferences and book chapters.
>> In some cases you don't need to do anything but use a document class from
>> the submission, throughout the review and at the final submission of the
>> camera ready version of the paper for the proceedings and that is heaven.
>> But I also came across situations where you were asked to include extra
>> customisations taking into account babel and then, when the paper was going
>> to be included in a book, the book's publisher was using polyglossia and
>> they wanted you to use specific font configurations to get the preprints,
>> etc.
>
> That sounds like something suitable as in-buffer option, file-local
> variable or directory-local. It is not like you *always* go for one font
> in polyglossia but other in babel. Or do I miss something?
> (Note that most users do not use directory-locals or file-locals)
>
>>> Imagine a single customization like `org-latex-fonts'.
>>> Users can then
>>> ;; For all compilers
>>> (push '("CMU Serif" :family "sf") org-latex-fonts)
>>> (push '("Noto Sans Mono" :family "tt") org-latex-fonts)
>>> ;; Just for babel
>>> (push '("Noto Serif" :family "sf" :package "babel") org-latex-fonts)
>>> ;; Just for ja + babel
>>> (push '("Noto CJK" :lang "ja" :family "rm" :package "babel")
>>> org-latex-fonts)
>>>
>> I can see why disagree completely...
>> Mainly I can relate better to configurations if I take the language as the
>> base element for the configuration.
>> Because when reading the the LaTeX export, I check the #+LANGUAGE line in
>> Org and start from there.
>> And then because I prefer to have separate configurations coexisting in
>> different variables.
>> If there is a problem and I say I want fontspec, I prefer to inspect
>> org-latex-fontspec-config directly than to skim through a variable which
>> mixes everything and potentially miss the point (for example the languages
>> plist).
>
> Ok. I have no problem with keeping separate variables.
> What is more important for me is the format of values and making sure
> that there is no need to learn a brand new format for each polyglossia
> setting vs. babel setting vs. fontspec setting.
>
>> ...
>> I don't see myself writing that higher level layer, though.
>
> I will be willing to update your code once we decide about more uniform
> value format. I do find it really important.
As new functions that sit on top and feed the variables we already have,
please. So people can decide on which format they want to use.
> But I first want to make sure that we have no critical disagreement
> about what that format would be.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
