Hi Ihor,
consider the following examples:
#+begin_src org
,#+OPTIONS: toc:nil
,#+LATEX_COMPILER: lualatex
,#+LATEX_HEADER: \setmainfont{DejaVu Serif}
We only need to change the _main_ class to get a /viable/ document as long
as we
don't use the *other* families.
,# Local variables:
,# org-latex-classes: (("article" "\\documentclass[a4paper,12pt]{article}"))
,# end:
#+end_src
and
#+begin_src org
,#+OPTIONS: toc:nil
,#+LATEX_COMPILER: lualatex
,#+LATEX_HEADER: \setsansfont{DejaVu Sans}
,#+LATEX_HEADER: \renewcommand*{\familydefault}{\sfdefault}
We only need to assign the _sans_ font family a valid system font to get a
/viable/ document as long as we don't use the *other* families.
,# Local variables:
,# org-latex-classes: (("article" "\\documentclass[a4paper,12pt]{article}"))
,# end:
#+end_src
Try them out.
After trying them out, do you not feel that the extra burden on the user by
_mandating_ that *all four* font families be defined is unacceptable?
/PA
On Fri, 26 Dec 2025 at 09:14, Ihor Radchenko <[email protected]> wrote:
> Pedro Andres Aranda Gutierrez <[email protected]> writes:
>
> >> What about adding the following to Font configuration for LuaLaTeX and
> >> XeLaTeX:
> >>
> >> Remember that LaTeX requires setting 4 fonts to reliably render all
> >> parts of the document: =main= (roman) font used for main text,
> =sans=
> >> (sans serif) font often used for headings and captions, =mono=
> >> (monospace) font used for code snippets and verbatim text, and
> =math=
> >> font used in equations. If you are using non-ASCII characters in
> >> main text/headings/code/equations, make sure to specify appropriate
> >> fonts that can render those characters.
> >>
> >
> > It is already there for fontspec:
> >
> > ~fontspec~ distinguishes between the Roman (=main=), the Sans-Serif
> > (=sans=) and the Monotype (=mono=) font, and can provide fall-backs for
> > character sets (for example, ~emoji~, ~han~, ~kana~, etc.) that are
> > not provided by the fonts you use in your document. See
> > [[#lualatex-fontspec]] for more details. Note that ~fontspec~ does
> > not work with =pdflatex= compiler. For =pdflatex=, you can control
> > fonts using font packages (cf. [[#pdflatex-fonts]]).
> >
> > We recommend using =lualatex= or =xelatex= for reliable non-Latin
> > language support and using Unicode fonts that include
> > the non-Latin character sets you use to simplify the configuration
> > (cf. [[#nonpdflatex-fonts]]).
>
> Reading the existing paragraph, I cannot see that specifying Roman,
> Sans-Serif, and Monotype is mandatory. It also says nothing about math.
> It may come natural to you, but for me, as someone not familiar with all
> the LaTeX machinery, even the difference between Roman and Sans is elusive.
>
> >> >> Where I do have slight problem is "emoji" (or other script
> >> >> name). Consider
> >> >>
> >> >> ("math" :font "Stix Two Math")
> >> >> ("main" :font "FreeSerif"
> >> >> :fallbacks (("mathematical" "Noto Serif")))
> >> >
> >> > That has never happened to me. I have seen 'symbol', but never
> >> > mathematical.
> >> > And maths are quite well covered with \setmathfont and
> >> > \usepackage{unicode-math}.
> >> > If and when we have to cross that bridge, we will see.
> >>
> >> Ok. I will agree with your position here for now, but make sure to do
> >> RFC to hear from others after we finalize other aspects of the variable
> >> value formats.
> >
> > Reading through your slight objection, I don't think I fully grasp what
> > your reservations are. We are mapping a string from a message produced by
> > Emacs to a system font when there are indications that this string point
> to
> > a Unicode glyph range not included in the system font we use in the
> > document.
>
> My problem is that
> ("<some name>" ...)
> and :fallbacks (("<some name>" ...))
> look similar and may be confused.
> That's all.
> I have no issue with explanation in the manual, I have an issue with
> practical implementation - no matter how good the value is documented,
> if the structure leaves space for confusion, I will eventually forget,
> will have to reach to the manual every time, and get annoyed.
> That's why I insist on consistent value formats that are (1) easy to
> remember (that is - not changing as much as possible between
> fontspec/babel/polyglossia); (2) clear enough to understand the meaning
> *without* having to go to the manual/docstring every single time I need
> to write the values.
>
> >> (setq-default org-latex-fontspec-config
> >> ...
> >> #+BEGIN_SRC elisp
> >> ("mono" :font "TeX Gyre Cursor"
> >> :features ("Color=blue"
> >> "Scale=MatchLowercase"))
> >> ...
> >>
> >> As discussed, we should also allow
> >> ("mono" :font "TeX Gyre Cursor:Color=blue,Scale=MatchLowercase")
> >>
> >
> > If you continue reading in the manual:
> > ...
> > :features ("Color=blue"
> > "Scale=MatchLowercase"))
> > ...
> > :features "Color=blue,Scale=MatchLowercase")
> > #+END_SRC
>
> I think I was not clear enough. I did read the manual. What I want is 3
> ways to specify features:
>
> :font "Name:features"
> :font "Name" :features "..."
> :font "Name" :features ("..." "...")
>
> There are currently only 2 for fontspec. I want all 3, so that
> everything is consistent between fontspec/babel/polyglossia.
>
> >> You can declare the fallback fonts for missing scripts in the
> >> ~:fallback~ property based on this list. It consists of an
> >> associative list that maps the script names as detected by Emacs
> with
> >> their fallback system font and optional extra configuration.
> >>
> >> We can probably point to
> >> M-: (char-table-extra-slot char-script-table 0) RET
> >> as a way to consult what scripts are known by Emacs
> >> (I took it from 34.6 Character Properties in Elisp manual)
> >
> > Isn't it much easier to tell people too look for the script list
> generated
> > by the exporter and starting from there?
> > And this is what my Emacs shows both in the minibuffer and in the
> > *Messages* window:
> > [image: image.png]
> > Where are the emojis there? I would be extremely confused. Whereas if I
> see
> > a messages telling me which scripts are detected during the export
> process,
> > I have a (more solid) base to start investigating.
>
> Good point. Then, I would provide some examples of the script names.
>
> >> :fallback (("emoji" . "Noto Color Emoji:mode=harf")
> >> ("han" . "Noto Serif CJK JP")
> >> ("kana" . "Noto Serif CJK JP")))
> >> ...
> >> I do not like that fallback is an alist, while the main config is using
> >> plists.
> >>
> >> What about
> >>
> >> '(("main"
> >> :font "TeX Gyre Termes"
> >> :fallback (("emoji" :font "Noto Color Emoji:mode=harf")
> >> ("han" :font "Noto Serif CJK JP")
> >> ("kana" :font "Noto Serif CJK JP")))
> >> ...
> >>
> >
> > Would you be more happy if we allowed both?
>
> Yes. But I would still prefer my variant in the manuals.
>
> >> . ((org-latex-polyglossia-font-config
> >> . (("en" :font "FreeSerif")
> >> ("en" :variant "sf" :font "FreeSans")
> >> ("en" :variant "tt" :font "FreeMono")
> >> ("he" :font "Hadasim CLM"
> >> :props "Script=Hebrew")
> >> ...
> >> Let's drop ("en" :font "FreeSerif"). It implies :variant "rm", but we
> >> should recommend specifying :variant explicitly. Maybe even make
> >> :variant mandatory.
> >
> > Once again, if you read through the manual, you will see:
> >
> > 2. ~:variant~: a string for the font variant (e.g. ~sf~ for Sans
> > Serif, ~tt~ for Mono, ~rm~ for Roman aka. Serif). The variants
> > are [[https://en.wikibooks.org/wiki/LaTeX/Fonts][the two-letter
> > codes used in LaTeX for the different font families]]. When no
> > variant is indicated, it is assumed that the serif font family
> > (~:variant "rm"~) is implied. It is recommended that you always add
> > variant =rm= *explicitly*.
> >
> > Isn't that enough?
>
> No, it is not. I am very confused why you need main/sans/mono for
> fontspec but rm/sf/tt for babel/polyglossia. I would like to use
> consistent names everywhere (be it main/sans/mono or rm/sf/tt)
> The reason is the same - if I write a fontspec config and want to
> copy/paste it to, say, polyglossia, I am sure I will forget to change
> main/sans/mono to rm/sf/tt, will get errors, and get confused.
>
> > Also, what about
> >> (("en" "main" :font "FreeSerif")
> >> ("en" "sans" :font "FreeSans")
> >> ("en" "mono" :font "FreeMono")
> >> ("he" "main" :font "Hadasim CLM" :features "Script=Hebrew")
> >> ...)
> >
> > That looks really confusing to me...
>
> I am looking at fontspec vs. polyglossia/babel configs:
>
> ("mono" :font "TeX Gyre Cursor")
> ("en" :font "TeX Gyre Cursor" :variant "mono")
>
> and I feel that I will get confused by where to put "mono" when.
>
> Let's go another way...
>
> What about using full plist?
>
> (:family "mono" :font "TeX Gyre Cursor")
> (:lang "en" :family "mono" :font "TeX Gyre Cursor")
>
> This second looks much easier to understand (without having to reach to
> the manual every time), IMHO.
>
> >> 2. We replace "sf"/"rm"/"tt" with "main"/"sans"/"mono" - this is to
> >> reduce confusion about latex terminology. (We may still allow
> >> "sf"/"rm"/"tt" as aliases, for people familiar with LaTeX)
> >
> > My gut feeling is that this will confuse people who browse through the
> > suggested bibliography.
> > If we want to be strict, it would be allowing aliases "main","sans" and
> > "mono" and not the other way round.
>
> No problem. For me, the most important thing is to be able to copy/paste
> and edit between fontspec/babel/polyglossia configs without getting
> unexpected surprises.
>
> > 3. :props -> :features. As discussed, I want the same things to be named
> >> with the same keywords.
> >>
> >> Same for babel (:props -> :features, "lang" "main/sans/mono")
> >>
> > Once again, the fontspec references speak about font features while the
> > polyglossia/babel sources mostly use properties.
> > Introducing new terminology will confuse people.
> >
> > With a ton of reservations, but I would introduce :features as an alias
> to
> > :props.
>
> But aren't fontspec's features and polyglossia/babel properties the same
> thing?
> If they are, I am ok with an alias.
>
> --
> 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
