Hi there are a couple more commits in the feature branch. Against my judgement, but I have included the possibility of using main,sans and mono everywhere. Once again, I don't like that at all, because it diverges from the examples people can find in the Internet and that will be a source of confusion.
More answers inline... Happy New Year, /PA On Sun, 14 Dec 2025 at 13:16, Ihor Radchenko <[email protected]> wrote: > 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. > > I have no problem with flexibility. What I am after is more consistent > value format (without losing flexibility). > > (I also wanted to drop redundant [IMHO] options. But since they are not > as redundant as I though, let's keep) > > >> 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. > That is done. I allow the default features to be a string of comma-separated feature definitions. Internally, it also allows the default features to be a list of strings, each with one feature definition. It mimics the '+' in the default features definition. > >> 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. > > Ok. Let's agree on nested :fallback. I can see how people may prefer > this structure instead of flat. > > However, what is still confusing is "emoji" vs "main"/"sans"/"mono"/"math". > They are in the same place, that can be interpreted as the same > meaning. But it is not the same... > What about > > (("main" :font "TeXGyreSchola" > :fallbacks (("AppleColorEmoji:mode=harf" :script "emoji"))) > They are not strictly the same,OK. But it is always the font family or the missing script that trigger the use of a font. Your example in the current format (("main" :font "TeXGyreSchola" :fallbacks (("emoji" :font "AppleColorEmoji:mode=harf"))) reads as: For the 'main' font family use system font "Tex Gyre Schola" and, if Emacs tells you that there are characters it identifies as "emoji", use font "Apple Color Emoji", which needs to use the HarfBuzz renderer. As I have already explained, it is always a family/script -> font+optional config mapping. It hardly can be more consistent. BTW, look at the new missing font parser in one of the last commits. > >> (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. > > Ok. I find flat structure more natural. But that's *me*. I do not find > nested fallback as a true blocker problem. > > -- > 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> > -- Fragen sind nicht da, um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler "Sagen's Paradeiser" (ORF: Als Radiohören gefährlich war) => write BE! Year 1 of the New Koprocracy
