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?
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.
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?
> 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 think there are multiple solutions for Japanese. See
https://en.wikibooks.org/wiki/LaTeX/Internationalization#Japanese
> 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.
> 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.
> 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.
--
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>
