Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-15 Thread Max Nikulin

On 11/07/2022 21:23, Juan Manuel Macías wrote:

Max Nikulin writes:

 \\ifpdftex
   \\relax
   \\else


Is it the case of latex as the old engine with tex->dvi->ps workflow
besides new XeTeX and LuaTeX? However such engine is not used by Org.


According to the iftex documentation (p. 2):

\ifpdftex, \ifPDFTeX
True if PDFTEX is in use (whether writing PDF or DVI), so this is true
for documents processed with both the latex and pdflatex commands.

So the code says: if pdfTeX is used, do nothing; else, add this (luatex
and xetex related) code.


I have noticed the \iftutex command in the iftex.sty manual. It detects 
XeTeX, LuaTeX, LuaHBTeX, so it should be more suitable here.


At first I had intention to suggest \ifdefined\XeTeXrevision 
\ifdefined\XeTeXrevision you mentioned in
Re [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia 
languages alists. Fri, 15 Jul 2022 14:36:07 +. 
https://list.orgmode.org/878rou30ko@posteo.net


P.S. I do not remember if CMU Serif, etc. family (that is Computer 
Modern Unicode) has been mentioned in this thread. It is not installed 
but default, but allows to generate documents with traditional TeX fonts.




Re: fontsets (was: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful..."))

2022-07-11 Thread Timothy
Hi Juan,

> When you talk about fontset, I understand that you mean lists of
> families with their options that you have previously defined, is that
> right?

Yep, so in my config’s implementation I have an alist of fontset names and
individual fonts. For something part of org-mode itself, we’d probably want to
add a format level to this, something like:

┌
│ ((fontset-name .
│   ((serif .
│ ((pdflatex . "\\usepackage{myserif}")
│  (lualatex . "etc.")
│  (html . "and so on")))
│(sans ...) ... ))
│ (another-fontset ...) ...)
└

Actually, now that I think of it maybe it would be better to seperate out the
fontsets and fots, e.g.

┌
│ ;; Fonts
│ ((myfonta . ((pdflatex . "etc.") (lualatex ...) (html ...) ...))
│  (myfontb ...)
│  ...)
│ ;; Fontsets
│ ((myfontset .
│   ((sans . myfonta)
│(serif . myfontb)
│(mono . myfontc)
│...))
│  ...)
└

> In any case, I think it would also be nice if the user could add only
> one family for roman, sans, mono or math, if he/she prefers it that way.
> Something like:
>
> #+options: rmfont:Minion Pro

Sure. There’s another bit of functionality in my config which I think is worth
noting, you can add a -sans/-serif/-mono suffix to the fontset name to override
the default body text font.

All the best,
Timothy


Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Max Nikulin

On 11/07/2022 21:23, Juan Manuel Macías wrote:

Max Nikulin writes:

\ifpdftex, \ifPDFTeX
True if PDFTEX is in use (whether writing PDF or DVI), so this is true
for documents processed with both the latex and pdflatex commands.

So the code says: if pdfTeX is used, do nothing; else, add this (luatex
and xetex related) code.


Likely it is not relevant to Org, but for the following document

\documentclass{article}
\usepackage{ifpdf}
\begin{document}
\ifpdf PDF\else Not PDF\fi
\end{document}

I get "PDF" when I use pdflatex and "Not PDF" when I run latex.


Yes, that is true, sorry. I don't work with math. But:

\setmathrm{⟨font name⟩}
\setmathsf{⟨font name⟩}
\setmathtt{⟨font name⟩}
\setboldmathrm{⟨font name⟩}

Now, weren't we talking about ensuring a minimum readability out of the
box in case non-Latin characters are used?


Mathematical expressions may contain non-latin characters as well. 
\text{} may be a rescue (anyway such expression usually appears poorly 
formatted), but if I remember correctly, it is better to use math mode 
commands to get accurate spaces in accordance to TeX design. So math 
fonts with wider coverage is somewhere close to minimum readability.





Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Juan Manuel Macías
Timothy writes:

> As an illustrative example, if I include this in one of my documents and 
> create
> a PDF:
> ┌
> │ #+options: fontset:biolinum
> └
>
> Then I’ll get text with:
> ⁃ libertine roman as the serif font
> ⁃ biolinum as the serif, and default, font
> ⁃ source code pro as the mono font
> ⁃ newtxmath as the maths font
>
> Similarly I can do `fontset:noto' and you can guess what that does.

I think it's a very good idea to be able to add the options using
#+options:..., forgive the redundancy :-)

When you talk about fontset, I understand that you mean lists of
families with their options that you have previously defined, is that
right? 

In any case, I think it would also be nice if the user could add only
one family for roman, sans, mono or math, if he/she prefers it that way.
Something like:

#+options: rmfont:Minion Pro

Best regards,

Juan Manuel 



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Juan Manuel Macías
Max Nikulin writes:

>>   \\relax
>>   \\else
>
> Is it the case of latex as the old engine with tex->dvi->ps workflow
> besides new XeTeX and LuaTeX? However such engine is not used by Org.

According to the iftex documentation (p. 2):

\ifpdftex, \ifPDFTeX
True if PDFTEX is in use (whether writing PDF or DVI), so this is true
for documents processed with both the latex and pdflatex commands.

So the code says: if pdfTeX is used, do nothing; else, add this (luatex
and xetex related) code.

>>   \\usepackage{fontspec}
>>   \\usepackage{unicode-math}
>>   \\defaultfontfeatures{Scale=MatchLowercase}
>>   \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>>   \\setmainfont{%s}
>>   \\setsansfont{%s}
>>   \\setmonofont{%s}
>>   \\fi
>>   org-latex-fontspec-mainfont
>>   org-latex-fontspec-sansfont
>>   org-latex-fontspec-monofont)
>
> Too many variables to my taste. It can be single property list. If I
> remember correctly, changing of mainfont requires setting of a
> consistent font for mathematics, so more options may be required.

Yes, that is true, sorry. I don't work with math. But:

\setmathrm{⟨font name⟩}
\setmathsf{⟨font name⟩}
\setmathtt{⟨font name⟩}
\setboldmathrm{⟨font name⟩}

Now, weren't we talking about ensuring a minimum readability out of the
box in case non-Latin characters are used? I assume that by default the
mathematical notation is assured, although the default mathematical font
may be typographically or aesthetically incompatible with the chosen
text fonts. For example, Computer Modern and FreeSerif are antipodes in
design. The first is a Didotian font and the second is a times style
typeface. But I think that what is sought here is that certain (non
latin) glyphs are represented in the PDF, beyond other typographical or
aesthetic considerations. My idea here is that a) the user who doesn't
want to mess with all these issues has a minimum of readability out of
the box; b) the user who wants to have full control over the fontspec
options has the possibility to do so; c) the user who does not want Org
to write the preamble under any circumstances (that is, people like me),
has the possibility of continuing doing so.

> Finally, default value may be language-dependent or alternative font
> set may be activated when non-latin characters are detected in the
> document.

If I had to choose between both options, I would prefer the second one.
But don't you think it would be much simpler to ensure the readability
of non-Latin characters (at least in a high percentage) by means of
three default fonts (roman, sans, mono), and let the user who needs
another font be able to choose it freely, simply by changing the value
of those variables? Generally, users working with a certain non-Latin
script are already used to using a certain font (I mean, they haven't
suddenly teleported into the digital world), and they know perfectly
well which fonts to use for their use case and their language. And for
those users who are a bit more lost, a list of recommended fonts can be
added to the documentation (many of which are already installed on their
system or are included with TeX live).

The other more extreme possibility is to default to GNU unifont
(https://unifoundry.com/unifont/index.html). With this font I think the
readability of almost everything is ensured (although it is a horrible
font, but it is not the case here). Or Google's Noto Fonts (but I don't
remember now what license terms those fonts are under).

Best regards,

Juan Manuel 



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Timothy
Hi Ihor & co.,

> As I recall, Timothy has been working on simplifying preamble
> generation. If we do not put unnecessary packages into preamble,
> compilation will be significantly faster.
>
> If Timothy can come up with a patch some time soon, I’d prefer to have a
> more targeted preamble. Otherwise, the proposed approach is the way to
> go.

Yep, I’ve got something in my config currently that intercepts LaTeX preamble
creation and generates it only the fly from a list of detected features based on
the exported document and capability providers. I use this in my config to
automatically switch to LuaLaTeX when necessary and use pdfLaTeX the rest of the
time.

This should also be able to be able clean up some of the currently kludgy
preamble modifications like in oc-csl.el.

This has been on the back-burner for a while (I want to implement this is a way
that can be generalised across all output backends), but I’ll see if I can make
some progress and hopefully have a preliminary patch set in the next few weeks.

Lastly, there’s something extra I want to note. If we talk about including a
font customisation, I’d advocate for supporting font sets, not fonts. Once
again, this is something I’m a fan of from my config, and this could potentially
be supported across multiple export formats.

As an illustrative example, if I include this in one of my documents and create
a PDF:
┌
│ #+options: fontset:biolinum
└

Then I’ll get text with:
⁃ libertine roman as the serif font
⁃ biolinum as the serif, and default, font
⁃ source code pro as the mono font
⁃ newtxmath as the maths font

Similarly I can do `fontset:noto' and you can guess what that does.

All the best,
Timothy


Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Juan Manuel Macías
Tim Cross writes:

> Juan, if I understand your proposal correctly, I think your on the right
> track. It sounds like what you are proposing would have almost no impact
> on basic users like me, but would allow those with more demanding
> requirements to adjust without too much effort. I originally raised the
> question regarding what would need to change with the switch to uatex to
> ensure that we do actually get things positioned to enable people to
> exploit the benefits and not just switch out one tool for another which
> only appears to be a little slower. I think what you are suggesting
> addresses that concern. 

Tim, thanks a lot for your interesting comments.

Indeed, I think that LuaTeX is a good direction for the TeX ecosystem.
And it seems that the third edition of The LaTeX Companion makes the way
clear:

https://tex.stackexchange.com/questions/612573/the-latex-companion-3rd-edition/612586

Of course, LuaTeX is still a kind of cyborg (someone defined it that
funny way :-). TeX has not been rewritten here from scratch (that would
have been preferable), but LuaTeX has brought, in my opinion, two
revolutionary things: being able to control TeX internals from a
scripting language as light and minimalist as Lua (which drastically
influences the creation of packages every increasingly powerful and
sophisticated for all areas) and the fact that TeX is finally native
unicode. From the latter, of course, follows the fact that the user is
no longer dependent on Computer Modern and can choose whatever font he
wants, just like in any other modern textual software, from a simple
word processor to more advanced tools like InDesign-style dtp programs.

Even though pdfTeX was light years ahead of InDesign, this simple
operation of choosing the font or font family has always been horribly
difficult in LaTeX. There were a few packages that incorporated specific
font families (Times, Fourier, etc.), but if one wanted to manually
install Adobe Garamond in pdfTeX ---for example---, the process became
absurdly long and cumbersome. Now in LuaLaTeX and XelaTeX that is as
simple as doing it in libreoffice.

Of course, TeX and LaTeX have always had their historical typeface,
Computer Modern, which is almost like one of their distinguishing
features. This extreme reliance on Computer Modern has often given
people who don't use LaTeX the misconception that any document made in
LaTeX always looks the same.

Despite the fact that I feel enormous admiration for Donald Knuth, and I
believe that to a greater or lesser extent many or almost all of us are
indebted to him, I believe that the design of Computer Modern is not
good and has many legibility problems (imho), especially legibility
screen (precisely because of its Didot-style design, with such a marked
contrast between the strokes). Since there is a thread on this list
about accessibility, it's worth remembering that Computer Modern isn't
exactly an easy-to-read font. Of course, you have to put things in their
historical context. When TeX was created there was nothing similar to
what we have today in fonts, there was no truetype or opentype, there
were no free fonts either. It was all to do. And, naturally, if one
creates "a new typesetting system intended for the creation of beautiful
books" (Texbook page 5, Preface), it would be somewhat strange if this
new typesetting system were born without a typeface to show the world
the excellence of TeX. For that reason Knuth created Metafont and the
Computer Modern font.

Now with LuaTeX and XeTeX choosing the font, any font, is easy, fast and
trivial.

> but as I said, I know nothing

I don't think so. Knowing (or not knowing) things or facts (after all, all
of this is just "data") is not the same as being wise and speaking
wisely :-)

