emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Maxim Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: org-mode export to (latex) PDF
Date: Fri, 16 Jul 2021 00:10:19 +0700	[thread overview]
Message-ID: <scpq5t$92a$1@ciao.gmane.io> (raw)
In-Reply-To: <m15yxcg1hf.fsf@nobis-it.eu>

On 15/07/2021 02:05, Stefan Nobis wrote:
> Maxim Nikulin 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
> people?

I hope, it is possible to make Org export to PDF working out of the box 
for more people. Surprisingly Unicode TeX engines besides alleviating of 
some limitations of earlier implementation bring new burden. I see no 
problem to fix support of Cyrillic in PdfTeX. I have not realized if it 
can be done for LuaTeX or XeTeX despite original expectation that 
support of Unicode means that there should be no problem for any 
character of any script. I started to discuss Russian because it is a 
language for which most of problems are apparent for me. Perhaps a 
similar approach can be used for other scripts.

Before UTF-8 became wide spread on Linux, there were guides how to 
enable support of Cyrillic in e.g. Netscape Navigator. Now such problems 
are forgotten. Is it achievable for TeX?

In CSS it is possible to specify a list of fonts and a glyph is taken 
from the first font where it is present. Despite particular fonts have 
limited coverage, I see wide range of Unicode characters on web pages, 
that is why I am almost sure that system font libraries combine fonts.

Do Unicode TeX engines support such combination of fonts? Is it 
efficient enough to be used by default? Is it possible to write 
reasonably complete config for such purpose? It is preferable to have 
such config as a LaTeX style file, but it may be implemented in Org code 
as well.

There are two quite distinct cases: documents with carefully chosen 
fonts (e.g. a book) and everyday notes when particular font is not so 
important. For the former case a glyph taken from wrong font is a 
serious error. For the latter one, likely even low quality font is 
significantly better than a missed character. I think, both cases should 
be supported however.

> [unicode-math]
>> 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).

Maybe it is possible to scan the document for presence of character from 
specific category, range, etc., to avoid overhead when the package is 
not necessary.

>> Is it possible to detect lualatex and xelatex in runtime?
> Yes, that is possible. The LaTeX package iftex provides macros to
> execute commands based on the running engine (see
> https://www.ctan.org/pkg/iftex?lang=en).

I mean detection if LuaLaTeX or XeLaTeX is usable from Org code. The 
intention is to minimize customization required before successful 
export. Ideally Org should guess reasonable configuration form content 
of the document and available external tools (and maybe freeze it by 
adding properties to the document to make next compilations faster). 
Certainly user should have a way to force fixed values by disabling 
autoconfiguration as a whole or only for particular settings.

>> 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.

I hope, single font is not necessary since other applications can show 
all scripts simultaneously. Of course, my example was not complete, feel 
free to extend it, e.g.

Randomly chosen examples: "日本", "多喝水", "📞".

  parent reply	other threads:[~2021-07-15 17:11 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 [this message]
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

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:

  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='scpq5t$92a$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* 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).