On Sun, 09 Nov 2025 20:21:32 +0800, Ihor Radchenko wrote: > > Huang Jing <[email protected]> writes: > > >> ctex is (IMHO) orthogonal to this. > > > > ctex (https://ctan.org/pkg/ctex) can actually be think of an > > abstraction layer on top of several Chinese supporting macro-packages, > > so for example when compiled using XeTeX (XeTeX is the engine which > > XeLaTeX is a format built for XeTeX) it will load xeCJK, and when > > using LuaTeX, it will load luatex-ja for Chinese typesetting > > support. IMO it's best to use it, so the export of Org containing > > Chinese text can be processed with nearly every TeX engine (XeTeX, > > LuaTeX, pTeX family, pdfTeX, ApTeX). > > 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. 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. > FYI, the design we are going for is currently focused on auto-loading > babel/polyglossia, possibly with additional user configuration. > You can find the details of what we are working on in the new sections > in the Org manual on feature/all-tex-fonts branch ($REPO/doc/org-manual.org) > > For context, babel is, according to LaTeX devs, the goto solution for > loading typesetting rules in non-English documents. + there is font > configuration. From my understanding, xeCJK is necessary for font > configuration. 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. > The overall goal of this ongoing effort is making basic export work > without errors without additional configuration. (Currently, for > non-English documents users have to figure out themselves any additional > latex configuration necessary to produce pdf). The results do not have to > be perfect, as everything is already configurable, so users can tweak > things if fine-tuning is necessary. > > > 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 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. 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. > > And the use of \ctexset{space=auto} is not encouraged, expecially by > > Org. This option has different behaviours across different engines. > > > > If decided adding zws as delimiters is the solution for inline markup > > CJK texts, then the best solution should be changing the catcode for > > zws as active, and define it to \relax. So it will be ignored by the > > TeX engine while macro expansion. This is the code, which you can add > > in preamable to test. > > > > \catcode`\^^^^200b=\active\let^^^^200b\relax > > Zero-width spaces are simply recommended as a part of Org markup, > because Org markup only recognizes *bold* /italic/, =verbatim=, and > ~code~, when the */=~ markers are paired with whitespace (usually space, > but can also be zero-width space). This is sometimes considered awkward > and has side effects when exporting to pdf, and there are multiple > possible ways to address the problem (depending what you see as the > problem). > Let's discuss it in more details in > https://list.orgmode.org/CAO48Bk-rAv-UdEGwySU36kqS6SoP2+oy43a=uhod1qjeqgy...@mail.gmail.com/T/#t > as this is not specific to Chinese, but also touches on intraword markup. > > >> Which begs the question whether a solution with an extra document class > >> for this could not be the cleanest answer in the > >> future. (But leave it as FFS, please) > > > > I am willing to work on Chinese and Japanese support in Org, however I > > might need some guidance on the Org infra. And since there is no such > > package like ctex for Japanese, only a document class providing > > unified interface across engines (the BXjscls, > > https://ctan.org/pkg/bxjscls). > > Thanks for volunteering! I'm currently having my mid-term exams, so I'll be able to work on this after Tuesday. > I think there are multiple solutions for Japanese. See > https://en.wikibooks.org/wiki/LaTeX/Internationalization#Japanese I mean there is no unified interface provided, comparable to ctex. But since we are only supporting XeTeX, LuaTeX and pdfTeX, then that's not a problem. > > Some questions: > > > > 1. Which engines should we support? Only pdfTeX, XeTeX and LuaTeX, or > > pTeX family and ApTeX as well. > > 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. pdfTeX support is also feasible, through the CJK package, which is used by ctex as well. > > 2. How configurable the TeX export is from Org? In what form can one > > configure it? (sry I'm not that familiar with Org.) This might affect > > whether to use an engine-wise solution rather than ctex or any unified > > interface, since that's more flexible. > > Export in Org mode is fully programmable. You can refer to > https://orgmode.org/manual/Exporting.html, > https://orgmode.org/manual/LaTeX-Export.html, and > https://orgmode.org/manual/Advanced-Export-Configuration.html > The last link describes the export logic. > The whole thing is somewhat similar to pandoc, but every aspect of the > export is user-configurable. > Let me know if you have any further questions. Thx! > > 3. Do we prefer document class based solution or macro-package based > > solution? > > Documentclass is generally configurable by users > (#+LATEX_CLASS). Ideally, users should not care about class at all and > things should work as long as document #+LANGUAGE and possibly fonts are > specified. Gotcha. > -- > 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>