Best regards,

Juan Manuel 



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Max Nikulin

On 11/07/2022 03:23, Juan Manuel Macías wrote:


3. A variable (something like 'org-latex-fontspec-default-configuration') would 
return something like this:

(format
  \\usepackage{iftex}
  \\ifpdftex


I like the idea of unified preamble suitable for pdflatex and lualatex. 
For pdftex \usepackage[...]{fontenc} line may be added here.



  \\relax
  \\else


Is it the case of latex as the old engine with tex->dvi->ps workflow 
besides new XeTeX and LuaTeX? However such engine is not used by Org.



  \\usepackage{fontspec}
  \\usepackage{unicode-math}
  \\defaultfontfeatures{Scale=MatchLowercase}
  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
  \\setmainfont{%s}
  \\setsansfont{%s}
  \\setmonofont{%s}
  \\fi
  org-latex-fontspec-mainfont
  org-latex-fontspec-sansfont
  org-latex-fontspec-monofont)


Too many variables to my taste. It can be single property list. If I 
remember correctly, changing of mainfont requires setting of a 
consistent font for mathematics, so more options may be required.


ox-latex has some code searching for e.g. \usepackage[...]{inputenc} in 
the current configuration to avoid adding of extra copy. It would be 
great to have something similar for fontspec commands. I guess, it is 
harder to detect, since per-language font configuration may be required 
as babel options.


