Inline On Sat, 22 Nov 2025 at 17:20, Ihor Radchenko <[email protected]> wrote:
> Pedro Andres Aranda Gutierrez <[email protected]> writes: > > >> ((nil > >> :fonts > >> ((nil :font "Noto Serif")))) > >> > >> That will result in > >> \babelfont{rm}{Noto Serif} > >> \babelfont{sf}{Noto Serif} > >> \babelfont{tt}{Noto Serif} > >> > >> WDYT? > > > > That would really set my "TeX persona" off-balance. > > Because Noto Serif is neither sans-serif nor teletype. > > There has to be a good reason why TeX has distinguished these three > > families of fonts for the last ??? years. > > I recently found a CHIP SPECIAL Magazine devoted to TeX with a 5'25 inch > > diskette with an MSDOS distribution among my stuff. > > It's from the '80s of the last century and guess what ... back then they > > distinguished between \rm -they translate it to "Normalschrift"-, \sf and > > \tt. > > In other words, for *any* latex document, you basically need to provide > at least 3 fonts. Do I understand it correctly? > I don't need anything if the default fonts in the document class template are what you want and need. But if you want to have your own fonts, then you need to specify the fonts you use in the document. In this case, it is CBP to provide a Serif font for \rm (default), a Sans-Serif font for \sf and a Monotype font for \tt. This way you avoid a lot of headaches. (You call a car a car and not a motorcycle for hopefully understandable reasons...) >> ;; Default mono font, used instead of Source Code Pro for monospaced > >> ("DejaVu Sans Mono" :features "Scale=MatchLowercase" :family "mono") > ; > >> or :family "tt" > >> ;; Default font for hindi, used instead of Source Code Pro and > >> DejaVuSans Mono > >> ("Noto Serif Devanagari" :features "Script=Devanagari" :lang "hindi") > >> ;; Default monospace font for hebrew, used instead of Source Code Pro > >> and DejaVu Sans mono > >> ("Noto Mono Hebrew" :features "Script=Hebew" :lang "hebew" :family > >> "mono"))) > >> > >> Similar for fontspec/polyglossia. > >> > > Using the LaTeX native rm,sf and tt where LaTeX uses them feels easier > when > > you have a LaTeX example and you want to map that to a .dir-locals.el. > > We are not going to get anything sensible if we search for 'Org LaTeX > > exporter font configuration hindi' but it's more probable we get a useful > > answer for 'LaTeX font configuration babel hindi' > > Then, what about > > (setopt > org-latex-babel-font-config > '(;; Default "rm" font > ("Source Code Pro" :features "Scale=MatchLowercase" :family "rm") > ;; Default mono font > ("DejaVu Sans Mono" :features "Scale=MatchLowercase" :family "tt") > ;; Default roman font for hindi, used instead of Source Code Pro > ("Noto Serif Devanagari" :features "Script=Devanagari" :lang "hindi" > :family "rm") > ;; Default monospace font for hebrew, used instead of DejaVu Sans mono > ("Noto Mono Hebrew" :features "Script=Hebew" :lang "hebew" :family > "tt"))) > > >> I believe that the above is much easier to understand for users compared > >> to nested alists we have now. > >> > > But then you lose the structure and it gets much more complex to add > things > > on a language base to a common configuration. > > Fontspec is already alist based, so let's keep that uniformly expressed. > > Nested alist-based values are always hard to work with for users. I know > it from many complaints about capture templates. > > I am not sure if I understand what you mean by more complex. Can you > provide an example that would be simpler using the existing configuration? > > -- > 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
