Skip to main content

终于装好了中文LaTeX

很多作业要用LaTeX排版了,Linux下安装就是方便,TeX,LaTeX,teTeX,都是轻松安装,使用也不错,一个pdflatex命令就全搞定了,然而现在需要中文了,就不那么方便了。
Windows下可以去http://www.ctex.org下ctex套装,虽然有几百兆,可我用迅雷只花了3分种就下来了。安装很慢,用起来还可以,只是没试中文的情况,应该不用再配置了吧。
但是Linux下就麻烦很多了,唉,ctex为什么不开发个Linux版呢,害我花了好几个小时才弄好

我查到了主流解决方案有两个,UCS和CJK,一开始我用aptitude在源里找,都找到也都装了,但是在网上查安装方法却发现还要自己装字体。

USC在这里有介绍http://bbs.sayya.org/~edt1023/tex/ipeucs/node4.html,但是需要个cyberbit字体,我这里是烂教育网,没法下,最后只得放弃

然后就是CJK了,开始在apt源里发现了arphic字体,但是编译tex时总报错,只得作罢。
后来查了N多资料,有不少都十分麻烦,但是发现了这个:http://www.cublog.cn/u/29820/showart_236501.html,文中提到了个gbkfonts,可以在http://learn.tsinghua.edu.cn/homepage/2001315450/src/gbkfonts-linux-0.3.tar.gz下载,虽然我这里不能编译(它竟然是用cc编译的),但是压缩里有编译好的程序,需要用的是gbkfonts和一个叫appendconf的脚本。
现在要从windows里拷如下几个字体文件:simfang.ttf,simkai.ttf,simhei.ttf,simsun.ttc,放到~/fonts里,再把gbkfonts,appendconf也拷过来,运行
./gbkfonts simfang.ttf fang
./gbkfonts simkai.ttf kaif
./gbkfonts.simhei.ttf hei
./gbkfonts simsun.ttc song
(其中最后一个参数表示在tex中使用的字体名)
然后直接运行gbkfonts,会出介绍,最后让你把dvips, tex, dvipdfm,fonts几个目录拷到/usr/share/texmf里
再运行appendconf就好了,参数是/usr/share/texmf
(因为我这里tex都是用sudo aptitude装的,所以都装到/usr/lib /usr/share...去了,而不是/usr/local/...)

生成pdf时仍有问题,需要个dvipdfmx,用apt装一下吧。

这就算装完了,试试看

\documentclass{article}
\usepackage{CJK}
\title{Font Test}
\author{WangLu}
\begin{document}
\maketitle
\begin{CJK}{GBK}{song}
宋体测试\\
\end{CJK}
\begin{CJK}{GBK}{kai}
楷体测试\\
\end{CJK}
\begin{CJK}{GBK}{hei}
黑体测试\\
\end{CJK}
\begin{CJK}{GBK}{fang}
仿宋体测试\\
\end{CJK}
\end{document}


存为test.tex
然后
latex test
dvipdfmx test.dvi
查看 test.pdf。。。嗯,不错

Comments

Tate TIAN said…
我下回在linux下用的时候过来参考一下

Popular posts from this blog

A Rocky Migration: Moving from docker-compose to Podman and gVisor

I've been running a few containers for several years. They were all running under rootless Docker with a single user. Initially, I planned to  migrate the containers to VMs , but I couldn't get a stable workflow after about two months of effort. Later,  gVisor caught my attention , and I decided to migrate to Podman with gVisor instead. The new plan is to run each container with  --userns=auto  and use Quadlet for systemd integration. This approach provides better isolation and makes writing firewall rules easier. I'm now close to migrating all my containers. Here are a couple of rough edges I'd like to share. Network Layout I compared  various networking options  and spent a few hours trying the one-interface-per-group approach before giving up. I settled on a single macvlan network and decided to use static IP addresses for my containers. To prevent a randomly assigned IP address from conflicting with a predefined one, I allocated a large IP range for my ...

Exploring Immutable Distros and Declarative Management

My current server setup, based on Debian Stable and Docker, has served me reliably for years. It's stable, familiar, and gets the job done. However, an intriguing article I revisited recently about Fedora CoreOS, rpm-ostree, and OSTree native containers sparked my curiosity and sent me down a rabbit hole exploring alternative approaches to system management. Could there be a better way? Core Goals & Requirements Before diving into new technologies, I wanted to define what "better" means for my use case: The base operating system must update automatically and reliably. Hosted services (applications) should be updatable either automatically or manually, depending on the service. Configuration and data files need to be easy to modify, and crucially, automatically tracked and backed up. Current Setup: Debian Stable + Docker My current infrastructure consists of several servers, all running Debian Stable. System Updates are andled automatically via unattended-upgrades. Se...

mkosi: First Impressions

I stumbled upon the Gentoo wiki page for systemd-nspawn , which in turn led me to nspawn.org , mkosi , and later systemd-sysupdate . mkosi quickly caught my eye because it's almost exactly what I wanted to build myself, as mentioned in a previous post . So, I decided to spend my "sysadmin fun quota" on it. Overview mkosi is similar to docker build or podman build , but it's designed for creating full OS images. It focuses on development and testing. For example, much like nix-shell , mkosi can quickly launch a sandboxed shell with a specific distribution and selected packages installed. The systemd project itself uses mkosi for testing across different distros. The re-introduction article  is a great read. Speed Note that this is by no means a rigid benchmark. My setup is an SSD with LUKS and an ext4 filesystem (without reflink support). Building Container Images mkosi is pretty fast. A simple mkosi command creates a fresh Debian image. I used the --incrementa...