Finally, default value may be language-dependent or alternative font set 
may be activated when non-latin characters are detected in the document.





Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Juan Manuel Macías
Juan Manuel Macías writes:

> By the way, although I've already commented on it in some post in the
> parent thread, i think this package I wrote might be useful for doing a
> quick visual test of a font (including opentype features test), using
> org-latex-preview (compiling with LuaTeX). It can be done on any font
> marked in dired. There are three options: insert arbitrary characters,
> insert the Unicode code of the characters, or display a specimen of the
> font. The default specimen is in the file specimen.tex, which can be
> edited to add examples and languages.
>
> Some screenshots:
>
> https://i.imgur.com/3faKSjA.png
>
> https://i.imgur.com/OJfUcO9.png

Sorry, I forgot the link:

https://gitlab.com/maciaschain/org-font-spec-preview



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Juan Manuel Macías
Stefan Nobis writes:

> Juan Manuel Macías  writes:
>
>> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
>> (I would vote for nil by default).
>
> I would vote to activate this by default.

I voted nil because of the available fonts issue. But I think what you
say below is a good idea, so it could be activated by default

>> (format
>>  \\usepackage{iftex}
>>  \\ifpdftex
>>  \\relax
>>  \\else
>>  \\usepackage{fontspec}
>>  \\usepackage{unicode-math}
>>  \\defaultfontfeatures{Scale=MatchLowercase}
>>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>>  \\setmainfont{%s}
>>  \\setsansfont{%s}
>>  \\setmonofont{%s}
>>  \\fi
>>  org-latex-fontspec-mainfont
>>  org-latex-fontspec-sansfont
>>  org-latex-fontspec-monofont)
>
> I would prefer to make it easier to stick with the default fonts. So
> only add the font selection commands (including defaultfontfeatures)
> when the font variables are non-nil. If no font has been explicitly
> chosen, just use the default (in case of lualatex Latin Modern).
>
> For me, it does not matter whether the 'org-latex-fontspec-*'
> variables have a default of nil or set to the Free* fonts or something
> else. For my configuration, I would set these variable to nil in order
> to get the LaTeX default fonts and would like to go with the default
> preamble of Org and then add to this on a per document basis.
>
> This way, the whole configuration would be a little more composable, I
> think.

