2

I am using CJK package to typeset traditional Chinese text. When using Big5 encoding, some characters will break:

\documentclass{article}
\usepackage{CJK}
\begin{document}
\begin{CJK*}{Bg5}{bsmi}
認識
\end{CJK*}
\end{document}

Then I get

Runaway argument?
{ \end {CJK*} \end {document} 
! File ended while scanning use of \CJK@XX.
<inserted text> 
                \par

If I remove 認 (the first character) then everything will OK.

程 has the same effect.

The similar but not the same result is from 開:

! Argument of \CJK@XX has an extra }.
<inserted text> 
                \par 
l.6 開

I guess the problem is from catcode mechanism behind CJK. So can anyone help me to resolve it?

PS: I know there is ctex, xeCJK, luatex-ja etc. But I just need to test CJK package, with Big5 encoding. By the way, GBK and UTF8 don't have such problem.

stone-zeng
  • 2,710

1 Answers1

6

Your problem is caused by the second byte of the problematic characters.

Let me first name a few characters that replicate the problem (hex code in the parenthesis is the code point of the corresponding character in Big5 encoding).

  • ! File ended while scanning use of \CJK@XX.: 認 (0xBB7B), 程 (0xB57B), and 臨 (0xC17B)
  • ! Argument of \CJK@XX has an extra }.: 開 (0xB67D), 稀 (0xB57D), and 飼 (0xB97D)

You might notice that all the characters that cause ! File ended while scanning use of \CJK@XX. have 0x7B in their second byte. In ASCII code, 0x7B means {, which has a special meaning to LaTeX. So, a part of 認 was interpreted as an unbalanced opening brace, hence the error. Same explanation can be applied to ! Argument of \CJK@XX has an extra }. because 0x7D in ASCII code means }.

Sometimes, more weird thing can happen. The following code can be typeset without an error, but the output is totally unexpected (Big5-encoded of course).

\documentclass{article}
\usepackage{CJK}
\begin{document}
\begin{CJK*}{Bg5}{bsmi}
臨開
\end{CJK*}
\end{document}

unexpected output

Considering the fact that 褻 has the code point 0xC1B6 in Big5 encoding, it's no wonder that this happens.

In order to overcome this restriction, CJK package prepares a utility program bg5conv along with sjisconv (for Shift_JIS) and extconv (for Big5+ and GBK). These programs convert characters into a safe form so that they are compatible with LaTeX.

Typeset the following code with -shell-escape option, and you will get a desired output.

\RequirePackage{filecontents}
\begin{filecontents}{\jobname-input.tex}
認程臨開稀飼
\end{filecontents}
\immediate\write18{bg5conv <\jobname-input.tex> \jobname-processed.tex}
\documentclass{article}
\usepackage{CJK}
\begin{document}
\begin{CJK}{Bg5}{bsmi}
  \input{\jobname-processed.tex}
\end{CJK}
\end{document}

bg4conv

When you have the luxury, you can also use a shell script wrapper called bg5pdflatex, which converts the whole source and then runs pdfLaTeX. This doesn't require the -shell-escape option as is in Ch'en Meng's comment.

% Typeset this with bg5pdflatex or bg5latex.
\documentclass{article}
\usepackage{CJK}
\begin{document}
\begin{CJK}{Bg5}{bsmi}
認程臨開稀飼
\end{CJK}
\end{document}

However, I'm not sure if these are satisfactory solutions to the OP and I find them inconvenient.

yudai-nkt
  • 921
  • 1
    As a Japanese, who have a similar problem with Shift_JIS encoding, my personal advice is to avoid using legacy encodings and switch to UTF-8 (I don't know how severe the OP's necessity of testing CJK with Big5 is though). – yudai-nkt Dec 29 '17 at 19:15
  • 1
    There seems to be Bg5text environment, which is less flexible but doesn't rely on external tools. I don't include it in my answer because it ended up freezing on my end and I haven't found a reason yet. You might investigate the environment and give it a try. – yudai-nkt Dec 31 '17 at 03:25
  • 1
    For those who do not want to enable --shell-escape to solve this basic problem, they could replace compile command latex/pdflatex by bg5latex/bg5pdflatex. There are also gbklatex and gbkpdflatex exist for solve the same problem in the encoding GBK. Since this kind of problem (named 許蓋功 in traditional Chinese) is rooted in the encoding, to solve them once and for all, one should always apply the encoding UTF-8 for their LaTeX manuscripts. BTW, it's wondered how Japanese people call this problem in Japanese? (Yes, I do read Japanese. : )) – Ch'en Meng Jan 02 '18 at 02:32
  • @Ch'enMeng Thanks for the info and I've added a solution using bg5pdflatex. Regarding your question, those ill-behaved characters are often called ダメ文字 (dame-moji, lit. bad character for those who don't read Japanese) here in Japan. – yudai-nkt Jan 02 '18 at 16:27
  • Thanks for the name in Japanese. :) – Ch'en Meng Jan 03 '18 at 05:34