HI, On Sat, 17 May 2025 at 18:10, Ihor Radchenko <yanta...@posteo.net> wrote:
> Pedro Andres Aranda Gutierrez <paag...@gmail.com> writes: > > >> I think that we can take inspiration from > >> https://tecosaur.github.io/emacs-config/config.html#font-collections > >> and introduce an idea of font collections. > >> The font collections are named font presets that can be selected as a > >> whole. (and potentially contributed by users) > >> > > In using a variable, I'm following the approach of eglot. > > I do not suggest removing the variable. But I suggest adding a keyword > as an extra option. > OK, I was not sure. Just trying to clarify. I'd like to leave it as a TODO until we have something we can all +/- live with. I am not sure how eglot is relevant to Org mode. > Just an example of a package that has made it to Emacs core. >> Then, we can introduce a #+LATEX_FONT: collection-name > >> keyword so that users can set it per-document. > > > > Wouldn't that mean a lot of user centric configuration. I think we can > > share documents better if we have the document and the .dir-locals.el > > distributed. So it might be more reproducible, because it would not > depend > > so much on the local user configurations. I see a lot of resistance in > > people WRT 2 things: > > 1.- if they have to start creating a "giant" Emacs configuration, vs. > they > > get a zip file with everything and they can start working on the doc > > 2.- if the document header starts to grow too much with too many things > > users need to learn. > > I do not think that .dir-locals.el is the best approach. > .dir-locals.el is just a way of setting a variable for a set of files that reside in a directory. Why is is nice (not perfect) IMHO? Look at the use case "I'm working with other people on an article" 1. I have my org document with figures and included files, etc, and I want to share it with other people. 2. I push the contents of that directory including .dir-locals.el to a git repo (as we do in the development tree of Org mode) 3- When another user installs the document tree, all the settings "are there" and nothing extra needs to be added. * Note that .dir-locals.el would take precedence over any configuration a user might have for personal work, so everybody is synchronised. > What I suggest is the following: > > 1. We introduce org-latex-fontsets variable that will hold pre-defined > set of fonts that we ship with Org mode. > I see a small disadvantage in defining font sets in a generalised way, which I'm experiencing in my multi-OS and which was pointed out earlier. Sometimes fonts are not there. If we follow this path, people may need to install fonts they don't like/use/... If you are working on a document and you define the fonts you want to use for it, it makes more sense. Looking into the future, if and when I'm able to work on this in Beamer, I see that templates include the font definitions in order to create a "corporate" appearance (nasty name, but I hope you understand what I mean). > 2. #+LATEX_FONT: fontset_name will simply choose from that variable. So, > all the users need to export the shared document is Org mode version > that has a given fontset. No downsides compared to .dir-locals.el > I don't see downsides in neither approach. > 3. In addition to using fontsets, I still want to leave an option to > configure fonts directly in Org document. But I'd prefer to avoid dir > locals if we can do the same with keywords. Keywords are more > explicit and more readable (at least, we can make them more readable). > I'm not opposed to that, we can create keywords that manipulate the org-latex-fontspec-config variable and that everybody can see. >> > + :fallback (("emoji" . "Noto Color Emoji:mode=harf") > >> > + ("han" . "Noto Serif CJK JP:") > >> > + ("kana" . "Noto Serif CJK JP:"))) > >>... > >> This sounds like something intersecting polyglossia, or maybe I miss > >> something? > > > > No, this is the fallback mechanism for fontspec only. The "emoji", "han", > > etc. are detected with Juan Manuel's code. > > Then the fallback configuration using the luaotfoffload mechanism is > > generated for the scripts that are detected *and* defined in the font > > configuration. > > I see. So, "emoji", "han", and "kana" are the character sate names > internally used by Emacs, right? In this case, I think that we may also > want some kind of generic fallback; not just for specific character sets > (which is "unicode" charset as per 34.7 Character Sets section of Elisp > manual) > That "fallback" should be covered by the \set...font{}, right? In the beginning of the discussion, we had a report of a directory tree produced by the tree command that could not be printed by default and that #+LATEX_HEADER: \setmonofont{Noto Sans Mono} in the header solved, as long as: #+LTAEX_COMPILER: lualatex. > Maybe we can then use `char-charset' instead of directly querying > `char-script-table'. > I will experiment with that too > > Again, please go through the examples I attached as a ZIP to my message > in > > the hope that they would show what I want to achieve from the document > > layout point of view. > > I did, but I am not sure what to make out of it other than noting that > it already works better than main. > That is nice to hear :-) thanks. I would expect people who are facing the multi-fontset issue to check and help us detect what is still missing in their use case. -- > 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> > An extra-thought for pdflatex. I'm intentionally leaving it out of the conversation, because it is another pair of shoes. My use case doesn't include LaTeX preview FTMB, so it is centered on UTF-8 solutions with (lua|se)latex. That's also the reason why: 1.- I'm calling the control variable(s) after the packages they configure (i.e. fontspec and polyglossia) 2.- The code specifically returns an empty string if (equal compiler "pdflatex") Best, /PA -- Fragen sind nicht da, um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Sagen's Paradeiser, write BE! Year 1 of the New Koprocracy