Sounds like a good idea and I agree. If I understand correctly, if the
sans, roman, and mono font variables (or any of them) are non-nil,
enable font selection. Otherwise, leave the default Latin Modern font.

By the way, although I've already commented on it in some post in the
parent thread, i think this package I wrote might be useful for doing a
quick visual test of a font (including opentype features test), using
org-latex-preview (compiling with LuaTeX). It can be done on any font
marked in dired. There are three options: insert arbitrary characters,
insert the Unicode code of the characters, or display a specimen of the
font. The default specimen is in the file specimen.tex, which can be
edited to add examples and languages.

Some screenshots:

https://i.imgur.com/3faKSjA.png

https://i.imgur.com/OJfUcO9.png

To create font tables I often use the LaTeX package unicodefonttable. An
example of usage within Org:

#+header: :headers '("\\usepackage{unicodefonttable}")
#+begin_src latex :imagemagick yes :iminoptions -density 600 :results raw 
:results file :file -2256080143431736233.png
\displayfonttable*[range-start=1F00,range-end=1FFE]{Old Standard}
\displayfonttable*[range-start=0600,range-end=06FF]{FreeSerif}
#+end_src

A screenshot:

https://i.imgur.com/Fwsg7bb.png

Maybe it could also be added as an emergency fallback font GNU Unifont:

