I am the Nate in EnVisioNate

The PostScript Interpreter

This is a replacement for the GhostScript Open Source system as far as that system parses and interprets PostScript.

It is not used to actually create PDF files, as GhostScript does. In this case, I've focused on creating a PostScript interpreter that you can actually read and understand by looking at the source code.

Using a dedicated approach to pristinely clean software, in a well organized and robustly architected system, interpreting PostScript language source files is now easy to implement, and especially, simple to understand and to extend to your own needs.

I've been developing software since 1979. At this writing that is 46 years ago.

My first program was computer graphics - I mean number graphics, not the stuff that fancies other stuff up, but the graphics that helps engineers and other geeks convey information (data) about something.

It was written on cards at a key punch machine, and yes, I did trip and fall in the hallway on the way to the card reader, and, of course, my cards went flying everywhere. 

In 1979 I was totally amazed at the speed of that card reader, and at the incredible room sized mainframe behind the wall.

And, in 2025, I am still completely amazed at the speed of computer software, and the machines that process it, even if they are almost infinitely smaller.

In 1979 we used to take a printout of our software and roll it down the hall. Then, on our hands and knees, read it top to bottom to try to figure out why the computer was kicking it out with a bug.

I thought helping out the girls in my class this way would get me an "in" with them. Alas, no such luck. Yes, I invariably found their bug(s), but I had to keep trying for that date. I was relegated to Saturday nights in the computer room, oh well, I guess I was just too much of a nerd.

In 2025 I'm still debugging software that way. At least in the sense that I'm reading it with the utmost focus. The modern and incredibly powerful debuggers today sort of make a mockery of reading printouts on your hands and knees, but what I really can't believe is that so many professional developers these days can't be bothered with debuggers, or at least with accommodating debuggers in how they write their software.

In my first career post after school, I was in the US Defense Engineering field working with IBM Mainframes, and DEC Vax minicomputers. I became adept with the PL/I language and using it, created more data graphics and numerical analysis tools as well as a T_EX like markup language that emitted Adobe PostScript language files to our PostScript printers. Brand new technology at the time.

Those were my first software "children". I have always considered the software that I write as offspring, important contributions to the world in some way, I hope anyway. I still believe the same and hold the software this particular website is related to in exactly the same regard. I will never abandon it, until, that is, I assume room temperature.

With the software products herein, and especially by demonstrating how they are built, I hope that I can influence, at least in some way, the adoption of some better practices in software development.

Though I can see horrible problems in Open Source software, obviously because it's visible and available for my perusal, I strongly suspect that the vast majority of software, Open Source and proprietary, has these problems. Indeed, every "closed source" system I have come across in my professional career, including a lot of commercial and government efforts, has been so horribly written and architected, I was usually stunned that it ran at all. Actually, In pretty much every case, it didn't really run until I rewrote it.

The CursiVision Print Driver is part of my CursiVision commercial product.

This driver prints any document to PostScript, then launches the CursiVision application which learns exactly how to sign that document through configuration. The system captures signatures using an electronic signature pad, then saves the document in a highly configurable manner. Following that all sorts of document management processing steps can occur.

This driver is perfectly suited to front-end any process you may want to develop by printing to the PostScript language file, and then launching software which would use the PostScript Interpreter.

I talk at length about some of the possibilities this may support, but as a concrete example, if you had a process that needs to scan documents for content or data, you could set that up easily with this driver and the other tools described here.

The Font Manager

This is a replacement for the Open Source freetype system.

It was born as the font rendering component of the PostScript interpreter. In keeping with a consistent architecture, it is a COM (Component Object Model) object whose implementation details are kept separate from that project.

As a COM object - you can easily use it, off the shelf, in any software you may be writing that needs to render text in any font available to you.

Included in the repository is a clear and concise example implementation that will show you how easy it is to get full featured font management and rendering up and running.

The Renderer

While struggling to understand rasterization by deciphering freetype and other implementations of it, I came upon a very nice surprise indeed!

Rasterizing the text was always in the back of my mind while I was trying to prepare everything else that would use it.

I finally got all of the contour rendering stuff down by implementing the font internals documentation to create the glyph outlines. That was quite a journey and an interesting one at that. But now, how to rasterize ? hmmm

Well, before long I came upon that surprise!!