Huang Jing <[email protected]> writes: >> How does it play with babel and polyglossia? > > It's not mentioned in the documents of xeCJK and luatex-ja, however I > believe they do work together. From my limited testing, when loaded as > packages, xeCJK and luatex-ja does no localization, thus relying on > babel. However they will override the font settings by babel, which is > totally acceptable.
That actually depends. If the user of Org mode customizes fonts, it may be a surprise when xeCJK/luatex-ja override the fonts. So, we might only load these packages conditionally, when no font of explicitly selected. Or maybe we simply put font settings _after_ xeCJK/luatex-ja is loaded. > 1. Under XeTeX and LuaTeX, xeCJK and luatex-ja will setup font support > according to the platform (operating system) detected, and activate > font, kinsoku, line-breaking support. They will not change the > \baselineskip. > > 2. When ctex is being used, it will also configure correct > \baselineskip (from the default 12pt to 16pt). It will also try to > support pdfTeX. > > 3. Localization support provided by babel. > > So it's actually necessary to load babel when not using the document > classes provided. It's safer to load babel first though. Note that babel also provides rules for typography. So, xeCJK/lualatex-ja do step onto babel a bit. But, as you said, they basically add missing typographical rules, so it might be reasonable. > Neither xeCJK nor luatex-ja is necessary for font configuration when > babel is being used. Since babel only support Chinese and Japanese on > LuaTeX and XeTeX with OTF support, the CJK font can be loaded the same > way as latin fonts. See > https://latex3.github.io/babel/guides/locale-chinese.html. > However babel is hardly ever used in Chinese or Japanese community, > since their support is so, primitive. For example it does not add > xkanjiskip between latin and CJK characters. Here's a relevant > discussion on relying on babel for localization in the ctex community: > https://github.com/CTeX-org/ctex-kit/issues/626#issuecomment-1147428749. My understanding from this is that we (1) always want to load xeCJK for Chinese documents (what about luatex?); (2) always want to load luatex-ja for Japanese (what about xetex?). >> > For the \setCJK...font declaration, I can provide a wrapper in LaTeX >> > if needed, compatible with XeTeX, LuaTeX and probabily other >> > engines. You will need xeCJK for this control sequence while other >> > engines will not compile because it is provided by the xeCJK package. >> > Under other engines, there are different control sequences used for >> > font configuration (i.e., under LuaTeX thus luatex-ja, you use >> > \set...jfont). Could you expand on "other engines will not compile"? How does it fit to "compatible with XeTeX, LuaTeX, and probably other engines"? (Note that inclusion or not inclusion of xeCJK can be controlled by us - we know which compiler is used for export during export and can conditionally include it on Elisp level) >> Could you provide more details about these commands? > > Equivalents to \setCJK...font provided by luatex-ja are documented in > English here: > https://mirrors.ctan.org/macros/luatex/generic/luatexja/doc/luatexja-en.pdf > Search for ``Tabel 1: Commands of luatexja-fontspec'' in that > PDF. They are provided by luatexja-fontspec, which autoloads luatexja > and fontspec. Ok. \setmainjfont, \setsansjfont, and \setmonojfont seems to be of interest. They are direct equivalents of \setCJKmainfont, \setCJKsansfont, and \setCJKmonofont. This is probably only relevant when using bare bones fontspec or polyglossia to set fonts. When using babel, it probably makes sense to keep using \babelfont[chinese]{rm}{...} > luatexja also patches LaTeX2e's NFSS2, adding CJK font > support. However unless there's a specific reason we shouldn't use > that in Org export results. That sounds concerning. What are the potential consequences? > I'm currently having my mid-term exams, so I'll be able to work on > this after Tuesday. No problem. I think Pedro wanted the whole thing to be in mergeable state (not necessary final) before EmacsConf, but we are generally not very pushy - we are all volunteers after all. >> Org mode only supports exporting via pdflatex, xelatex, and lualatex. > > Then my idea is to drop ctex, and use xeCJK or luatex-ja with babel. > These two packages support both Chinese and Japanese, while xeCJK > comes with out-of-the-box Chinese support and luatex-ja comes with > out-of-the-box Japanese support. Good. > pdfTeX support is also feasible, through the CJK package, which is > used by ctex as well. Note that pdfTeX is something we are not certain about. I wish we could do it, but it seems tricky. We will need to work out how we want to design the pdftex support. Tentatively, we may add a field to `org-latex-language-alist' where standard per-language config will be stored and loaded according to #+LANAGUAGE settings (note that there might be multiple languages in one document). -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