https://unifoundry.com/

Best regards,

Juan Manuel 



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Stefan Nobis
Juan Manuel Macías  writes:

> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).

I would vote to activate this by default.

> (format
>  \\usepackage{iftex}
>  \\ifpdftex
>  \\relax
>  \\else
>  \\usepackage{fontspec}
>  \\usepackage{unicode-math}
>  \\defaultfontfeatures{Scale=MatchLowercase}
>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>  \\setmainfont{%s}
>  \\setsansfont{%s}
>  \\setmonofont{%s}
>  \\fi
>  org-latex-fontspec-mainfont
>  org-latex-fontspec-sansfont
>  org-latex-fontspec-monofont)

I would prefer to make it easier to stick with the default fonts. So
only add the font selection commands (including defaultfontfeatures)
when the font variables are non-nil. If no font has been explicitly
chosen, just use the default (in case of lualatex Latin Modern).

For me, it does not matter whether the 'org-latex-fontspec-*'
variables have a default of nil or set to the Free* fonts or something
else. For my configuration, I would set these variable to nil in order
to get the LaTeX default fonts and would like to go with the default
preamble of Org and then add to this on a per document basis.

This way, the whole configuration would be a little more composable, I
think.

-- 
Until the next mail...,
Stefan.



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-11 Thread Stefan Nobis
Ihor Radchenko  writes:

> But can someone check if Free* fonts are available on Windows and
> Mac by default?

I just checked TeXLive (on MacOS, but should be the same on all
systems): The Free* fonts are part of TeXLive as truetype and as
opentype versions (and partly in other formats).

For Windows I remember vaguely that some prefer the MikTeX
distribution (TeXLive is also available for Windows and has the same
fonts as everywhere). A short search shows that the gnu-freefont set
is also availabe for MikTeX, but I currently don't know whether it
will be installed with a default MikTeX installation.

> This unified preamble approach is consistent with what we do now.
> However, our currently used large preambles will slow down compilation.

Not that much. The time consuming packages like tikz/pgf (used by
beamer) are not part of out default preamble. There is not that much
speed to gain (all times are for a single lualatex run):

