From cyl Tue Oct 4 10:35:18 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA15602; Tue, 4 Oct 94 10:35:18 CDT Date: Tue, 4 Oct 1994 10:35:17 -0500 (CDT) From: Nelson CHIN To: Software Authors Subject: convert fonts from Ch-Word to TTF? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII anyone want to take up the offer to convert the GB fonts supplied with ifcss.org:/software/ms-win/chinese-sys/ch-word into True Type Fonts? Nelson ---------- Forwarded message ---------- Date: Tue, 4 Oct 1994 11:06:55 -0300 >From: Wenjia Zeng >also i was wondering why are the fonts takes up so much space, can they >be enlarge very big? would it be better to convert them to true type >fonts so other softwares can take advantage of them. > >see ifcss.org:/software/fonts/big5/ms-win for samples. > >Nelson > Hi! Nelson: Yes, they can be enlarge very big. Of course, it would be better to convert them to true type fonts so other software can take advantage of them. This is exactly what I hope some one else to do since I do not know how to do it and I do not have enough computing power to do it. Thanks and regards. Wenjia Zeng From shin@hermes.ee.nthu.edu.tw Fri Oct 14 05:27:11 1994 Return-Path: Received: from nthu.edu.tw by ifcss.org (4.1/IFCSS-Mailer) id AA17468; Fri, 14 Oct 94 05:27:11 CDT Received: from hermes.ee.nthu.edu.tw ([140.114.28.27]) by nthu.edu.tw with SMTP id <181879(1)>; Fri, 14 Oct 1994 18:30:56 +0800 Received: by hermes.ee.nthu.edu.tw (4.1/SMI-4.0/shin-1.0) id AA26078; Fri, 14 Oct 94 18:23:24 CST Date: Sat, 15 Oct 1994 08:23:24 +0800 From: shin@hermes.ee.nthu.edu.tw (Jing-Shin Chang) Message-Id: <9410141023.AA26078@hermes.ee.nthu.edu.tw> To: ccnet-l@uga.cc.uga.edu, soft-authors@ifcss.org Subject: GB symbols arranged in reversed order ? Hi, ccnetters, I found that the special symbol GB:a7b6 (upper case X) and a7b7 (upper case PHI) and their lower-case version: GB: a7e6 (phi) and a7e7 (x) are in different order. (Intuitively, it should be PHI, X, ..., phi, x..., isn't it?) I got such a GB code table from a PostScript hardcopy, which is generate by a program I got from ifcss (or cnd?) one or two years ago. When I checked such situation with cxterm with both 'cclib16s' and 'cclib16f', such reversed order is still the same. Therefore, I am wondering if the official GB code really assigned the codes in this way (... X, PHI, ..., phi, x ...) or someone who compiled those font files (or someone who provided a code list) had made some mistake such that the characters are arranged so strangely.) In ETen's Big5 mapping, both the upper case and lower case symbols are in the same order, i.e, ... PHI (C849), X (C84A), ... phi (a7e6), x (a7e7) ... ; in fact, I would guess that ETen's extension in this part is copied from GB's special symbols, since the char sequences are the same for all such special symbols, except for the above two swapped characters. If the official GB codes are in fact has the same order for the PHI/X and phi/x characters, then I guess many font files in ifcss.org need to be re-examined. Any comments or information? My mapping table is wrong? Thanks for your information. Jing-Shin -^^- From CAI%MVF.DecNet@wigate.nic.wisc.edu Fri Oct 14 09:24:02 1994 Return-Path: Received: from vms.macc.wisc.edu by ifcss.org (4.1/IFCSS-Mailer) id AA24929; Fri, 14 Oct 94 09:24:02 CDT Received: from VMSmail by wircs1.DecNet; Fri, 14 Oct 94 09:21 CDT Message-Id: <24101409210515@wircs1.DecNet> Date: Fri, 14 Oct 94 09:21 CDT From: CAI%MVF.DecNet@wigate.nic.wisc.edu Subject: GB symbols To: soft-authors@ifcss.org X-Vms-To: WIRCS1::IN%"soft-authors@ifcss.org" >From: IN%"shin@hermes.ee.nthu.edu.tw" 14-OCT-1994 05:29:22.39 I found that the special symbol GB:a7b6 (upper case X) and a7b7 (upper case PHI) and their lower-case version: GB: a7e6 (phi) and a7e7 (x) are in different order. (Intuitively, it should be PHI, X, ..., phi, x..., isn't it?) I got _______ I have one table generated long time ago from a 24x24 font. The order seems to be the same but the codes for lower case are a6d6 and a6d7 respectively. Actualy they are all in the order of phi (a6b5, a6d5), x (a6b6, a6d6) and psai (a6b7, a6d7) cai From shin@hermes.ee.nthu.edu.tw Fri Oct 14 09:54:53 1994 Return-Path: Received: from nthu.edu.tw by ifcss.org (4.1/IFCSS-Mailer) id AA25968; Fri, 14 Oct 94 09:54:53 CDT Received: from hermes.ee.nthu.edu.tw ([140.114.28.27]) by nthu.edu.tw with SMTP id <181771(1)>; Fri, 14 Oct 1994 22:58:33 +0800 Received: by hermes.ee.nthu.edu.tw (4.1/SMI-4.0/shin-1.0) id AA06402; Fri, 14 Oct 94 22:51:04 CST Date: Sat, 15 Oct 1994 12:51:04 +0800 From: shin@hermes.ee.nthu.edu.tw (Jing-Shin Chang) Message-Id: <9410141451.AA06402@hermes.ee.nthu.edu.tw> To: CAI%MVF.DecNet@wigate.nic.wisc.edu, soft-authors@ifcss.org Subject: Re: GB symbols |> From CAI%MVF.DecNet@wigate.nic.wisc.edu Fri Oct 14 22:30:20 1994 |> |> From: IN%"shin@hermes.ee.nthu.edu.tw" 14-OCT-1994 05:29:22.39 |> I found that the special symbol GB:a7b6 (upper case X) and a7b7 (upper case PHI) |> and their lower-case version: GB: a7e6 (phi) and a7e7 (x) are in different |> order. (Intuitively, it should be PHI, X, ..., phi, x..., isn't it?) I got |> |> _______ I have one table generated long time ago from a 24x24 font. |> The order seems to be the same but the codes for lower case |> are a6d6 and a6d7 respectively. Actualy they are all in the order |> of phi (a6b5, a6d5), x (a6b6, a6d6) and psai (a6b7, a6d7) |> |> cai |> The symbols you are referring to are those Greek symbols. What I was refering to look like the Greek Symbols, but they are in a different group. (I remembered that someone said that this group of symbols are Russian symbols or something else. Could you check the code points in the a7xx region? You had better also check it with the internal codes and fonts under cxterm /GB mode. Shin -^^- From davidk@mediastation.com Fri Oct 14 10:55:44 1994 Return-Path: Received: from heifetz.msen.com by ifcss.org (4.1/IFCSS-Mailer) id AA28327; Fri, 14 Oct 94 10:55:44 CDT Received: by heifetz.msen.com with UUCP (Smail3.1.28.1 #12) id m0qvoS3-000ZVxC; Fri, 14 Oct 94 11:21 EDT Received: from rameau.mediastation.com by mediastation.com (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA03144; Fri, 14 Oct 94 11:15:03 EDT From: davidk@mediastation.com (David Koelzer) Message-Id: <9410141515.AA03144@ mediastation.com> Received: by rameau.mediastation.com (NX5.67d/NX3.0X) id AA00434; Fri, 14 Oct 94 11:11:55 -0400 Date: Fri, 14 Oct 94 11:11:55 -0400 To: soft-authors@ifcss.org Subject: Please remove william@imagine.com from this list X-Mailer: Echelon Version 1.11 Please remove william@imagine.com from this list. He no longer has an account here. David Koelzer Media Station, Inc. From cyl Mon Oct 17 18:07:49 1994 Return-Path: Received: by ifcss.org (4.1/IFCSS-Mailer) id AA04256; Mon, 17 Oct 94 18:07:49 CDT Newsgroups: alt.chinese.computing Date: Mon, 17 Oct 1994 18:07:43 -0500 (CDT) From: Nelson CHIN To: Koichi Yasuoka Cc: Software Authors Subject: Re: GB symbols arranged in reversed order? (fwd) In-Reply-To: <199410170251.LAA03072@kudpc.kudpc.kyoto-u.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII bug-fixed guobiao font is archived at ifcss.org:/software/fonts/gb/bdf/guobiao16.bdf.gz anyone interested in fixing the other gb fonts in ifcss.org:/software/fonts/gb? also volunteers still needed to convert the gb fonts at ifcss.org:/software/ms-win/chinese-sys/ch-word into true type fonts. Nelson On Mon, 17 Oct 1994, Koichi Yasuoka wrote: > > Thank you, Mr.Nelson. I've found it's a bug of GB2312-80 itself. > However the bug is fixed in GB8565-88. So > >the official GB code really assigned the codes in this way > >(... X, PHI, ..., phi, x ...) > WAS true, but is false NOW. I've updated my guobiao16.bdf in my > hzbanner. Try and get it. > > Koichi Yasuoka > From A7621GAC@AWIUNI11.EDVZ.UNIVIE.AC.AT Tue Oct 25 16:25:07 1994 Return-Path: Received: from cnd.org (cnd.cnd.org) by ifcss.org (4.1/IFCSS-Mailer) id AA08815; Tue, 25 Oct 94 16:25:07 CDT Received: from AWIUNI11.EDVZ.UniVie.AC.AT (helios.edvz.univie.ac.at) by cnd.org (4.1/4.7) id AA19668; Sat, 22 Oct 94 08:43:25 PDT Message-Id: <9410221543.AA19668@cnd.org> Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT by AWIUNI11.EDVZ.UniVie.AC.AT (IBM VM SMTP V2R2) with BSMTP id 3582; Sat, 22 Oct 94 16:39:57 MEZ Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A7621GAC@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.2a/1.8a) with BSMTP id 7019; Sat, 22 Oct 1994 16:39:55 +0100 Date: Sat, 22 Oct 94 16:39:03 MEZ From: Werner Lemberg Subject: ANNOUNCING CJK 2.2 (Chin/Jap/Kor for LaTeX2e) To: soft-authors@ifcss.org, linux-asia@orac.iinet.com.au, ctan-ann@shsu.edu This package will be in language/chinese/CJK soon on all CTAN hosts (ftp.shsu.edu, ftp.dante.de, ftp.tex.ac.uk). Below you can find the most important new features and the readme file. Happy TeXing Werner PS: Sam Chiu has precompiled a set of GB and Big5 fonts for 600dpi resolution (about 22 MByte uncompressed!). It should be soon in /fonts/chinese/CJK-fonts. ============================================================================== Version 2.2 : new: 18-Oct-1994 CJK now supports hangul and hanja together. Two different sets of subfonts are used as defined in Uhangul.fd and Uhanja.fd . CJK punctuation characters (fullwidth comma, colon, semicolon etc.) will not start a line. CJK opening braces etc. will not end a line. This is the LaTeX2e style package CJK Version 2.2 (18-Oct-1994) =============================================================== It contains the following files: history.txt Package history CJK.txt This file CJK.sty A LaTeX2e style file to enable CJK (Chinese/Japanese/Korean) logographs (i.e. Hanzi/Kanji/Hangul) with LaTeX2e CJK.enc Master Encoding File (at the moment only for Chinese and Korean) standard.enc Bg5.enc KS.enc pmCsmall.enc pmCbig.enc Encoding scheme files Bg5.chr standard.chr hangul.chr pmC.chr Character encoding files Uhangul.fd Font definition file for standard Hangul fonts Uhanja.fd Font definition file for Hanja font (example only!) UBg5.fd UGBs.fd UGBt.fd Font definition files for Chinese (examples only!) UpmC-Bg5.fd UpmC-GBs.fd UpmC-GBt.fd Font definition files for (old) pmC-fonts vf/*.vf tfm/*.tfm virtual fonts and metric files for hangul standard fonts to use in combination with the font libraries lj_han and lj_han1 (available at the CTAN hosts) utils/hbf2cjk.w CWEB source file for hbf2cjk (at the moment only for UNIX) utils/hbf2hbf.w CWEB source file for hbf2hbf utils/hbf2cjk.c utils/hbf2hbf.c C code files extracted from the CWEB source files utils/hbf2cjk.dvi utils/hbf2hbf.dvi Documentation extracted from the CWEB source files utils/hbf.h utils/hbf.c Ross Paterson's HBF API (with small extensions) utils/Makefile Makefile for hbf2hbf utils/Makefile.hbf2cjk Makefile for hbf2cjk (only for UNIX) This is freely distributable under the GNU Public License. ******************************* * New Korean virtual fonts! * ******************************* Use --- Use CJK.sty as a package, e.g. \documentclass{article} \usepackage{CJK} . Two new environments \begin{CJK}{encoding}{shape} ... \end{CJK} and \begin{CJK*}{encoding}{shape} ... \end{CJK*} are defined: encoding the following coding schemes are currently implemented in CJK.enc: Bg5 (Big5) GBs (GuoBiao with simplified characters) GBt (GuoBiao with traditional characters) KS (hangul and hanja). For compatibility with the pmC package three additional encodings are defined: pmC-Bg5, pmC-GBs, and pmC-GBt. It's not encouraged to use these encodings because of wasting fonts. If possible, convert your original CJK-bitmaps with bmf2gf or hbf2cjk (see below) to CJK-encodings. shape It is impossible to know what fonts are available at your site; look at the example .fd-files how to create appropriate .fd-files suiting your needs. If you use the KS environment, this parameter is unused (see below). CJK* will swallow unprotected spaces and newlines after a CJK character, whereas CJK will not. This is a very realistic example: \begin{CJK*}{GBs}{kai} ... Text in GuoBiao encoding ... \end{CJK*} How it works ------------ Asiatic logographs can't be represented with one byte per character. (At least) two bytes are needed, and the most common encoding schemes (GB, Big5, JIS, KS etc.) have a certain range for the first byte (usually 0xA1-OxFE or a part of it) which signales that this and the next byte represents an Asiatic logograph. This means that plain ASCII-text (i.e. characters between 0x00 and 0x7F) will be left undisturbed, and most characters of the extended ASCII character set (0x80-0xFF) will be assigned to a CJK encoding. CJK.sty will make the characters 0xA1-OxFE active (and in the file CJK.enc you should inactivate those characters not needed to be active if you add a new encoding scheme) inside of an environment and assigns the macros \CJK@char and \CJK@charx to the active characters which select the proper font. The real mechanism is a bit more complicated to assure robustness (it was borrowed and modified from german.sty) and correct handling of punctuation characters. The encodings ------------- CJK.sty defines internally \CJK@standardEncoding, \CJK@Bg5Encoding, \CJK@KSEncoding, and for compatibility with pmC, \CJK@pmCsmallEncoding and \CJK@pmCbigEncoding. \CJK@standardEncoding will be used for encodings with the second byte in the range 0xA0-0xFE (GB etc). \CJK@Bg5Encoding will be used for Big5 encoding (e.g. NTU fonts) with the second byte in the range 0x40-0xFE. \CJK@KSEncoding will be used for KS encoding. Two sets of subfonts are defined, one for Hangul syllables and elements, and a second for Hanja. For more details see below. \CJK@pmCsmallEncoding and \CJK@pmCbigEncoding can be activated with \pmCsmall (this is the default) and \pmCbig inside the CJK environment. Note that the original pmC fonts have two character sizes per font (the bigger ones with an offset of -128); pmC-Big5 encoded fonts cannot contain big characters. The names of the fonts in the UpmC-xxx.fd files reflect the modifications added by Marc Leisher (mleisher@nmsu.edu) to the original poor man's Chinese (pmC) package written by Thomas Ridgeway (ridgeway@blackbox.hacc.washington.edu). The fonts --------- CJK.sty uses NFSS (New Font Selection Scheme) which has some advantages over the font selection offered with pmC: o TeX fonts are loaded only on demand. This is especially useful with Asiatic logographs. If you have e.g. three Chinese characters in your text, pmC must load the whole Chinese font (about 85 TeX fonts), whereas LaTeX2e loads only three fonts normally. o As long as the limit of 256 TeX fonts will not be exceeded, you can use as many CJK fonts as you like (e.g. simplified and traditional Chinese characters together with Japanese fonts in different sizes) --- pmC is limited to two sizes and can only have two CJK fonts at the same time. In the web2c-TeX package (for UNIX) you will find a patch which allows the use of more than 256 TeX fonts. o You need not to care about the right size of CJK fonts in footnotes etc. They will obey the NFSS (although changing the other attributes except font series and size will be done with \CJKenc and \CJKshape). For font selection in a hangul environment see below. Of course you must have proper sizes of your CJK fonts --- if you have, say, 48x48 and 64x64 bitmap fonts (or greater), I recommend bmf2gf to convert them directly to .pk-fonts. If you have only 24x24 size (as most of the public domain fonts are), you can magnify them using bmf2gf with integer magnifications or hbf2cjk with arbitrary magnifications. See the last section for availability of precompiled fonts. If you chose one font per active character as with the pmC macros, you would waste character space (256 characters per font are possible with TeX 3). Therefore CJK.sty expects the whole Asiatic font splitted in TeX subfonts with 256 characters each. An example: GuoBiao-encoded simplified characters in song style 12pt: ^ ^ ^^ ^^ first byte second byte TeX font offset ---------------------------------------------- 0xA1 0xA1-OxFE gsso1201 0 0xA2 0xA1-0xFE gsso1201 94 0xA3 0xA1-0xE4 gsso1201 188 0xA3 0xE5-0xFE gsso1202 0 0xA4 0xA1-0xFE gsso1202 26 0xA5 0xA1-0xFE gsso1202 120 . . . 0xFE 0xA1-OxFE gsso1235 38 To create such splitted fonts you can use the package bmf2gf (written by me) which should be at the same place where you've found this package (I upload my TeX packages to the CTAN hosts). Enclosed here in the CJK package you will find the source code of the program hbf2hbf which you should use instead of hbf2bmf of the bmf2gf package. The latter only supports the Big5 encoding scheme of CJK versions before 2.1 . hbf2hbf converts HBF fonts into BMF files (plus a HBF header file) bmf2gf can understand. See the next section for the syntax. To make hbf2hbf, you will need the GNU C compiler and GNU make, and optionally the CWEB package. For converting to .pk-files via bmf2gf, you should get the appropriate HBF (Hanzi Bitmap Font) header files from ifcss.org (or create if you can't find the right one); almost all Chinese bitmap fonts in the public domain together with their HBF headers are collected there. These HBF files document CJK fonts completely. Using hbf2cjk ------------- If bmf2gf does not satisfy you, try hbf2cjk. This program is a patched version of HBFtoPK written by S. Simpson . To execute hbf2cjk, you additionally need pnmscale and pgmtopbm of the pbmplus package and pbmtopk. Consider this as a beta version which works unmodified only under UNIX. hbf2cjk is much more slower than bmf2gf - it will call pnmscale and pgmtopbm for each character. The advantage is that you can scale the fonts with any (reasonable) value. To compile hbf2cjk, you will need the GNU C compiler and GNU make, and optionally CWEB. Say `make TARGET -fMakefile.hbf2cjk', where TARGET can be `unix' or `unixdebug'. You should first convert your original CJK font and HBF header with hbf2hbf into a temporary font file and HBF header: Syntax: hbf2hbf output_font_name_without_extension input_HBF_header Then call hbf2cjk to build the needed TeX subfonts: Syntax: hbf2cjk HBF_file fontname resolution family encoding Two decimal digits will be appended to the `fontname' parameter to construct the output file names; `family' and `encoding' will appear as identifiers in the .tfm files. An example: input files: jfs56.a - jfs56.e, jfs56.hbf program calls: hbf2hbf temp jfs56.hbf hbf2cjk temp.hbf gsfs13 300 "Jianti FanSong" "Big5" output files: gsfs1301.300pk - gsfs1332.300pk gsfs1301.tfm - gsfs1332.tfm [gsfs: GuoBiao simple encoded FanSong style] ^ ^ ^ ^ It's hard to overcome the DOS restriction of 8 characters in a file name if you need two characters as a running number... Korean input ------------ (The status of this feature is experimental. I can't speak Korean and would be glad to hear comments from people who have any idea what is happening here :-) There are already different packages handling Hangul: hlatex, htex etc.; there is one package which also can handle hanja: jhtex. The great difference of the packages just mentioned compared to CJK is the use of a preprocessor which converts text files containing KS encoded text into a TeX file. To do so has some advantages, but the output is completely unreadable. Additionally the output lines become rather lengthy (a two byte character code will be converted into a string up to 11 characters long), which may confuse some editors; and if you have a text which contains Chinese or Japanese also, you can't use KS to TeX converters because the code ranges overlap and the converters are not able to recognize which is Korean and which is not. In contrast, CJK does not need a preprocessor and the problems mentioned above are nonexistent, but you get nothing for free: CJK uses the virtual font mechanism to map the hangul syllables onto Hangul Elements (11 virtual fonts map to 2 real fonts), whereas preprocessors directly use the real fonts. CJK's hangul support is thought for users who write texts in a non CJK language and who want to input some hangul characters, possibly mixed with Chinese or Japanese. If you want a complete Korean environment, I recommend jhtex. There you will also find a hangul.sty which modifies (among others) the sectioning commands to enable Korean chapter counting and Korean headers. To use the KS environment, say \begin{CJK}{KS}{} ... \end{CJK} . These font switches are available inside the environment: fonts from hLaTeX: * \mj MyoungJo (default) \gt Gothic \gs BootGulssi \gr Graphic \dr Dinaru fonts from jhTeX: * \hgt Hangul Gothic * \hmj Hangul MyoungJo (MunHwaBu fonts) * \hpg Hangul Pilgi \hol Hangul Outline (MyoungJo) If a font is marked with a star, bold series are available. You will find the hangul fonts in the lj_han and lj_han1 packages. These are emTeX libraries for 300 dpi resolution which can be easily converted back to .pk fonts using the fontlib package of emTeX. If you need different resolutions, you must obtain the original metafont sources of the hlatex_mf.tar.gz and the jhtex packages. Note that the shapes of Hangul elements are not satisfactory. You find the needed virtual fonts and virtual metric files in the vf and tfm directories. Move the .tfm files into a directory TeX will scan. You need a dvi driver which understands virtual fonts - move the .vf files into a directory your dvi driver will scan. For non-hangul characters inside the KS environment (i.e. the first byte in the ranges 0xA1-0xAF except 0xA4 and 0xC9-0xFD), fonts are taken from Uhanja.fd . This enables the use of many hangul fonts and perhaps only one or two different hanja fonts. If you don't want the overlay of hangul fonts from Uhangul.fd, say \CJKhanja. The opposite command is \CJKhangul. Archaic hangul elements (KS 0xA4D5-0xA4FE) and the character KS 0xA4D4 are only accessible if \CJKhanja is active. You should convert your KS hanja fonts using bmf2gf or hbf2cjk as described above. The .fd-files ------------- CJK fonts can be installed as easy as normal TeX fonts! CJK.sty defines four new size commands: CJK corresponds to `' (empty) sCJK corresponds to s CJKfixed corresponds to fixed sCJKfixed corresponds to sfixed . The difference between these size functions and the original commands defined by LaTeX2e is that a CJK size function defines a class of fonts. If you say as an example \DeclareFontShape{U}{Bg5}{m}{song}{<6> <7> <8> sCJKfixed * b5so07}{} , LaTeX2e searches for fonts named b5so0701 - b5so0758 if the font size is 6, 7 or 8 pt; with other words, the CJK size functions append two digits to select the proper subfonts. These digits are defined in the \CJK@...Encoding macros; the macro \CJK@plane holds the current value (for pmC compatibility, \CJK@plane holds hexadecimal numbers). See the example .fd files how to define font substitutions additionally. Caveats ------- o You can of course use CJK-environments inside of a CJK-environment, but it is possible that you must increase the so called save size (with emTeX you can adjust this with -ms=...). The CJK package has optional arguments which controls the scope of CJK environments: lowercase If you want to use \lowercase with non-Big5 encodings inside CJK environments. You need less save size using the `encapsulated' option if `lowercase' is not set. global \lccode (if `lowercase' set), \uccode, \catcode and the activation of the characters 0xA1-0xFE will be globally modified (\lccode and \uccode reset to 0). This is the most economical mode concerning save size, but you can't have CJK environments inside of CJK environments or other environments which manipulate the character range 0xA1-0xFE. Packages which change some of the above values only once (e.g. in the preamble) will also not work after the first use of a CJK environment. local Only \lccode (if `lowercase' set) and \uccode will be modified globally. This is the default. You can stack environments. encapsulated If you want to use DC fonts outside of the CJK environment with \uppercase and \lowercase working correctly, you must use this option. All values mentioned above will be local, so you can stack environments. This option probably causes an overflow of the save size. Say \usepackage[option]{CJK} to activate `option'. o There is an other way to overcome the problem of stacked environments. CJK implements two low level CJK attribute switches: \CJKenc and \CJKshape, which take the same arguments as the corresponding values of the CJK environment. If you need two different encodings/shapes at the same output line, you must use these macros. An example: \begin{CJK}{GBs}{song} ... Text in GBs song ... \CJKenc{GBt} ... Text in GBt song ... \CJKshape{kai} ... Text in GBt kai ... \end{CJK} As with \begin{CJK}{...}{...}, you should start a new line after \CJKenc to assure that possibly new activated characters get their active meaning. o The characters \, {, and } are used as second bytes in the Big5 encoding. If you write Big5 text, you should use the Bg5text environment which changes the category codes of these characters. The command prefix is now the forward slash /, and the grouping characters are ( and ) respectively. An example: \begin{CJK}{Bg5}{song} \begin{Bg5text} .... /begin(center) .... /end(center) .... /end(Bg5text) \end{CJK} To get the /, (, and ) characters, write //, /(, and /) inside the Bg5text environment. This environment is ugly, and some commands like \newcommand will not work in it, but I know no other solution to retain all CJK characters readable with a Big5 editor. o Instead of using the Bg5text environment you can protect the offending second bytes with a backslash, i.e. \{, \}, \\ (using a non- Chinese editor). This will not increase the readability of the Chinese text, but for short texts it's perhaps more comfortable. Alas, it doesn't work in page header commands because the macros \{ etc. will not be expanded. o Be careful not to use any commands inside the Bg5text environment which write something into an external file (commands like \chapter etc.). o If it's not possible to avoid Big5 character codes with \, {, or } outside of the Bg5text environment (e.g. having Big5-text in a \chapter or \section command), you can replace them with the \CJKchar macro manually: \section{This is a problematic Big5 character: \CJKchar{169}{92}} The parameters are the first and second byte of the Big5 character code. You can also use hexadecimal or octal notation. o CJK will disable \uppercase and \lowercase (preserving the commands within \CJKuppercase and \CJKlowercase) if you select a Big5 encoding. This affects the headers of the standard classes and \Roman only in standard LaTeX2e. o \uppercase and \lowercase will work with NONE of the CJK encoding schemes if you use DC fonts because these 8-bit fonts have most \lccode's and \uccode's set in the range 0x80-0xFF. o You should define for each TeX font size a CJK font (as an example, use sCJKfixed for good sizes and CJKfixed for bad sizes, and LaTeX2e will complain loudly about wrong sizes on the screen). LaTeX2e will also do the job if some size definitions are missing (using defined sizes), but expect a font warning for each (!) CJK character affected under certain circumstances. Possible errors --------------- o If you write Chinese (or Japanese) text, don't forget to suppress the linefeed character with a trailing `%' in the CJK environment, otherwise you get unwanted spaces in the output. On the other side, say `\ ' or something similar inside the CJK* environment to get a space after a CJK character. o To prevent a line break before a CJK character (e.g. between an opening (non-CJK) parenthesis and a CJK character), say \CJKkern. This command prevents the insertion of \CJKglue before the CJK character. You may wonder about the curious name: a small kern (1 sp) between CJK characters signales that the first is a punctuation character. o If you get the error message: "\CJK@min (or \CJK@max) undefined", you should insert \newpage before saying \end{CJK}. This can happen if LaTeX writes the headers (or footers) of a page containing Chinese characters after closing the CJK environment. o If you get overfull hboxes caused by CJK characters, try to increase \CJKglue. It defines the glue between CJK characters; the default definition is \newcommand{\CJKglue}{\hskip 0pt plus 0.08\baselineskip} . \CJKglue will be inserted by CJK before each Chinese character (except punctuation characters as defined in the punctuation tables; see CJK.enc), and none after. You should separate non-Chinese text from CJK characters with spaces to enable hyphenation. o If you get overfull hboxes caused by Hangul syllables, try to increase \CJKtolerance. The default definition is \newcommand{\CJKtolerance}{400} . o If you encounter a TeX stack overflow caused by {\CJKenc{new_encoding} ....}, you should write \CJKenc{new_encoding} ... \CJKenc{old_encoding} instead. Or (better) increase the stack size as discussed above. How to get CJK and related software ----------------------------------- o You will find CJK and software related to TeX at the CTAN hosts (Comprehensive TeX Archive Network). These completely identical ftp servers (concerning TeX software) are ftp.shsu.edu Sam Houston University Texas (USA) ftp.dante.de DANTE (Deutsche Anwendervereinigung fuer TeX) Heidelberg (Germany) ftp.tex.ac.uk Cambridge University Cambridge (England) You should use the nearest one, or even better, a local mirror of a CTAN host. CJK will be found unpacked. To receive the complete package, go to the parent directory of CJK and say get CJK.zip or (whichever is appropriate for your system) get CJK.tar.gz The CJK directory and all subdirectories will be sent to you in compressed form. Be aware that not all mirrors of CTAN sites support compression of directories. o The main site for Chinese related software is ifcss.org (USA). Mirrors are ftp.edu.tw (Taiwan) and kth.se (Sweden). Here you find free Chinese fonts, Text editors etc. o The main site for Korean related software is cair-archive.kaist.ac.kr (Korea). I don't know any mirror sites of this host. At ifcss.org you will find a 24x24 hanja font with HBF header in /software/fonts/misc/hbf. o Sam Chiu compiled the fonts jfs56 (GBs encoded) and ntu_kai48 (Big5 encoded) for various sizes with 600dpi resolution. You will find them (about 22 MByte uncompressed!) at the CTAN hosts in /tex-archive/fonts/chinese Author ------ Werner Lemberg Goldschlagstr. 52/14 A-1150 Vienna Austria/Europe Please report any errors or suggestions to this email-address.