Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

I use XeLaTeX with TeXShop v. 2.47 and have generally good results with the SimSun and PMingLiU fonts.

However, I find that the glyph ○ (U+25CB), which is used for zero in some of my sources, is output as a blank space when I typeset, whether by Pdftex or TeX and DVI, and whether I enter the character itself or the explicit code \char"25CB.

The glyph is present in both fonts and I can get it to appear on the screen and to print to PDF and physical printers without difficulty using traditional word processors.

Any idea what is wrong or how to fix it?

Code follows:

%!TEX TS-program = xelatex
%!TEX encoding = UTF-8 Unicode

\documentclass{article}
\usepackage{xeCJK}
\usepackage{fontspec}
\setCJKmainfont{PMingLiU} % or SimSun

\begin{document}
Using glyphs: 二○○二年\\
Using codepoint: 二\char"25CB\char"25CB 二年
\end{document}

Output:

enter image description here

share|improve this question
    
Do the fonts actually contain the character? –  Caramdir Jul 1 '12 at 23:48
2  
@Caramdir: Both fonts do contain the character, according to the Character Viewer in OS 10.6.8. This is part of the Geometric Shapes plane, which may explain why XeLaTeX does not treat it as Chinese. However, it and a number of other symbols outside of the CJK planes do periodically appear in Chinese texts. Other fonts listed in the Character Viewer as containing this glyph, such as Apple LiSung Light and Heiti SC Light/Medium, also fail to render it. –  brannerchinese Jul 2 '12 at 0:09
    
● and ○ are both important in the representation of traditional Chinese prosody, apart from the fact that ○ often stands in for zero. –  brannerchinese Jul 2 '12 at 0:17
add comment

1 Answer

I'm sorry but you wrongly used the Chinese symbol.

U+25CB (○) is a 'white circle', but NOT a Chinese character. You should, instead, use U+3007 (〇) for a 'ideographic number zero'.

xeCJK does not treat U+25CB as a CJK symbol, so in your document Latin Modern Roman font is used and no glyph is output.

The two symbols look very similar. Even some Chinese misuse them. However, in some fonts, e.g. Microsoft YaHei, the two look quite different:

enter image description here


CJKnumb package from the CJK bundle is often used to produce CJK numbers and digits. Although it is not designed for xeCJK, xeCJK has a CJKnumber option to fix the problems and makes it available:

\documentclass{article}
\usepackage[CJKnumber]{xeCJK}
\setCJKmainfont{PMingLiU}

\begin{document}

二〇〇二年

\CJKdigits{2002}年

\end{document}

Also, you can use 李清's new zhnumber package to produce CJK numbers and digits. It works fine with xeCJK. Example:

\documentclass{article}
\usepackage{xeCJK}
\setCJKmainfont{PMingLiU}

\usepackage{zhnumber}

\begin{document}

二〇〇二年

\zhdigits{2002}年

\end{document}

zhnumber is a modern alternative of CJKnumb. We plan to use zhnumber instead of CJKnumb for future versions of ctex bundle and other Chinese tools.


For the symbol usage, you can certainly use ○ and ● as you wish. However, you should specify a NON-CJK font rather than a CJK font. Say, you can use \setmainfont to set a font with these symbols:

\documentclass{article}
\usepackage{xeCJK}
\setmainfont{Linux Libertine O} % for solution 1
\newfontfamily\simsun{SimSun}   % for solution 2
\setCJKmainfont{SimSun}
\begin{document}

\section{Use a western main font with Unicode symbol support}

十六字令

天。休使圆蟾照客眠。人何在?桂影自婵娟。

○。[●]●○○●●○。○○●,[●]●●○○。(Linux Libertine)

\section{Use a Chinese font as a normal font}

{\simsun ○。[●]●○○●●○。○○●,[●]●●○○。}(SimSun)

\section{Configure xeCJK to treat the symbols as CJK symbols}

\xeCJKsetcharclass{`●}{`●}{1}% DO NOT use this
\xeCJKsetcharclass{`○}{`○}{1}% DO NOT use this

○。[●]●○○●●○。○○●,[●]●●○○。(SimSun, without affecting brackets)

\end{document}

But remember: don't use U+25CB as a CJK number, you should modify the source code.

share|improve this answer
    
No, no, I agree that the symbol is not correct, but it is in fact in use by some people. And because it is in use, I have to be able to typeset text that contains it. If you search for, say, "二○一二年" on a search engine, you will find countless examples of this sort of thing. For example, shanghai.gov.cn/shanghai/node2314/node2319/node2404/n30571/… , etc. etc. etc. I already use a script to replace ○ with 0 or 〇 in my materials, but that does not solve the real problem, which is that I have to be able to render the actual text used by people I am citing. I can't correct them. –  brannerchinese Jul 2 '12 at 8:48
    
My basic feeling is that if a glyph appears in a font, I should be able to use that font's version of that glyph, without making other sorts of corrections. –  brannerchinese Jul 2 '12 at 8:51
    
Here is an example that does not involve numbers: "有人用○来代表平声字、●来代表仄声字。" [Some people use ○ to stand for syllables in the píng tone and ● for syllables in the zè tones.] This is a legitimate usage unrelated to numerals, but neither of the shapes from the Geometric Shapes plane appears. XeLaTeX is suppressing them. My question is: how do I get them to appear, right or wrong? –  brannerchinese Jul 2 '12 at 9:06
1  
@brannerchinese: There might be two reasons why some Chinese wrongly use the symbols. 1. Some Chinese pinyin IME (input method editor) are poorly designed. 2. There are some old fonts with no CJK zero glyph (U+3007). Luckily, new IME's and fonts are better, there's no reason to continue the mistake. –  Leo Liu Jul 2 '12 at 11:13
1  
I agree that it's mistaken usage, but as a scholar, I must be able to quote even mistaken usage, if that is what my source supplies to me. Their reason for being wrong is not important. In the present case I am automating the processing of text; whatever graphs appear in the original must appear in the XeLaTeX-typeset form, even if they are not standard usage. If they appear in a CJK text, it would be best to use a CJK font to typeset them, just as in the original. I'm grateful for your work here, but it seems that you are calling for more manual normalization than is efficient. –  brannerchinese Jul 2 '12 at 11:35
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.