1) Only hyperref loaded, no other packages:
   0.46s user 0.10s system 99% cpu 0.568 total

2) Complete default preamble for lualatex:
   0.48s user 0.14s system 99% cpu 0.623 total

3) The same as above, but with babel and mathtools:
   0.51s user 0.15s system 99% cpu 0.673 total

4) And another variant (same as before, but package caption instead of
   capt-of):
   0.53s user 0.14s system 98% cpu 0.674 total

5) Back to our default preamble, but adding fontspec:
   0.60s user 0.14s system 99% cpu 0.748 total

6) With fontspec, unicode-math, babel, mathtools, caption:
   1.02s user 0.19s system 99% cpu 1.220 total

Therefore most of out default packages (and even the addition of
babel) does not change much for the speed of compilation. I don't
think its worth to try to further optimize this default preamble.

Adding fontspec and especially unicode-math adds quite some time, so
maybe its worth to take care to only add these if necessary (only for
lualatex/xelatex and only if e.g. if a font has been selected or math
seems to be used in the document).

And, by the way, our preamble is neither large nor complex. For my
LaTeX documents, the preamble is usually *much* larger. :)


Here is the test file for the default preamble (but with mathtools
instead of amsmath and with babel; test run 3):

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---


Here is the test file for the last run with all extra packages:

--8<---cut here---start->8---

% Intended LaTeX compiler: lualatex
\documentclass{article}
\usepackage{fontspec}
\usepackage[english, safe=none, math=normal]{babel}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage[warnings-off={mathtools-colon,mathtools-overbracket}]{unicode-math}
\usepackage{caption}
\usepackage{hyperref}
\date{\today}
\title{Test Document}
\hypersetup{
 pdfcreator={Emacs 28.1 (Org mode 9.5.4)},
 pdflang={English}}
\begin{document}
This is a short test document.
\end{document}

--8<---cut here---end--->8---



-- 
Until the next mail...,
Stefan.



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-10 Thread Greg Minshall
Juan Manuel,

> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).

i just wanted to check: the "nil" case is for those of us who just want
it to work "out of the box"?

and, in the non-nil case, it would be up to the user to use "fontspec",
or whatever?

cheers, Greg



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-10 Thread Ihor Radchenko
Juan Manuel Macías  writes:

> Considering some discussions in the parent thread, I think maybe it
> wouldn't hurt to ensure a minimal preamble when the output is compiled
> with LuaLaTeX or XelaTeX, so that some very basic fontspec configuration
> is loaded to be able to read PDFs in non-Latin scripts.

+1

> But before proposing the patch directly, I'd like to discuss its
> structure. I think (IMHO) that a certain balance should be ensured
> between a) users who don't want to mess with fontspec and want something
> more out-of-the-box and b) users who prefer to be in control when
> compiling with LuaTeX and XeTeX.
>
> I think maybe it would be nice to let LaTeX do the work, via a
> conditional from the iftex package (idea taken from pandoc).
>
> The structure of the patch could be this:
>
> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).

Does it mean that unicode text (like це or 这个) will not be exported by default?

> 2. There would be three variables for the default fonts: roman, sans and
> mono. By default, the FreeSerif, FreeSans and FreeMono fonts could be
> set as default value, since they are very ubiquitous and have a very
> good coverage for non-Latin scripts.

+1
But can someone check if Free* fonts are available on Windows and Mac by
default? If not, can we distribute these fonts with Org?

> 3. A variable (something like 'org-latex-fontspec-default-configuration') 
> would return something like this:
>
> (format
>  \\usepackage{iftex}
>  \\ifpdftex
>  \\relax
>  \\else
>  \\usepackage{fontspec}
>  \\usepackage{unicode-math}
>  \\defaultfontfeatures{Scale=MatchLowercase}
>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>  \\setmainfont{%s}
>  \\setsansfont{%s}
>  \\setmonofont{%s}
>  \\fi
>  org-latex-fontspec-mainfont
>  org-latex-fontspec-sansfont
>  org-latex-fontspec-monofont)
>
> (and this string would be added at some point to org-latex-make-preamble)

