applets, then I'm sorry to disappoint you. I don't like lousy web
pages, as they're very boring. I believe less is more.
Willst Du ein ¡Euro?
Hier gibt's einen. :)
If you like deciphering, try this
C++ and STL
I have converted the STL (Standard Templates Library) documentation,
which is a part of the latest C++ standard, to
TeXinfo format. This allowed me to further convert it to various
other formats, such as Info, Postscript, PDF.
[More information ...].
is a Forth-like language designed by
It think it got its name because of the use of the Postfix notation
(a.k.a. Reverse-Polish notation).
It was designed as a page description language,
suitable for describing page layouts precisely.
That is why it is adopted as an industry standard in the printing
- My first attempt to write a Linux device driver, which
the old /dev/psaux device
found in Linux 2.0–2.4 to
the newest Linux 2.6.
- My second attempt is modused
for hacking the usage counts of dynamically loaded modules
in Linux 2.6.
- I've found and removed a bug
in the PC keyboard/PS-mouse chip (i8042) driver.
The bug can cause a kernel freeze!
Details can be found in my
in the Linux Kernel Mailing List.
- Another bug that I found and fixed in the kernel is in the swsusp
in the Linux Kernel Mailing List
- On 2004-05-28, I found a bug in the 'uinput' module.
Reported as Kernel Bugzilla
Dmitry Torokhov has made a
fix for it.
Disappointingly, the bug is still there in kernel
- The AT or PS/2 keyboard driver
and PS/2 mouse driver
have been ported to user space.
They serve as proofs of the concept that these drivers can be
implemented in user space.
They are still experimental.
- The keyboard driver in Linux 2.6 has a bug that I'm aware of for
a long time: The SysRq key on my notebook doesn't work any more,
although it did in 2.4. I've observed that since 2.6.0.
Eventually, I've found it: the keyboard driver
WRONGLY assumed that SysRq must be equal to Alt-PrintScreen.
The handler also made this wrong assumption, and hence refuse
to invoke the SysRq function unless the Alt key is also pressed.
The fix consists of 2 related by relatively independent parts:
Please refer to
kernel bugzilla #2808
- The input system in Linux 2.6 has a feature that
it automatically detects keyboard and mouse types and
bind them to the suitable device drivers.
Which driver controls which device is virtually hardcoded, and
cannot be modified at run-time.
This is OK if you stick to the kernel's choices of drivers.
It is NOT OK if you want to use some replacement drivers, because
the drivers would then fight with each other for the control of
My serio_switch patch
is a first attempt to fix this problem.
It works on a sublayer below the input driver, and lets you
control which PS/2 mouse/keyboard port is controled by which
The manipulation is done via a procfs interface,
I write tools from time to time to hack Postscript files.
I first begin by modifying (copies of) the Postscript files directly
with an editor to do what I want.
Trimming extra wide magins,
shifting and scaling the printed materials so that it will fit in
the printable area of the printer,
inserting ``watermarks'' into a Postscript file,
When I discover I'm doing a certain operation over and over,
I write a program (often in Perl) to do it.
Over the years, I've written a couple of tools.
This is a ray tracer
written in Postscript. Not my creation. It's only an improvement
on the one written by
Hartman and Heckbert,
which has been floating around in the Internet for some time.
The copyright notice of that program shows a date of 1988.
Now, after 15 years, I've decided to improve it.
First, I changed it so that it now produces colour output.
This was a very easy change, as the original code already does
the raytracing in colours. Only the output routine converts the
rendered picture to grayscale.
The overall structure of the code has not changed.
What I did was to change many parts so that it is more Postscript-native.
(The original one is apparently a
quick translation from C or Pascal or something like that.)
The bodies of some inner loops were optimized, too.
The result is that the efficiency is highly improved, both in terms
of CPU time and memory requirement.
(The file, without modifying the parameters, renders in
under Ghostscript 7.05.3 (driver: x11alpha) running
on Linux 2.4.19
with a Pentium 2.80GHz CPU and 2GB of RAM.
The old version, with a grayscale output, took 141 seconds!!!
That's a 48% increase in speed.)
Last, but not least, I've added DSC comments
to the code, and it
should now be possible to include it as an EPS file in documents.
is one of my most recent creations.
It is a successor of my old, simplistic psfindbb tool.
Function: reads in a Postscript file, invokes
Ghostscript to determine the bounding box of each page
as well as a global bounding box of the whole file,
and then writes out a new Postscript file with
DSC comments describing the bounding boxes found.
(Requires: Perl 5)
is useful to chop off unreasonably wide margins in some Postscript
files. e.g. many publishes want us to submit camera-ready Postscript
files with wide margins. They simply tell us (or TeX) that he paper
size is ``US letter'' or ISO A4, and make the margins wide enough
so that the contents can fit on a B4 page with decent margins. These
margins are, unfortunately, too wide for
printing on letter or A4 paper.
By trimming these margins, we could make the main text larger, lessening
the stress on the eyes. In many cases, we could even fit 2 logical
pages onto one A4 page without a reduction in the resulting font size!
(To fit 2 pages onto 1 sheet of paper, use psnup or
is another recent creation.
It adds text around the rim of the bounding box of each page
of a Postscript document. Quite useful to add information about
the source of a document. Needless to say, psrealbb can
be used as preprocessor to generate a good bounding box before
using this program. The text rim is set with TeX using Postscript
fonts. Why TeX? For the quality---I don't want to reinvent
line breaking and hyphenation algorithms, nor the code the handling
of font metrics. So, I invoke TeX. To make the resulting file not
too bloated with fonts, I stick to Postscript built-in fonts.
(Requires: Perl 5, a TeX installation (tested on teTeX))
is a recent rewrite of my older tool under the same name. The
older version was a shell script and invokes Ghostscript to do
most of its work. This rewritten version is a self-contained Perl
script. It doesn't require Ghostscript. What does it do? You
should have guessed from its name. Unlike other converters, this
converter does NOT decompress the JPEG file contents. Since
Postscript Level 2 has built-in JPEG support, we just need to add
a Postscript wrapper around a JPEG file. The decompression and
rendering of the JPEG contents are thus deferred and delegated to
the Postscript interpreter. The advantage is that the JPEG data
is kept intact through its tranmission to the Postscript
interpreter. So, more compact file size; reduced loss of
precision. Disadvantage: it takes the Postscript interpreter more
time to handle the print job.
METAPOST is an interesting tool for drawing diagrams with precision
and quality. Although, METAPOST generates Postscript as output,
the resulting files are is not standalone.
They often reference TeX fonts, which aren't included in the file.
This means you cannot properly preview the diagrams with
Ghostscript and the like.
Neither are the DSC comments generated good enough for
to display it in a window
of appropriate size.
This Perl script is meant to iron out these discrepancies, so that
you can view it nicely with Ghostscript (or gv) and print it on a
printer (when the bounding box fits on the printable area of the
printer). It is intended as a previewing helper.
Why not PDF
B'cos I don't like it. There are a couple of reasons for that.
The most important reason is that PDF is not a programming language like
It is just a dumb data format, with no programming constructs,
where the fun lies.
You cannot write a raytracer or web-server in PDF.
In this sense, PDF is a retarded version of Postscript.
Moreover, PDF is in large parts binary,
making it difficult to hack an existing PDF file to get what you want.
Apparently, Adobe has for some time kept the PDF format as a secret,
so that the only possible way to view and process a PDF file is
to use Adobe's Acrobat [Reader].
This is what I hate.
No interoperability with other softwares.
Yes, the PDF format is nowadays open,
making it possible to write PDF tools,
including non Adobe PDF viewers
which won't render non-Type1 fonts uglily on screen.
(It is said that this is Adobe's conspiracy
to promote sales of Type1 fonts,
whose format Adobe has again kept secret for some time.)
But being a binary format means that I still can't easily modify it
with a text editor. This is bad news for hacking.
PDF has an advantage that it has an index table (not in the sense of
the index of a printed book),
so that any page of the file can be accessed pretty quickly.
Postscript only provides (or even mandates) sequential access,
making it slow to jump from page to page.
However, this disadvantage has been alleviated by the
Document Structuring Conventions
, which is---you guess---specified by Adobe.
It is an extension of Postscript to make it possible for
software to process indivdual pages of a Postscript file
easily and reliably.
Many tools (such as
take advantage of this extension to let the user
select pages to print/view,
put multiple pages onto on sheet to save paper,
I have been using similar tools for 10 years!
The other so called "disadvantages" of Postscript can be similarly
amended by introducing backward-compatible extensions.
e.g. hyperlinks can be added by the
thing designed by Adobe itself to facilitate adding
hyperlinks to Postscript.
Some people simply believes that Postscript is obsolete because of PDF.
Well... maybe if they believe whatever they read (from Adobe).
If Postscript is (was) really being deprecated by PDF,
how come Adobe continued to design Postscript 3?
Why does Adobe still provide and maintain
for the Windows and Macintosh platforms?
(On Unix, Postscript printers works basically plug-and-play, without
is also a Turing-complete language.
That means you can write any programs in Postscript.
Programs that have been written in Postscript ranges from
simple graph plotters to
It is fun to write programs in Postscript. It is not difficult at all.
The syntax is very simple---comparable to LISP. Yet, you can already do
a lot by know very little. That's where the fun lies.
If you want to learn Postscript, you may be scared away
by the PLRM
(Postscript Language Reference Manual),
book (ISBN: 0201379228).
That book is meant to serve as a
complete and authorative reference.
Like a 1000+ page English dictionaries,
it is not really meant to be read, but to be used as a tool.
Even if you have lots of time to kill,
I still won't recommend reading it from cover to cover:
there much more funny things to do.
Most Postscript programmers including me look up information
from this manual from time to time.
The hardcopy would be too bulky and heavy, I suppose.
I've only kept the
Yes, I have gone over this manual
(revision 2, covering only language level 2) once,
but I didn't read word by word.
I just skimmed over it, reading only details that interest me at that moment.
To start learning Postscript, I recommend reading
Postscript language tutorial and cookbook,
If you're guessing that there must also be a
Green Book, you're right.
Postscript language program design, ISBN 0-201-14396-8.
These are the 3 ``primary'' books I used in teaching myself Postscript.
Many people also recommend beginners to read
``Thinking in Postscript''.
The book is now out of print, but the author has generously
made it available online as a
I have heard a lot of good comments about it.
My comments on this book is that it is more geared towards
people who already know programming well
(esp. in C or other procedural languages).
For beginners, it's a bit tough, unless you're already an excellent programmer
in other languages. However, this book should be helpful for
intermediate programmers in Postscript, and useful for experts for revision.
Many of these books suggest the learner to experiment their
Postscript code on a Postscript printer,
and examine the printout.
I recommend against this.
That's is unfriendly to the environment
(and your wallet, too!).
A more practical way to learn Postscript is to use a
Postscript emulation program, such as
is free and is available for many platforms
(Linux, Windows, Solaris, AIX, ...).
Experiment your Postscript code with this,
and you can see the results on your monitor, instead of printouts.
For an editor with some Postscript support (e.g. syntax highlighting),
GNU Emacs version 21 or higher.
I personally do not like XEmacs,
partly because it is not 100% compatible with GNU Emacs.
Even the configuration file is in many ways not compatible.
If you know Emacs-LISP (and I do),
you could write your config file so that it suits both variants of Emacsen.
But why waste time on that?
Many starters misbelieve that XEmacs supports
X11 Window System
and GNU Emacs doesn't.
So, they chose XEmacs to start with.
(This includes some people who,
after being amazed of how many things I can do with Emacs
with just a few keypresses,
accepted my recommendation to try out Emacs.
When they have problems with XEmacs,
they come to ask me,
and I'll simply give them my standard answer:
Sorry, that's XEmacs, and I'm only familiar with GNU Emacs.
I don't have no idea how to solve your problem with XEmacs.)
This is certainly a wrong perception.
GNU Emacs has been working in X11 as a separate window (not inside an xterm)
since around 1993.
Last updated $Date: 2004/06/16 11:36:16 $ (UTC)