Re: [possible patch] Basic fontspec code for LuaLaTeX and XelaTeX (was "LaTeX export: when is it more useful...")
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: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Max Nikulin writes:
> I would consider structures with named fields (alists or plists) for a
> case of adding some additional settings (Font name? But it is rather
> defcustom than defconst)
>
> ("es" . (:babel "spanishmx" :poliglossia "spanish"
> :poliglossia-variant "mexican")
I was paying more attention to the fontenc issue and I had forgotten to
comment this.
I think your proposal to use a property list makes sense. But I don't
quite see what new settings could be added without overcomplicating
things. Babel in its latest versions has several ways to load languages,
and many new commands to select fonts or associate font families to a
specific language or script. But they don't work with pdfLaTeX, so the
only thing I could think of is to keep the old babel method, valid for
all TeX engines, according to which, if a user puts in an org document:
#+language: es
#+latex_header: \usepackage[foo,AUTO]{babel}
it returns:
\usepackage[foo,spanish]{babel}
which is valid for all flavors of TeX. And I think that this way, as Org
was doing so far, it will satisfy most users.
But given the syntactical variety that babel now has (polyglossia is
simpler), I don't see how all of that could be 'translated' to Org via
Org settings. I think this is one of those cases where it's easier for
the user to just build the LaTeX preamble writing LaTeX code or create a
new 'class' for org-latex-classes. The problem with Org writing the
preamble for the user is that it will never satisfy all users. That is
why I think it is necessary for this 'automatic' preamble to be as basic
and elementary as possible (I, for example, always write the preamble
from scratch or write my own sty files). Otherwise we run the risk of
converting, or wanting to convert, Org into a clone of LaTeX, but less
flexible than LaTeX.
I agree that most Org users (like most Pandoc users) just want to
produce a clean pdf without messing with LaTeX. But if users want to do
more things in LaTeX, they should know some LaTeX, even if they prefer
to use a lightweight markup language as a latex 'interface'. That's why
I think it's great that in Org you can enter arbitrary LaTeX (or html)
code anywhere and at many levels. I think this is the real killer
feature of Org. I don't know if I'm explaining myself... But this
reflection of mine (which, of course, is debatable) would take us
further, and this is not the case here.
Other than that, your idea of using a property list sounds good to me.
What happens is that I do not see a clear advantage (at least in the
short term).
Best regards,
Juan Manuel
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Max Nikulin writes:
> I have tried on Ubuntu-20.04 LTS focal (Latest LTS is 22.04 jammy).
> Without explicit fontenc it may work, but emits a warning
>
> Package babel Warning: No Cyrillic font encoding has been loaded so far.
> (babel)A font encoding should be declared before babel.
> (babel)Default `T2A' encoding will be loaded on input
> line 74.
Yeah, that's something I forgot to mention. The warning is from
russianb.ldf:
-
\ifx\cyrillicencoding\undefined
\if@uni@ode
%\ifdefined\XeTeXrevision
% \edef\cyrillicencoding{EU1}
%\else\ifdefined\luatexversion
% \edef\cyrillicencoding{EU2}
%\fi\fi
\edef\cyrillicencoding{TU}
\else
\edef\cyrillicencoding{T2A}
\fi
\PackageWarning{babel}%
{No Cyrillic font encoding has been loaded so far.\MessageBreak
A font encoding should be declared before babel.\MessageBreak
Default `\cyrillicencoding' encoding will be loaded
}%
\lowercase\expandafter{\expandafter\input\cyrillicencoding enc.def\relax}%
\AtBeginDocument{\@setcyrillicencoding}
\fi
-
But there is no warning in the case of Greek, where the LGR fontencoding
is not explicitly indicated either. In any case, I have commented on
this issue on the Hispanic TeX mailing list, where Javier Bezos (current
Babel maintainer) participates. It would be interesting if he could
clarify this for us...
> Unfortunately in the case of
>
> \usepackage[russian,english]{babel}
>
> \selectlanguage{russian} is required, without it compilation fails with
>
>! LaTeX Error: Command \cyrn unavailable in encoding OT1.
Yes, this is the case of the example that I put in my previous message
(russian as second language). If a explicit babel command is not added,
the T2A fontencoding is not loaded. Therefore, you would have to add a
selectlanguage{russian} or, at a low level,
\fontencoding{T2A}\selectfont
> With \usepackage[T2A]{fontenc} it behaves accordingly to acceptable
> for non-important documents graceful degradation. Text is readable,
> but no hyphenation applied.
>
> So I consider explicit loading of fontenc as more reliable.
Wouldn't it be easier in those cases to just load the fontenc package a
second time:
#+LaTeX_Header: \usepackage[T1,T2A]{fontenc}
According to what Egreg says in this thread
(https://tex.stackexchange.com/a/79112), "The only package that's
allowed to be loaded multiple times is fontenc".
So my logic is as follows: since Org has always loaded fontenc with the T1
option by default, I don't see much point in changing that behavior now
that pdfLaTeX is, so to speak, in retirement. And in any case, the user
can change (now) the fontencoding via the babel commands or by loading
the package a second time. For the record, I'm not opposed to redoing
the patch by adding the features you're proposing. Simply, from my point
of view, I think it's not worth the effort. But it's just my opinion,
and besides, I don't use pdfLaTeX, so I may have a bias here.
Best regards,
Juan Manuel
Re: Fallback fonts in LuaTeX via 'luaotfload.add_fallback' (was "Fontsets")
On 12/07/2022 22:26, Juan Manuel Macías wrote:
Today I discovered that luaotfload included in v. 3.12 a new
experimental function, luaotfload.add_fallback, to be able to add a list
of fallback fonts to a LuaTeX document, at a low level.
...
\documentclass{article}
\usepackage{fontspec}
\directlua{
luaotfload.add_fallback ("fallbacktest",{
"oldstandard:mode=harf;script=grek;color=FF;",
"oldstandard:mode=harf;script=cyrl;color=FF;",
"freeserif:mode=harf;script=arab;color=FF;",
"freeserif:mode=harf;script=dev2;color=FF;",
})}
\setmainfont{latinmodernroman}[RawFeature={fallback=fallbacktest}]
...
The main drawback I've found to this (at least I don't know how to solve
it at the moment) is that the fallback feature cannot be added via
\defaultfontfeatures. That would avoid having to (re)define all the
main/sans/mono/math families.
I agree that defining fallbacks for each font family is inconvenient.
Defining font per script resembles specifying fonts per language in
babel configuration, however fallback should work without explicit
switching of language. I have seen that babel may determine language
from character code points, but I have not tried if it works reliable
and if it affects performance (as it does for fallback fonts).
Maybe I did not read the manual with enough attention, maybe I tried it
with too old version of LuaTeX, but I had a problem with Emoji.
Depending on font such symbols either broke compilation or did not
appear in PDF (accordingly to pdffonts font was embedded, text may be
copied, but PDF viewers displayed blank space).
https://list.orgmode.org/orgmode/scuirf$m7o$1...@ciao.gmane.io/
Maxim Nikulin. Re: org-mode export to (latex) PDF. Sat, 17 Jul 2021
19:35:57 +0700
Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
On 15/07/2022 01:17, Juan Manuel Macías wrote:
Juan Manuel Macías writes:
In any case, I personally think that org-latex-language-alist, as it is
now in this patch, is sufficient.
I agree that the lists should be merged. My point is that with unnamed
fields and variable number of them it would not be possible to extend
this list with additional fields. So additional step with
`make-obsolete-variable' would be required.
By the way, Maxim. I have been doing some tests with pdfLaTeX. I've
known for a while now that it's no longer necessary to load the inputenc
package. But it seems that it is not even necessary to load fontenc with
the encoding of each language.
It looks like a promising feature.
In TeX live 2022 the compilation is correct (I think). It seems that
Babel (or russian/greek.ldf) loads the font encodings according to the
declared languages. From the log:
(/usr/share/texmf-dist/tex/generic/babel/locale/es/babel-spanish.tex)
Interesting, Spanish is not mentioned in your document.
Is this normal or is it a new Babel feature? If it is a new feature, I
can't find it anywhere in the documentation.
I have tried on Ubuntu-20.04 LTS focal (Latest LTS is 22.04 jammy).
Without explicit fontenc it may work, but emits a warning
Package babel Warning: No Cyrillic font encoding has been loaded so far.
(babel)A font encoding should be declared before babel.
(babel)Default `T2A' encoding will be loaded on input
line 74.
Unfortunately in the case of
\usepackage[russian,english]{babel}
\selectlanguage{russian} is required, without it compilation fails with
! LaTeX Error: Command \cyrn unavailable in encoding OT1.
With \usepackage[T2A]{fontenc} it behaves accordingly to acceptable for
non-important documents graceful degradation. Text is readable, but no
hyphenation applied.
So I consider explicit loading of fontenc as more reliable.
If I'm not mistaken, there is now nothing like
an hypothetical 'org-latex-guess-fontenc', and org defaults to the T1
option. If I remember correctly (because I haven't used pdfLaTeX in
ages), the fontenc option for Greek is LGR. And I imagine there will be
many more cases.
That is why I am suggesting a mapping from language to font encoding.
If you or anyone wants to implement that on top of my
patch, that's fine with me.
I do not see a solution "on the top of your patch". Either an additional
mapping should be added or your changes should be overwritten by some
extensible structure. The former is a step backward in respect to the
idea of merging alists, the latter might make unhappy developers of
third party packages.
[SOLVED] (was: exporting timestamps to html, day of the week is not exported.)
>>> "UB" == Uwe Brauer writes:
> Hi
> I only now realized that the day of the week of week in a org timestamp
> is not exported.
(let ((org-time-stamp-custom-formats
'("<%A, %B %d, %Y>" . "<%A, %B %d, %Y %H:%M>"))
(org-display-custom-times 't))
(org-html-export-to-html))
Seems to solve the issue
smime.p7s
Description: S/MIME cryptographic signature
