Willst Du ein ¡Euro?

Cryptography

C++ and STL

Hacking Linux

• My first attempt to write a Linux device driver, which adds back 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 posting in the Linux Kernel Mailing List.
• Another bug that I found and fixed in the kernel is in the swsusp feature. See my posting in the Linux Kernel Mailing List for details.
• On 2004-05-28, I found a bug in the 'uinput' module. Reported as Kernel Bugzilla ID 2786, also in LKML. Dmitry Torokhov has made a fix for it. Disappointingly, the bug is still there in kernel 2.6.7 (2004-06-16).
• 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. [details...]
• 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:
  • A patch in drivers/input/keyboard/atkbd.c to make the input system distinguish the SysRq and PrintScreen keys.
  • A patch in drivers/char/keyboard.c to make the keyboard handler respond to SysRq instead of Alt-SysRq.
  Please refer to kernel bugzilla #2808 for details.
• 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 the devices. 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 serio driver. The manipulation is done via a procfs interface,

Postscript

Tools

• psrealbb 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)
• pscrop 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 a2ps.)
• psrimtext 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))
• jpeg2eps 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. (Requires: Perl5)
• mpiron 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 gv 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.

Ray Tracer

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 Postscript. 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 (e.g. XPDF) 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 a2ps and gv) take advantage of this extension to let the user select pages to print/view, put multiple pages onto on sheet to save paper, etc. 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 pdfmark operator/extension---another 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 printer drivers for the Windows and Macintosh platforms? (On Unix, Postscript printers works basically plug-and-play, without special drivers.)

As a programming language

Postscript 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 ray-tracer and web-server (PS-HTTPD) .

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), a.k.a. ``The Red Book''. a 900-page 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 PDF version around. 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 ``The Blue Book'' ( Postscript language tutorial and cookbook, ISBN 0-201-52372-8). If you're guessing that there must also be a The Green Book, you're right. That's 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 PDF file. 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 Ghostscript. GNU Ghostscript 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), consider using 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 the 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.