by Richard G. Baldwin
baldwin@austin.cc.tx.us
Baldwin's Home Page
Dateline: 08/23/99
One of the great things about XML is that XML has something for everyone. Although XML is a technology in its own right, the purpose of XML is to solve other people's problems. Without those problems to be solved, XML is simply an empty specification.
An interesting article on SVG caught my eye this week and caused me to decide to temporarily put my series of articles on "XML and Java Objects" on the back burner. I'll probably resume that series in the next article.
The computer escaped from the mainframe's "glass house" around 1971. That was in the dark ages of computers (before the invention of the personal computer). Prior to that time, computers had operated only in large air-conditioned structures which typically had a hall with lots of windows so that the curious could peer in (hence the name "glass house"). Around 1971, DEC, Data General, Raytheon, and several other companies introduced what became to be known as the "mini computer."
A mini computer was typically housed in a rack that fit into a standard 19-inch electronic cabinet along with other assorted items such as punched paper tape readers, magnetic tape drives, and disk units. It wasn't necessary to operate these computers in the large air-conditioned glass houses, although a little air-conditioning was always a good thing (especially in Austin, Texas where I worked at the time).
To make a long story short, the company of which I was a cofounder designed and sold a line of "remote batch terminals" built around a minicomputer manufactured by the Data General Corporation. Later on, when Motorola introduced the 68xx line of microprocessors and associated chips, we began using them in place of the minicomputer.
A remote batch terminal (RBT) was a device that made it possible for computer users in outlying offices to submit batch data processing jobs to a central mainframe via the telephone lines and to get the results back via the same telephone lines. There was often a significant time delay between submission of the job and receipt of results because jobs were queued on the mainframe using a variety of criteria. My data-processing jobs seldom had top priority in the queue.
This characteristic of submitting a job into the scheduling queue and then getting the results back sometime later led to the terminology "batch processing." Another way to describe the batch process is to say that it was not interactive with the user as most of us are accustomed to today.
The RBTs that my company built and sold contained a number of peripheral devices including punched-card readers, high-speed line printers, magnetic tape drives, disks, and plotters.
In those days, the primary graphic output device for computers was an ink-and-paper plotter. These devices were built by CalComp, Houston Instruments, and others. (It seems that neither of these companies is still in business, but there are a number of companies on the web that still sell supplies for existing plotters.)
Plotters made line drawings on paper (or some similar material) using a stylus that dispensed liquid ink. The early plotters were very dumb devices. In order to draw a picture, you simply caused the pen to move along in small X and Y incremental movements. Generally the smaller the incremental movement that the plotter could support, the better was the quality of the resulting drawing. Software was required in the driving device to translate the desired drawing into incremental plotter movements.
Until we introduced our line of RBTs, the common configuration for such a plotter was to operate as a stand-alone device, connected to a magnetic tape drive in a mainframe computer center. Software on the mainframe computed the incremental movements required to produce a drawing and wrote those movements onto magnetic tape as a series of incremental plotter codes. This magnetic tape was then mounted on the stand-alone plotter system and the incremental plotter codes on the tape were transferred to the plotter.
I was a co-inventor of the first (to my knowledge) commercially viable system that made it possible to locate the plotter physically distant from the mainframe and to support the plotter using information transmitted via the telephone lines. For this purpose, I wrote software that ran on the mainframe to generate and transmit a series of X and Y vector values to the RBT. I also wrote the software that ran in the minicomputer in the RBT to convert those vector values into incremental plotter codes and to deliver those plotter codes to the plotter.
Because of the need to provide graphic output in many different technology areas, there were many different kinds of customers for our remote plotting terminals. They were used for such diverse tasks as the generation of geologic maps, the generation of logic diagrams, and the generation of masks used in the manufacture of semiconductors.
One of our larger customers was Motorola. Motorola used very accurate and expensive plotters attached to our RBTs to generate masks used in the design and manufacture of semiconductor devices.
That's enough background, let's get to the point.
According to Janus Boye, "Most graphics on the web today are in bitmap formats (e.g. JPEG, GIF, and PNG), and thus contain information about every pixel in the image. Vector graphics, on the other hand, describe shapes and paths only, which is more efficient."
With all the hype about animated GIFs and such, many people have forgotten about the importance of graphics composed of lines. The reality is that virtually all engineering drawings are line drawings. Most and probably all computer-aided-design (CAD) software produces line drawings. Without drawings of this sort, we wouldn't have any automobiles, computers, telephones, or any of the things that we have come to take for granted.
The significance of vector graphics is that it provides a very efficient way to transmit line graphics via electronic communication channels. Interestingly, as I read about the efforts of the people currently working on the SVG standard for XML, I find that they are still dealing with the same issues that we dealt with back in 1971.
I'm not going to go into a discussion of the advantages and disadvantages of vector graphics as compared to bitmap graphics. Rather, I will refer you to the article in webreview.com entitled "SVG Brings Fast Vector Graphics to (the) Web." The article does a very good job of making such a comparison.
I will also refer you to SVGView, a tool from IBM "to parse, process, and display SVG files on any XML-enabled Web browser." According to IBM, "The viewer enables Web professionals working with SVG files to preview their forms or images."
If you really get turned on by this article, you might like to read the W3C specification. You might also be interested in an appendix entitled "Introduction to SVG Requirements," According to the W3C, this appendix "contains the extensive list of Design Goals and Detailed Requirements which were drafted initially before the SVG specification was written and then revised as the specification developed."
|
coming attractions... |
As I mentioned earlier, in my next article I will probably resume the discussion of "XML and Java Objects", showing you more of the Java code that can be used to create the XML file based on the contents of the objects stored in the Vector.
Trying to wrap your brain around XML is sort of like trying to put an octopus in a bottle. Every time you think you have it under control, a new tentacle shows up. XML has many tentacles, reaching out in all directions. But, that's what makes it fun. As your XML host, I will do my best to lead you to the information that you need to keep the XML octopus under control.
This HTML page was produced using the WYSIWYG features of Microsoft Word 97. The images on this page were used with permission from the Microsoft Word 97 Clipart Gallery.
231250
Copyright 2000, Richard G. Baldwin
baldwin@austin.cc.tx.us
Baldwin's Home Page
-end-