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?
>> ;; 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>
