PS: the current language names used in the configuration are Org's. I feel
it is more in line with
#+LANGUAGE: el-polyton de
to have an
("el-polyton" ... ) alistOn Sat, 22 Nov 2025 at 16:58, Pedro Andres Aranda Gutierrez < [email protected]> wrote: > Answers inline > > On Sat, 22 Nov 2025 at 14:12, Ihor Radchenko <[email protected]> wrote: > >> Pedro Andres Aranda Gutierrez <[email protected]> writes: >> >> >> There are differences, but I'd like to figure out if we really need to >> >> map every single feature of polyglossia/babel into variables exposed to >> >> Org users. >> > >> > And don't remember people coming from LaTeX. If we put too many >> > restrictions to them, they will not use this at all. >> > And that <IMvvHO>would be a pity<(IMvvHO> >> >> Point taken. So, the goal should be _both_ people coming from LaTeX and >> people unfamiliar with LaTeX. In other words, a simplified configuration >> + extended configuration. >> >> >> As of now, for me, it looks like we do not need a special configuration >> >> for default fonts for babel. Instead, we can simply use fontspec >> >> defaults (babel falls back to them by default). >> > >> > <WARNING>Most examples you can look up will not follow this >> > pattern.</WARNING> >> > That is (at the very least) confusing for most people... >> > An example: >> > https://github.com/latex3/babel/blob/main/samples/lua-polygreek.tex >> > Further examples: the rest of that directory (and I have not looked at >> the >> > official polyglossia examples) >> > >> > <IMvvHO>I have kept close to what is out there, not to confuse >> > people</IMvvHO>. >> >> That and other examples use something like >> \babelfont{rm}{Old Standard} >> to set the default font. Got your point. >> >> >> Further, :tag in polyglossia does not seem necessary. We should be >> >> perfectly fine if we do not expose this feature to Org users. >> > >> > Since that is secondary, I could concede, leaving it commented as a >> FIXME >> > (FFS) . >> > I wouldn't complete rule it out in the (perfect) future. >> >> Ok. I find this one particularly confusing, especially because it is a >> layer on top of Org's own language naming. If someone finds this feature >> necessary, can re-consider. >> >> >> Finally, it looks like we do not have to force users specifying >> >> individual fonts for each rm/sf/tt script for babel. We can provide >> >> default per-language font just as we do for polyglossia. >> > >> > Here you may have misunderstood. >> > You do not need the full spectrum, OK. But you still need to >> differenciate: >> > Not providing the "sf" font and then using \textsf{} or setting the >> default >> > font to \sfdefault will be cause of trouble, either as a non-intended >> > presentation, missing characters or as errors in the compilation >> process. >> > Thus, allowing for explicitly setting rm/sf/tt is needed. >> > >> > I'd be more cautious here. >> >> No disagreement here. I did not say that we should not allow explicitly >> setting rm/ss/tt. What I meant is allowing setting a single default font >> in babel. Something like >> >> ((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. > > > fontspec-config provides the font overrides for lualatex and xelatex. >> > Additionally lualatex can do fallbacks. >> > It can be used with babel and polyglossia. But it is not a _MUST_ and we >> > shouldn't impose it. >> >> Ok. Fair. >> >> >> 2. polyglossia-config and babel-config will provide the same set >> >> features - per-language font settings, optionally also specifying >> >> language + script combinations. Then, the value formats for >> >> polyglossia-config and babel-config can be made the same, reducing >> >> the learning barrier. >> >> >> > My main concern with your understanding here is that you seem to be >> ruling >> > out a babel-only or a polyglossia only configuration. >> > >> > What I could try is to explore using the same >> > ((<lang> >> > . (('rm' :font '<fname>' ...) >> > ('sf' :font '<fname>' ...)))) >> > scheme for polyglossia and babel and then see which properties are >> common >> > and which are not. >> > My earnest concern here is that people could try to add babel-specific >> > properties in a polyglossia configuration or viceversa. >> > But if you could live with that, it would be OK for me. >> >> Understand your point. You want to allow independent configuration >> only for polyglossia/babel/fontspec. >> >> I am not against that, however, I'd like to make the variable value >> format simpler, and more uniform across the backends. >> >> What I have in mind is something like >> >> (setopt >> org-latex-babel-font-config >> '(;; Default font for everything: main, sans, mono... >> ("Source Code Pro" :features "Scale=MatchLowercase") >> > Once and for all, no. we need the mapping for rm, sf and tt to fonts that > comply to their "nature". > >> ;; 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' > >> 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. > >> -- >> 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> >> > > /PA > > -- > 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 > > -- 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
