From: Stefan Nobis <email@example.com>
Subject: Re: org-mode export to (latex) PDF
Date: Wed, 14 Jul 2021 21:05:32 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <email@example.com> (Maxim Nikulin's message of "Thu, 15 Jul 2021 00:30:15 +0700")
Maxim Nikulin <firstname.lastname@example.org> writes:
> There are cm-super fonts for at least of 15 years.
There are many tradeoffs in many aspects. No single font pleases
everyone. So you want to say: Your requirements are more
important/common/stylish/whatever that the requirements of other
I do need only latin characters and math (so Latin Modern would
suffice), but still I use different fonts from time to time (like
Libertine, Palatino and others) - and I also mix different fonts (not
all font families provide serif and sans serif and monospace glyphs).
And due to the history of TeX and the structure of font files, there
is no single command to set up all required information to switch all
font families with one command. Usually up to 3-4 command are required
(sometimes more for more advanced requirements) are needed to change
most relevant font information.
Frankly, I'm completely clueless why this should be a problem.
Yes, it may be unfortunate that not all fonts available support all
Unicode glyphs ever invented. But on the other hand: Most of the free
fonts are created by people in their free time and it takes VAST
amounts of time and talent to create nice looking fonts.
I appreciate the many fonts that creative people created to be used for
free. So if all I have to do to use this massive gift is drop a couple
of commands in some or all my documents, I do not complain - I'm
I understand that it sometimes sucks to be forced to use tools that
are created with a massive US centric world view, that not only
focuses on latin characters, but even only respcect ASCII (e.g. even
today quite some systems have problems with german umlauts). But try
to get over it: At least in the case of Emacs, Org, and LaTeX it is
possible and in most cases quite easy to overcome the restrictions
that the default settings may impose.
> Thank you for the hint. Do you think Org should use it by default?
> Are there any caveats?
Yes, unicode-math should be seen as must have for lualatex and xelatex
(if math is used). As far as I know there are no downsides and it
should be part of the default packages (but only for lualatex and
xelatex, not for pdflatex).
> If LuaTeX and XeLaTeX handles Unicode better, is it possible to make
> any of them the default option and to leave pdflatex as a fallback?
That is possible today and you can easily change the LaTeX engine via
global options in your Emacs init.el or via local settings inside Org
> Is it possible to detect lualatex and xelatex in runtime?
At runtime of the LaTeX engine, so execute LaTeX commands depending on
the engine that processes the document containing these commands?
Yes, that is possible. The LaTeX package iftex provides macros to
execute commands based on the running engine (see
> Should some packages for lualatex and xelatex be added to default
> list to minimize user problems and at the same time keeping
> configuration safe? (unicode-math, etc.)
Maybe. I'm currently myself struggling a little bit with a flexible
configuration, that can be used with many different kind of documents
(short notes, larger reports, beamer presentations) and provides all
the extras I like to use. There is no clear best package list for
every use case (in some cases unnecessary loaded packages only waste
time, in other cases, especially with some individual set of package
options, there might be errors in some scenario or another).
> Is it possible to provide reasonable defaults for fonts?
I do not think so. You want Cyrillic. But what about Japanese,
Chinese, Devanagari, Tamil, Arabic etc? I doubt that there exists a
single font that supports all these scripts satisfactorily. Despite
the existence of the Unicode encoding(s), the glyphs and font designs
are still quite complex and demanding even for a single script.
But maybe we could assemble a list of good (enough) fonts for
different languages/scripts and provide a default setup in Org for
LaTeX export, that sets a proper font for the chosen document
Until the next mail...,
next prev parent reply other threads:[~2021-07-14 19:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-10 13:42 org-mode export to (latex) PDF Jean-Christophe Helary
2021-07-10 13:52 ` Juan Manuel Macías
2021-07-10 14:13 ` Jean-Christophe Helary
2021-07-10 14:38 ` Juan Manuel Macías
2021-07-10 14:59 ` Tim Cross
2021-07-10 17:40 ` Juan Manuel Macías
2021-07-12 3:09 ` Tim Cross
2021-07-12 8:15 ` Eric S Fraga
2021-07-10 15:01 ` Jean-Christophe Helary
2021-07-10 16:13 ` Maxim Nikulin
2021-07-10 16:44 ` Stefan Nobis
2021-07-13 16:53 ` Maxim Nikulin
2021-07-13 17:53 ` Juan Manuel Macías
2021-07-14 6:44 ` Stefan Nobis
2021-07-14 17:30 ` Maxim Nikulin
2021-07-14 19:05 ` Stefan Nobis [this message]
2021-07-14 23:26 ` Tim Cross
2021-07-15 12:06 ` Juan Manuel Macías
2021-07-15 17:10 ` Maxim Nikulin
2021-07-15 19:40 ` Juan Manuel Macías
2021-07-16 16:56 ` Maxim Nikulin
2021-07-16 18:34 ` Juan Manuel Macías
2021-07-17 12:35 ` Maxim Nikulin
2021-07-17 14:27 ` Juan Manuel Macías
2021-07-16 9:20 ` Stefan Nobis
2021-07-16 10:38 ` Jean-Christophe Helary
2021-07-16 11:11 ` Stefan Nobis
2021-07-16 5:58 ` Jean-Christophe Helary
2021-07-14 19:29 ` Juan Manuel Macías
2021-07-10 18:43 ` Jonathan McHugh
2021-07-10 19:24 ` Juan Manuel Macías
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).