Makes sense. Though I'd rather use format-spec instead to allow
arbitrary order of variable formatting.

> 4. Conclusion: I think the good thing about letting LaTeX do the
> conditional work with iftex is that it saves us less invasive code on
> our end. I also think that other more complex approaches, such as
> searching for the fonts present in the system and adding them according
> to the document scripts, would lead us to a completely slippery slope.
> Of course, a list of recommended free-licensed fonts could be included
> in the documentation.
>
> WDYT?

This unified preamble approach is consistent with what we do now.
However, our currently used large preambles will slow down compilation.

As I recall, Timothy has been working on simplifying preamble
generation. If we do not put unnecessary packages into preamble,
compilation will be significantly faster.

If Timothy can come up with a patch some time soon, I'd prefer to have a
more targeted preamble. Otherwise, the proposed approach is the way to
go.

Best,
Ihor



Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-10 Thread Tim Cross


Juan Manuel Macías  writes:

> Considering some discussions in the parent thread, I think maybe it
> wouldn't hurt to ensure a minimal preamble when the output is compiled
> with LuaLaTeX or XelaTeX, so that some very basic fontspec configuration
> is loaded to be able to read PDFs in non-Latin scripts.
>
> But before proposing the patch directly, I'd like to discuss its
> structure. I think (IMHO) that a certain balance should be ensured
> between a) users who don't want to mess with fontspec and want something
> more out-of-the-box and b) users who prefer to be in control when
> compiling with LuaTeX and XeTeX.
>
> I think maybe it would be nice to let LaTeX do the work, via a
> conditional from the iftex package (idea taken from pandoc).
>
> The structure of the patch could be this:
>
> 1. There could be a defcustom, something like 'org-latex-use-fontspec'
> (I would vote for nil by default).
>
> 2. There would be three variables for the default fonts: roman, sans and
> mono. By default, the FreeSerif, FreeSans and FreeMono fonts could be
> set as default value, since they are very ubiquitous and have a very
> good coverage for non-Latin scripts.
>
> 3. A variable (something like 'org-latex-fontspec-default-configuration') 
> would return something like this:
>
> (format
>  \\usepackage{iftex}
>  \\ifpdftex
>  \\relax
>  \\else
>  \\usepackage{fontspec}
>  \\usepackage{unicode-math}
>  \\defaultfontfeatures{Scale=MatchLowercase}
>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>  \\setmainfont{%s}
>  \\setsansfont{%s}
>  \\setmonofont{%s}
>  \\fi
>  org-latex-fontspec-mainfont
>  org-latex-fontspec-sansfont
>  org-latex-fontspec-monofont)
>
> (and this string would be added at some point to org-latex-make-preamble)
>
> 4. Conclusion: I think the good thing about letting LaTeX do the
> conditional work with iftex is that it saves us less invasive code on
> our end. I also think that other more complex approaches, such as
> searching for the fonts present in the system and adding them according
> to the document scripts, would lead us to a completely slippery slope.
> Of course, a list of recommended free-licensed fonts could be included
> in the documentation.
>
> WDYT?
>

I'll prefix this by being very clear that I'm so out of my depth, I know
nothing! I'm an Australian who lives on the worlds largest
island. Despite being a country where 1/4 people have at least one
parent born in a non-english speaking country, Australia is at this time
monolingual. As a consequence, I've never had to deal with fonts other
than trying to select one which 'looks nice'. This tends to be something
I leave to Latex as my aesthetic skills are only slightly better than my
language skills!

Like many, I have had to struggle with fonts at one time or another -
typically, it was with respect to type formatting of mathematics/logic
and it was what got me using Latex originally (30+ years ago). I rarely
need to do this now.

