From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Maxim Nikulin <manikulin@gmail.com>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: org-mode export to (latex) PDF
Date: Sat, 17 Jul 2021 14:27:29 +0000 [thread overview]
Message-ID: <87h7gtm2we.fsf@posteo.net> (raw)
In-Reply-To: <scuirf$m7o$1@ciao.gmane.io> (Maxim Nikulin's message of "Sat, 17 Jul 2021 19:35:57 +0700")
Hi Maxim,
I think the problem is not the fact that I may be inclined towards book
typesetting but that TeX itself and its workflow is inclined towards
book typesetting. This fact is something that must be taken into account
and that many LaTeX users sometimes forget. The concept of a 'fallback
font' is still something exotic for the TeX working method, despite that
LuaTeX can access TeX primitives using scripting in lua and can achieve
things like that, at the cost of resources. For example, the fontspec
package provides the conditional \IfFontExists{font}{True code}{False
code} which consumes a lot of resources.
Anyway, I would dare to recommend these two possibilities:
a) If you want to define a list of fallback fonts for the LaTeX
process, IMHO should be done org-centric with Elisp (something for
pdfTeX, XeTeX and LuaTeX. I'm afraid this would be a lot of work and too
much cholesterol for Org Mode, though).
b) However, my preference is something that has already been comented in
this thread: add to the documentation (or to Worg web site) a (not too
long) list of recommended fonts for different languages: of course,
fonts that are freely licensed and accessible to everyone. In any
collaborative work in LaTeX I find it's much more simple to share an
easily accessible and free (as in freedom) font than to add a list of
fallback fonts to the documents via code (a true bloat for TeX). The
LaTeX Font Catalogue includes lots of very good quality fonts. For
example, TeX Live includes an excellent font with support for Greek,
Cyrillic and Linguistics: Old Standard, originally designed by prof.
Alexey Kryukov and currently maintained by Robert Alessi:
https://www.ctan.org/pkg/oldstandard (I don't work on Cyrillic and I can
not comment on that aspect: I use this font more for Greek; but it is
often said that Old Standard is one of the best and most documented
options to represent Cyrillic).
Best regards,
Juan Manuel
Maxim Nikulin writes:
> On 17/07/2021 01:34, Juan Manuel Macías wrote:
>> Maxim Nikulin writes:
>>
>>> I think that low level implementation in browser or in some underlying
>>> library is much faster
>>>
>>> <dl>
>>> <dt>LM Roman 12</dt>
>>> <dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
>>> <dt>LM Roman 12, CMU Serif</dt>
>>> <dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
>>> </dl>
>> They are two different scenarios: web publishing and book
>> typesetting
>
> Juan Manuel, it seems you are too inclined to book typesetting. It is
> important case and it should be supported by org. I have repeated two
> times in this thread that there is another case, namely routine quick
> notes. Such documents have another balance concerning time required to
> get acceptable result. TeX takes responsibility for a lot of defaults
> such as what spaces should be added around "=" and what ones around
> right angle bracket. Users do not need to make decisions concerning
> such design details to get accurately typeset equations.
>
> At the age of custom charsets (often 8bit) and encodings the problem
> of multilingual texts was obvious. Unicode and UTF-8 alleviate many
> issues. It happened that Cyrillic is an edge case for Unicode TeX
> engines. Since ~2000 it works out of the box for LaTeX and PdfLaTeX.
> Last years I did not need to adjust config files and regenerate
> formats. Hyphenation, default fonts (OK, "apt install cm-super" to
> avoid rasterized fonts is a bit behind defaults though no manual
> config is required) just work. Each document needs a few universal
> lines to setup Russian. Some users may have specific style files but
> generally source documents are quite portable.
>
> Default fonts for LuaTeX and XeTeX do not include Cyrillic any more.
> Every user have to do a decision which fonts should be used even if
> one does not care concerning particular fonts. It increases
> probability to get a file with font configuration that is specific to
> Mac or Windows.
>
> I do not actively use characters from other Unicode planes, however
> sometimes I do it for fun. Getting them completely missing is less
> preferred than displaying them with low quality font. Specifying all
> fonts requires lengthy config, probably different for LuaTeX and
> XeTeX. At first it is necessary to realize which fonts are available
> for particular glyph. Finally it makes *source* document less
> portable.
>
> "font-family: 'LM Roman 12', 'CMU Serif'" above is a dumb example of
> what I consider relatively high-level config for routine documents
> that do not need to be handcrafted. Unavailable glyph or even font is
> not an error, it just causes lookup of candidates in the following
> items. For TeX maybe it is reasonable to consider fallback to complete
> set of fonts at ones (roman + mono + math) if such combination is
> available.
>
>> If I want to use the GFS Porson as italics from
>> another font, a Didot typeface for example, I can do this:
>
> If it is not a book or at the stage of early draft another scenario is
> possible. Text should just appear in the compiled document, particular
> font does not matter, its choice is postponed since text content has
> higher priority. Minimal setup in invaluable.
>
> At least with minimal examples I faced another issue: characters
> silently disappears, no warning is generated. Adding babel changes it,
> but I still believe that especially for documents with carefully
> chosen fonts. It is a serious hidden error to get "invalid char glyph"
> instead of all missed characters.
>
>> [1] If you want to have fallback fonts, you can also do it in
>> LuaTeX by adding some Lua code:
>> https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex
>
> Would you recommend such code as default for Org? Let's assume that
> some information concerning system fonts are available. I suspect, the
> accepted answer is not fool-proof. In addition, XeLaTeX requires
> something different.
>
> luaotfload provides fallback feature close to what I expect, however
> it is necessary to explicitly specify script that I would prefer to
> avoid. Moreover it significantly increases compilation time. Sometimes
> LuaLaTeX starts to eat CPU with no progress, emoji does not work for
> some reason.
> I am unsure concerning particular "Noto Sans CJK" since several ones
> are available.
>
> \documentclass{article}
> \usepackage{fontspec}
> \usepackage{unicode-math}
> \directlua{luaotfload.add_fallback
> ("seriffallback",
> {
> "Noto Serif CJK SC:mode=harf;script=sc;",
> "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
> })
> }
> % TwemojiMozilla is not shown by viewers, visible in pdftotext
> %"Noto Color Emoji:mode=harf;"
> % or
> %"file:/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf:mode=harf;"
> % </usr/share/fonts/truetype/noto/NotoColorEmoji.ttf
> % ! error: (file /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf)
> (ttf): loca
> % table not found
> % ! ==> Fatal error occurred, no output PDF file produced!
> \setmainfont{CMU Serif}[RawFeature={fallback=seriffallback}]
>
> \directlua{luaotfload.add_fallback
> ("sansfallback",
> {
> "Noto Sans CJK SC:mode=harf;script=sc;",
> "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
> })
> }
> \setsansfont{CMU Sans Serif}[RawFeature={fallback=sansfallback}]
>
> \directlua{luaotfload.add_fallback
> ("monofallback",
> {
> "Noto Sans Mono CJK SC:mode=harf;script=sc;",
> "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
> })
> }
> \setmonofont{CMU Typewriter Text}[RawFeature={fallback=monofallback}]
> \begin{document}
> Test¹ of superscript and ½ fraction.
>
> \textbf{«Теорема».} \emph{Пусть} $α → ∞$ и $\beta \to \infty$.
>
> \verb=Катет= и \textsf{гипотенуза}.
>
> Åå. Text Greek α.
>
> Text utf8x ≠ utf8 and math $utf8x ≠ utf8$.
>
> Randomly chosen examples: "日本", "多喝水", "📞".
>
> \verb=Randomly chosen examples: "日本", "多喝水", "📞".=
> \end{document}
>
>
next prev parent reply other threads:[~2021-07-17 14:28 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
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 [this message]
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
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h7gtm2we.fsf@posteo.net \
--to=maciaschain@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).