From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Timothy <orgmode@tec.tecosaur.net>, orgmode <emacs-orgmode@gnu.org>
Subject: Re: Fallback fonts in LaTeX export for non latin scripts
Date: Thu, 31 Aug 2023 11:42:58 +0000 [thread overview]
Message-ID: <877cpb8mkd.fsf@posteo.net> (raw)
In-Reply-To: <87wmxbvd60.fsf@localhost> (Ihor Radchenko's message of "Thu, 31 Aug 2023 08:17:27 +0000")
Ihor Radchenko writes:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>> The idea is to start from a defcustom that is an alist where each element
>> has the structure (script font). There would also be a default script +
>> font, for example ("latin" "Linux Libertine"). At the moment it would
>> only work for the default roman font, but it can be extended to default
>> sans serif, mono, etc.
>
> Are the fonts you have in mind shipped with LuaTeX distribution?
Yes, in fact the complete installation of TeX live includes a wide
catalog of free opentype fonts with good coverage for non-Latin scripts.
Added to that, more free (as in freedom) easily accessible fonts can be
recommended. Even many GNU/Linux distros already include them. In any
case, the fonts issue is the most delicate part. What default fonts to
add to the list? Here the user's taste or preferences would influence.
It must also be taken into account that if one has typographical
scruples, not all fonts match each other. For design purposes, I mean.
The Computer Modern, which is a modern style font (similar to the Didot
or Bodoni), does not usually pair well with (for example) a Garamond,
which is in the Renaissance style. That's why I think the best solution
would be to offer a basic defcustom, based on the purely utilitarian,
and let the user modify or extend it according to their taste,
preferences or convenience.
Another thing to keep in mind is the following. Offering basic
readability based on the unicode scripts means that we rely on scripts
and not languages. For example, the Cyrillic script covers several
languages, as you well know: Russian, Bulgarian, etc. The Latin script
is used for languages as diverse as English or Vietnamese. The choice of
font based on the script is a low-level LuaTeX functionality, that is,
it does not add features specific to each language, such as hyphenation
patterns. This means that long texts in (for example) Cyrillic or Greek
are not justified well because LaTeX does not know how hyphenate them:
https://i.imgur.com/PSja3x2.png
However, this may be sufficient for documents containing words or small
texts in non latin scripts, rather than long texts.
There is another possibility that I am working on in parallel: relying
on languages instead of scripts. This would add both readability and
support for each particular language. There could be two options for the
user: a basic one (the low level one, based on scripts: ensures
readability but the document may not look pretty) and an advanced one,
based on language support. Something like this occurred to me:
#+LaTeX_Header: % !enable-fonts-for ancientgreek russian:Old Standard
arabic
This means: enable default fonts for ancient Greek and Arabic
(associated with Greek and Arabic scripts). For Russian, enable the Old
Standard font (included in TeX live). And in the case of Arabic, enable
'bidi' (bidirectional text). If the user added that line it would be
enough to do the magic. I hope :-)
>> The functionality would not be activated by default. When activated, it
>> also enables LuaTeX as the default LaTeX engine, and on each export a
>> list of non-latin scripts in the buffer is extracted. Perhaps with
>> some code like this, which checks for any non-latin characters:
>>
>> (let ((scripts))
>> (save-excursion
>> (goto-char (point-min))
>> (while
>> (re-search-forward "\\([^\u0000-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
>> (let ((script (aref char-script-table
>> (string-to-char (match-string 1)))))
>> (add-to-list 'scripts script)
>> (setq script-list scripts))))
>> script-list)
>>
>> ?
>>
>> Once the list has been extracted, an ad hoc preamble would be formatted
>> assigning each script the chosen font.
>>
>> WDYT? Do you think this would be a viable path? I think that in a few
>> days I can offer something usable for discussion.
>
> Adding Timothy to CC. His WIP conditional preamble branch looks suitable
> to add the proposed functionality.
Great!
> What will happen if LuaTeX is not installed on the system?
Yes, there should be some kind of warning. Also it's not just LuaTeX,
but certain packages for fonts and multilingual support. The problem is
that the different versions of TeX live cooked in the distros
usually name these packages differently. This is another added problem...
Arch or Gentoo offer a more vanilla TeX live.
> Also, just to double check, is LuaTeX fully compatible to LaTeX? That
> is, if we have an existing org file using LaTeX-specific commands and
> packages, will it work with LuaTeX?
Yes, it is fully compatible, except that LuaLaTeX does not need to load
the fontenc or inputenc packages. LuaTeX is intended to be the natural
replacement for pdfTeX. The latest edition of The LaTeX Companion is
already very focused on LuaTeX. And 90% of the new LaTeX packages that
are uploaded to CTAN only work in LuaLaTeX. One of the essential
advantages of LuaTeX is that TeX now (finally!) has a simple scripting
language. With a little Lua you can achieve very low level things in TeX
that were horribly complicated in 'pure TeX'.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
next prev parent reply other threads:[~2023-08-31 11:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 8:25 Fallback fonts in LaTeX export for non latin scripts Juan Manuel Macías
2023-08-31 8:17 ` Ihor Radchenko
2023-08-31 11:42 ` Juan Manuel Macías [this message]
2023-09-01 9:18 ` Ihor Radchenko
2023-09-02 21:39 ` Juan Manuel Macías
2023-09-03 7:22 ` Ihor Radchenko
2023-09-03 11:05 ` Juan Manuel Macías
2023-09-04 8:09 ` Ihor Radchenko
2023-09-04 22:22 ` Juan Manuel Macías
2023-09-05 10:44 ` Ihor Radchenko
2023-09-20 14:03 ` Juan Manuel Macías
2023-09-21 9:00 ` Ihor Radchenko
2023-09-24 18:24 ` Juan Manuel Macías
2023-09-26 10:37 ` Ihor Radchenko
2023-09-05 16:42 ` Max Nikulin
2023-09-05 18:33 ` Juan Manuel Macías
2023-09-06 9:29 ` Ihor Radchenko
2023-09-06 14:58 ` Juan Manuel Macías
2023-09-07 10:22 ` Ihor Radchenko
2023-09-07 12:04 ` Juan Manuel Macías
2023-09-08 7:42 ` Ihor Radchenko
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=877cpb8mkd.fsf@posteo.net \
--to=maciaschain@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=orgmode@tec.tecosaur.net \
--cc=yantar92@posteo.net \
/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).