So, my perspective on this is fairly basic.

   - I think the move to luatex is important for org, especially given
 the rise of packages which use/need it

   - It seems like luatex could make org easier to use for those who do
 need support for other non-latin languages and especially for those
 who need to work in multiple languages.

   - For many simpler people like me, I just want it to work. When I
 export to a PDF document, I want to continue to have people say
 "Wow, that is a good looking document, what is your secret" and I
 can reply, "Don't use MS Office!". I don't want to mess with
 selecting fonts, defining font specs etc. I want good defaults.

  - For many people, it seems fonts are a very personal and important
component and they want the power to manage them at a lower
level. Therefore, support for this user is as important as my use
case. They need to be able to adapt their document to their
preferred fonts without having to code elisp or low level latex/tex.

Juan, if I understand your proposal correctly, I think your on the right
track. It sounds like what you are proposing would have almost no impact
on basic users like me, but would allow those with more demanding
requirements to adjust without too much effort. I originally raised the
question regarding what would need to change with the switch to uatex to
ensure that we do actually get things positioned to enable people to
exploit the benefits and not just switch out one tool for another which
only appears to be a little slower. I think what you are suggesting
addresses that concern. 

but as I said, I know nothing






Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-10 Thread Juan Manuel Macías
Sorry, I forgot to add quotes :-)  "\\usepackage{iftex}...\\fi"

Juan Manuel Macías writes:

> (format
>  \\usepackage{iftex}
>  \\ifpdftex
>  \\relax
>  \\else
>  \\usepackage{fontspec}
>  \\usepackage{unicode-math}
>  \\defaultfontfeatures{Scale=MatchLowercase}
>  \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
>  \\setmainfont{%s}
>  \\setsansfont{%s}
>  \\setmonofont{%s}
>  \\fi
>  org-latex-fontspec-mainfont
>  org-latex-fontspec-sansfont
>  org-latex-fontspec-monofont)



[possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")

2022-07-10 Thread Juan Manuel Macías
Considering some discussions in the parent thread, I think maybe it
wouldn't hurt to ensure a minimal preamble when the output is compiled
with LuaLaTeX or XelaTeX, so that some very basic fontspec configuration
is loaded to be able to read PDFs in non-Latin scripts.

But before proposing the patch directly, I'd like to discuss its
structure. I think (IMHO) that a certain balance should be ensured
between a) users who don't want to mess with fontspec and want something
more out-of-the-box and b) users who prefer to be in control when
compiling with LuaTeX and XeTeX.

I think maybe it would be nice to let LaTeX do the work, via a
conditional from the iftex package (idea taken from pandoc).

The structure of the patch could be this:

1. There could be a defcustom, something like 'org-latex-use-fontspec'
(I would vote for nil by default).

2. There would be three variables for the default fonts: roman, sans and
mono. By default, the FreeSerif, FreeSans and FreeMono fonts could be
set as default value, since they are very ubiquitous and have a very
good coverage for non-Latin scripts.

3. A variable (something like 'org-latex-fontspec-default-configuration') would 
return something like this:

(format
 \\usepackage{iftex}
 \\ifpdftex
 \\relax
 \\else
 \\usepackage{fontspec}
 \\usepackage{unicode-math}
 \\defaultfontfeatures{Scale=MatchLowercase}
 \\defaultfontfeatures[\\rmfamily]{Ligatures=TeX}
 \\setmainfont{%s}
 \\setsansfont{%s}
 \\setmonofont{%s}
 \\fi
 org-latex-fontspec-mainfont
 org-latex-fontspec-sansfont
 org-latex-fontspec-monofont)

(and this string would be added at some point to org-latex-make-preamble)

4. Conclusion: I think the good thing about letting LaTeX do the
conditional work with iftex is that it saves us less invasive code on
our end. I also think that other more complex approaches, such as
searching for the fonts present in the system and adding them according
to the document scripts, would lead us to a completely slippery slope.
Of course, a list of recommended free-licensed fonts could be included
in the documentation.

WDYT?

Best regards,

Juan Manuel