In the first part of my interview with Don Iannitti, President and CEO of Document Systems, Inc. (DSI), we learned about the impetus behind the birth of DocMagic. In this second part of my interview, Don goes on to describe the evolution of the DocMagic technology.

Developing DocMagic

Tell us about developing DocMagic.
Don: Around the time we were determining how to program forms for our new software, an office equipment representative walked in and dropped off a new word processor. At that point nobody even knew what a word processor really was. Word processing technology was just starting out and this rep's company saw the potential and initially began distributing word processors free of charge. In those days, anything entered into the word processor was saved in a proprietary file format. So, once companies started to work with the machines and enter their documents, they were committed to purchasing them.

We went ahead and laid out some of our original worksheets and created forms using the new word processor. The system had unique functionality in that you could create a data field on your document to fill data in the form, and your printer would follow you around the form as you typed. You would type a character and the printer would type that same character. The program really nailed where your data was going to hit on pre-printed forms. As soon as the rep was gone, I called our lead developer over to take a look at the new system and we decided that this was the way we are going to program forms. In a very short period of time, we had the program doing just that, paving the way for the elimination of the grid-based programming generally being employed at that time.

Grid-based programming involved laying a grid on the form and basing input on x, y coordinates. The coordinates would be entered into the program, giving a particular position, and the program would subsequently print there. But, because printing is never precise, the form would never be printed precisely the same way twice. One method was to make a printed alignment mark as a guide on the form. Coordinates would begin at that point, and relative to that point, the printing would be accurate. However, the next problem was that many of the lender-specific forms were duplicated on copiers. Back then, cutting edge copier technology took a picture of the form-a light popped and the copier snapped a picture-which, over time, had the effect of blowing up the document image. There was a very slight percentage increase in the form every single time it was photocopied. So from one set of photocopies to the next, a variation of size was introduced. Even though there might be a printing alignment mark on a given form, the form and coordinates were still different because everything expanded. A program-based method of filling forms just couldn't work over time. The programmer would have to adjust the form every single time it was reproduced. This meant that when you had a database of 30, 40, 50,000 forms, it would take an army of programmers just to keep them running. The program we developed solved this whole problem.

Could you expand on the method your team developed?
Don: Our new program solved that problem by enabling you to go directly into the form and adjust it. We created the closest thing possible to a WYSIWYG-type application before graphical user interfaces (GUI's) had been developed. Everything was still text-based. We couldn't really do WYSIWYG, because the text was different than what you'd see on the form, but it really was as close as you could get to it back then.

Once you were operating in that mode, when your cursor would move, the printer would move. If it was told to go down by 1/16th of an inch, moving the cursor from here to there would cause the printer to move by that 1/16th of an inch. It was a very delicate program that had to be well written to get the printer and cursor to move around in synch that way. It wasn't trivial at all.

Ultimately, wherever the user typed was where the form fill was going to hit. Competing technology required the user to stop six or seven times throughout a 28-inch Deed of Trust to realign. Our new process just went straight through. The user hit 'print' and it would just spit it out, perfectly.

How long did it take to develop the program? Were there a lot of sleepless nights?
Don: There were many hours of work involved and once we got the application itself done, programming the actual forms took additional time. We pounded out the initial batch of core forms, and when we landed our first couple of clients, it took a substantial period of time to get those client-specific sets of documents functioning. Getting a set of documents back then took all day.

There were also many issues we hadn't noticed. Speed issues, for example. We didn't notice it during programming, since that's sort of a vacuum, but as soon as we began producing for more than a few clients, speed showed itself as an issue. The very nature of the interpretive file we were creating meant it took some processing time to populate the form with data. For instance, if the form was printing and it called for the lender name, the application would ping the lender database, find the lender, pick the proper name for the form and then continue. It was rather amusing. If we had numerous sets printing at the same time, everybody would basically hit "go" on their forms and then we'd all sit back and wait.

Was this a limitation of the technology?
Don: Well, yes... but remember, PC technology was brand new. The Pick operating system was one of the first-if not the first-multitasking, multi-user operating system. It was a desktop PC, yet we connected it to 4 or 5 other desktops terminals, effectively slicing CPU usage and dividing it amongst these users.

At that point, we started looking for things that needed to be optimized, like print speed, and we created the concept of pre-processing document requests. What that means is that a process creates a print-ready PCL stream before the forms actually are printed, so there would be no need to look up files while printing was underway. This increased our document processing speed considerably. The entire interpretative aspect was done in a single process. DocMagic uses the same technology today: A print-ready stream of data is created at process time so when our client presses Print, printing is as fast as the printer can accommodate.

It sounds like you were basically creating a whole new technology. That must have been exciting!
Don: It was more than exciting. The whole period was evolutionary. When the first laser printer hit the market - probably around 1989 or 1990 - we immediately bought one. Our office was so small; we didn't have anywhere to put it. We had to place it in our reception area, get a long parallel cable and plug it into one of the computers in that room. When we laid out our first laser form and put it to print across the room, it was like a light bulb went on.

That was remote printing, right there. We knew immediately that this would be huge for our business. Now we had a method for eliminating photocopies. We had drawers filled with thousands of photocopies. Why? Because the solution to the problem of bigger images with every copy was to print an enormous quantity every time you did so. That way you'd only have to deal with the problem once in a while. We still saw this as a problem, even though it only took a little time to go into the form and push things down a little bit. But then, sometimes you lost the original, and you'd have to shoot a copy from a copy… all over again. The laser printer clearly represented a solution to that problem and brought with it, the ability to print remotely here, there or anywhere.

We realized that what we had done in the office could conceivably work across a phone line. So, we immediately started to experiment. We hooked a modem to a phone line, hooked the printer to the modem, and we were able to successfully get a set of documents to print over the phone. Now, this was not Internet-level networking. At the time, there were some 1200 and 2400 baud modems, external models that you'd connect to the PC, and they were slow. But it was the beginning.

The Guiding Concept...

Please join us in the next issue of The Compliance Wizard for Part III of my Interview with Don Iannitti, where he talks about the company's guiding concept.

Melanie A. Feliciano is Assistant General Counsel of Document Systems, Inc. and a member of its Compliance Department.