Mac LaserWriter PageMaker - how I got into computers
I passed the entire gymnasium 1978-1984 without computers. There was a room in the top floor with some machines using Basic as programming language, text screens and audio cassette memory, but they didn't get my attention.
But then, in 1984, when I started social science at the University of Zurich, there was a brand new Macintosh and a LaserWriter in the institute everybody could use. It did not have much programs, but it did have MacPaint.
This program did not only have painting tools but allowed to write text in many fonts in huge sizes. The editing was complicated and the typography was jaggy (72 points per inch) but you design a poster and print it out with the LaserWriter.
Then everything happened fast. PageMaker arrived 1985 on a floppy disk which was barely copy protected and opened the world of desktop publishing. Every newspaper layout of that time could be created on a Mac, provided you had enough memory and time. The files were big and the program slow.
I remembered producing in PageMaker a daily newsletter for a medical congress, on of my first paid jobs: A young doctor wrote all articles in the morning, I layouted them in a classic 3 column layout and added some graphics the doctor managed to scan in a lab (scanners were rare at that time), and then we waited. Every page took half an hour to print. It was fun, but beware correcting all errors before printing!
Then QuarkXPress came out proving that a layout program does not have to be more complex than word processing, and I adopted QuarkXPress until it became too expensive.
If you do not layout as your main occupation, there are not many options to make decent layouts.
During ten years, I adopted Pages. The book mode and the support for styles allowed descent layouts for print. I did many posters, catalogs, postcards and covers with Pages. I even managed to build a properly print workflow by converting RGB PDFs to CYMK PDFs with QuickTime filters. But then Apple decided that Pages was too complex for the masses and killed it. The new Pages is a joke.
Currently, if you do not want to buy InDesign, Affinity Publisher is an option. I did some brochures and posters and did not yet break a limit. However, if you do not use it often, you forget how to use the tools. It does not have the intuitive tools that Pages had.
This said, layout took me to the computers and then also to programming. I bought an early book on PostScript "Understanding PostScript programming" by David A. Holzgang. I could follow the code until a certain point, but it was only theoretic exercise. I had no LaserWrite I could use as a terminal to program PostScript.
Graphics and programming took then different ways. I have used many programming languages, always related to a specific context to solve a problem.
I used Excel macros from the beginning, to create a timeline sheet for the sound mixing of a movie, later to calculate with timecode. Then I programmed databases in Filemaker, learnt C++ the hard way to write plugins for Photoshop and Avid MediaComposer, had fun with Realbasic to write Belle Nuit Subtitler and started into the web in about 2000 programming PHP/SQL and later Javascript, too.
While I have the capacity to mix competences of different fields (science, movies, politics, statistics), I often program from the ground up, not using libraries, but trying to understand the underlining basics.
This was the case first on the timecode add in, where you need a deep understanding how time calculation works. This includes also the hard parts like drop frame in the NTSC world.
Later, when I wrote the wavescope and the vectorscope for Avid MediaComposer, I applied the basic formulas for color conversion between RGB and YCbCr. The vectorscope does not only show the video signal, but has also a graphic overlay with lines, circles, letters and numbers. I had no idea how I could call the computer graphic routines to write them, so I wrote my routines by hand and created a bitmap font.
template
void sfxImage::DrawString(int x, int y, char *s)
{
int xpos = x;
while (*s)
{
xpos = DrawChar(xpos,y,*s,true);
s++;
}
}
The next step to build something from the ground was Sofawiki. I had have built websites from 15 years, first handmade HTML, then Filemaker generated HTML, then PHP, and I found website more and more complicated, missing flexibility, and handling of MySQL risky. On the other side, I saw how easy editing and content creation was on Wikipedia. So I built with Sofawiki a CMS using wikipedia syntax, but with a file based database.
When you create a new project, you must make some design decision that have long term effects. For example, I decided that Sofawiki has a revision system from the beginning. Every time you edit a page, you create a file with the revision number as filename that goes into the /site/revisions/ folder. That file is never deleted. On that, you create indexes which record the last version of the file, the name. This design decision made the Sofawiki very robust. Whatever happens, you can reconstruct the site content from the revision folder.
Another decision I failed to make at the beginning was to use Unicode. I started with Latin1 and moved to UTF-8 with version 0.5. But there are revisions created older than 0.5. This means that the encoding must be a field in the revision and the code now must always check for the encoding.
There as was mixed decision how to parse the wikitext. Wikitext is a mixture of formatting codes (bold, italic), patterns (recognising a link) and template structures and exotic constructions like tables and ambiguities on paragraphs and lines. I started using regex pattern as much as I could and work through the rest with normal PHP code. I used a state machine, going back to regex and going forward again. But I think I will finish using a pure state machine again like we do it here for PostScript.
Scaling is another issue. Sofawiki worked well for about 10 000 pages, which is not bad, but get very slow behind. When you search through a 1000 files, this can take 25 seconds. So I thought about aggressive caching which is possible with revisions. You never have to check a revision twice. I thought about trigrams filters, then bloom filters. I finished building an entire database system with its own language (Relation) which itself needed design and parsing.
At some time you get a very complex system. Optimisation makes code less readable. Sofawiki is still very easy to install and duplicate (just copy the folders), but the file based database approach has its limits. You can also get transportability with SQLite which is a fully SQL-capable database just in one file. So the next step will be to reduce complexity and move all indexes into SQLite.
But we are not here to talk about Sofawiki, but to write a PostScript interpreter in Javascript. What are our design decision:
- Write the interpreter as vanilla Javascript in one includable file.
- The interpreter function reads Javascript code and returns one or more images (as in a Canvas, as PNG, as SVG, as PDF). It will properly return errors.
- The editor function shows a PostScript editor, displays exportable images. It shows also the stack, the dictionary, the image state and the heap for debugging.
- The interpreter implements PostScript as much as it is created by humans and as it is shown in the exercices. It may leave exotic operators and most of font creation handling (anyway we will not be able to access encrypted Type 1 fonts). This said, operators can easily be added.
- The coding style should be functional as far as it is possible with PostScript. Most operations on graphics are side effects either on the current path or on the raster images. None of these should be global, but included in the context object.