emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: org-mode export to (latex) PDF


From: Maxim Nikulin
Subject: Re: org-mode export to (latex) PDF
Date: Sat, 17 Jul 2021 19:35:57 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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}




reply via email to

[Prev in Thread] Current Thread [Next in Thread]