Pedro Andres Aranda Gutierrez <[email protected]> writes:
> Apart from this, I think that we need to provide special handling for
>> #+begin_language <lang> ... #+end_language special blocks to avoid the
>> awkwardness of using different way to specify language for babel vs
>> polyglossia.
>>
>
> That is something that might be interesting to work on.
> IMV, it's the only major dangling point right now. If I find cycles, I will
> try to come up with a proposal.
First of all, I'd like to thank you for continued work on this despite
our different views on some aspects of the patch design. If you find
what I say below unconvincing, I will still appreciate it if you work on
the part about language special block.
> My full explanation for this. The process:
>
> 1. You specify a document class (or default to article) and the class
> template specifies the fonts to use.
> That's LaTeX and IMvvHO one of the nicest features. Do we need to amend
> something that is working?
No.
> 2. You want/need to change the document's appearance
> 2a. You want/need the document typeset in Sans -> we already have a knob
> for that
> 2b. You want/need to use different fonts. Then, if you use Lua/Xe-LaTeX we
> have the mechanism to help you.
I also agree.
What I asked for is improving the mechanism in 2b.
> 3. You have something in your text that is not supported by the current
> fontset. Then, if you use LuaLaTeX, you will need to add fallbacks. To
> identify the fonts that need to be helped with a fallback, the Org exporter
> prints a table of unsupported character groups (aka scripts) you need to
> add through fallbacks.
>
> So specifying a default font in cases 1 and 2a is putting the bandage
> before you are injured -if you allow me the metaphor-. This "bandage" is
> actually 2b and 3.
This part I do not get.
Imagine a user who attempts to export the document containing, say,
emoji. The document is using all defaults (article class, pdflatex).
The user will see the warning.
â›” Warning (ox-latex): PDF file produced with warnings: [unicode character(s)
not supported by pdflatex. Set org-latex-compiler to lualatex or xelatex
instead]
Ok. The user adds #+LATEX_COMPILER: lualatex as advised. Tries again,
and sees
â›” Warning (ox-latex): PDF file produced with errors.
Awkward, but ok. Let's the the user is a bit experienced and knows that
they should look into *Org PDF LaTeX Output* buffer. The user will see
Missing character: There is no 😀 (U+1F600) in font [lmroman10-regular]:+tlig;
Missing character: There is no 😀 (U+1F600) in font [lmroman10-regular]:+tlig;!
Missing character: There is no 😀 (U+1F600) in font [lmroman12-bold]:+tlig;!
Missing character: There is no 😀 (U+1F600) in font [lmroman12-bold]:+tlig;!]
(./bug.aux)
Maybe the user is still advanced enough to guess that they should lookup
the manual, and will see that not only changing compiler is necessary,
but also reading the manual section "Font configuration for LuaLaTeX and
XeLaTeX". There, the user finds about "LATEX_MULTI_LANG". If not
careful, that's the only thing the user finds and they may go ahead
trying
#+LATEX_MULTI_LANG: fontspec
there, resulting in the same error.
Then, they user may find the section describing fontspec configuration
and the example with
#+BEGIN_SRC elisp
(setq-default org-latex-fontspec-config
'(("main" :font "FreeSerif")
("sans" :font "FreeSans")
("mono" :font "Tex Gyre Cursor")
("math" :font "TeX Gyre Termes Math")))
#+END_SRC
there in (note that fallback fonts are described later).
They user may wonder then, why is it possible to set #+LATEX_COMPILER
and #+LATEX_MULTI_LANG via keywords, but the fonts cannot be set via
keywords. That's awkward.
Alternatively, the user may happen to find the paragraph in the manual
talking about lualatex and fallback fonts. The user will see
#+BEGIN_SRC emacs-lisp
(setq-default org-latex-fontspec-config
'(("main"
:font "FreeSerif")
("sans" :font "FreeSans"
:fallback (("emoji" :font "Noto Color Emoji:mode=harf")))
("mono"
:font "FreeMono"
:props "Scale=MatchLowercase")
("math" :font "TeX Gyre Termes Math")))
#+END_SRC
That's fine-ish (despite the same problem with lack of keyword setting),
and user may attempt to copy-paste this to config. But it won't work if
FreeSerif/FreeMono are not installed. So, the user may try to find
another installed font. But, does user really care about main font in
this case? The manual suggest a "fallback", so setting different font
seem to be an overkill. So, the user may try "lmroman10-regular" or
"lmroman-regular" as :font. That will yield
Scripts missing:
For font nullfont!
Missing character: latin
For font nullfont!
And 466 more --- see log file ’bug.log’
So, the user will be forced to use non-default font, unless they take
one more step and also *google* the default latex font.
The above process is far from ideal.
My suggestions about keywords and helping with default font are trying
to make the process smoother for users who know nothing about latex
internals.
>> The rough idea is something like
>> #+LATEX_FONT_MAIN: Font name
>> #+LATEX_FONT_SANS: Font name2
>> #+LATEX_FONT_MONO: Font name3
>> #+LATEX_FONT_MATH: Font name4:<font props>
>>
>> WDYT?
>
> I'm back to lectures and have little or no time for this. In the light of
> the answer above, you will understand that I see little use for your
> proposal, as it might introduce more confusion than actually help. There
> are so many other things in the LaTeX exporter that are only controlled
> with ELisp variables...
I hope that the above step-by-step example clarifies why I am insisting
on further improvements (or what I believe to be improvements) in the
configuration knobs.
--
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>
