In exploring a repertory of glyphs, it's handy to have pictures of them. Given the glyph data, these can be created quite easily using my CAD program of choice, VARKON®. This chapter explores the use of VARKON to draw the glyphs. If you're just interested in seeing the glyphs as drawn, skip it and go to the next chapter, The Occidental Glyph Repertory by Ranges.
Just to avoid confusion, I'll state what might be the obvious. Although one of my purposes in this project was to adapt some of the Hershey glyphs to provide new fonts for VARKON, the drawings here are done as ordinary VARKON drawings. They do not employ VARKON's font mechanism at all.
This web page, and the files linked to it, contain all of the Hershey data files and the complete VARKON MBS code for displaying individual glyphs, ranges of glyphs, and tables of ranges of glyphs. Although I started working on these with earlier versions of VARKON, as shown here they require at least VARKON 1.18A because the MBS code now uses long module names.
Note: If you use any of the code here, use the versions in the files. Do not cut-and-paste from the web page, as it may have XML entities substituted for some of the literal characters present in the files.
For more information on VARKON, see its home page at: http://www.tech.oru.se/cad/varkon/
(Aside: This entire exercise may be seen as an extended argument for Literate Programming, but for the present to have sidestepped one more time into Literate Programming tools, especially as used with XML, would have prolonged a project that already had taken two years too long. Next time.)
Here is a diagram of the overall organization of this VARKON project.
project: hershey
job: main
[Active Module: main()]
|
driver()
|
+---------------------+------------------------+--------+
| | | |
show_one_table() | | plot_all()
/ \ | |
check_table() display_table() | |
\ | |
show_one_range() |
/ \ |
check_range() display_range() |
\ |
show_one_glyph()
/ \
check_glyph() display_glyph()
get_glyph_radius() read_glyph() draw_glyph()
Text Files:
makefile
$HOME/hershey_data/data_glyphs_occidental.txt
$HOME/hershey_data/list_glyphs_occidental.txt
$HOME/hershey_data/list_ranges_occidental.txt
$HOME/hershey_data/list_tables_occidental.txt
$HOME/hershey_plots/
GNU General Public License 2 (gpl.txt)
In the sections which follow, I'll do a depth-first, left-to-right traversal of this architecture by MBS module.
This VARKON project assumes the existence of four data files.
The data file data_glyphs_occidental.txt is the result of processing the Hershey Occidental glyph data as presented in the GNU Plotutils, version 2.4.1. See the prior chapter "The GNU Plotutils' Distribution for information on how this extraction was accomplished. This file must reside in a subdirectory called "hershey_data" of the VARKON user's home directory.
The three data files list_glyphs_occidental.txt, list_ranges_occidental.txt, and list_tables_occidental.txt also must reside in the subdirectory called "hershey_data" of the VARKON user's home directory. These files contain the glyph annotations and the subdivisions of the glyphs into "ranges" and "tables."
The overall subject of organizing principles within the occidental glyphs has been discussed previously in the chapter "Organizing Principles within the Occidental Glyphs."
The annotation of the glyphs (list_glyphs_occidental.txt) has been discussed previously in the chapter "Annotating the Occidental Glyph Data."
The division of the occidental glyphs into "ranges" (list_ranges_occidental.txt) has been discussed previously in the chapter "Dividing the Glyphs into Ranges."
The division of the occidental glyphs into "tables" of ranges (list_tables_occidental.txt) has been discussed previously in the chapter "Dividing the Glyphs into Tables."
The project also relies on the existence of a subdirectory called "hershey_plots" in the VARKON user's home directory.
This is not the place to discuss VARKON in general. Suffice it to say that in VARKON drawings are represented by programs in VARKON's own programming language, "MBS." Drawings may be edited interactively (with changes automatically reflected back into MBS terms), or constructed by writing and compiling MBS programs, or a mixture of the two approaches. I prefer to work entirely by writing MBS programs.
Each VARKON "project" may consist of one or more "jobs." Each job in turn has at any one time an "Active Module" which is its main MBS program. The Active Module for this job is very simple:
GLOBAL DRAWING MODULE main(); BEGINMODULE clear_gm(); clear_pm(); part(#1,driver(0)); ENDMODULE
(If you're running these examples, just create a new VARKON project for them, create a job within it (I call my "main"), and type the above Active Module main() in by hand.)
Outside of the "main" module, all of the MBS modules are handwritten and compiled externally using VARKON's mbsc compiler. The process of compiling them is coordinated in the VARKON mbs directory using the following "makefile":
ROOTS=$(basename $(wildcard *.MBS))
OBJS=$(patsubst %,../lib/%.MBO,$(ROOTS))
all: $(OBJS)
$(OBJS): ../lib/%.MBO : %.MBS
mbsc $*.MBS
mv $*.MBO ../lib
clean:
rm -f *.MBO
rm -f ../lib/*.MBO
# references: info make, Static Pattern Rules
# info make, Automatic Variables
Since VARKON strips comments from the Active Module, I wished to keep it as small as possible and removed the overall driver for the program to a separate, mbsc-compiled, module: "driver.MBS".
This driver() module will put up a window containing several buttons indicating the various things that may be drawn (in VARKON, a drawing can have its own user interface in this manner). There are three general categories of actions, pertaining to tables, ranges, and glyphs. Each may be shown using plain glyph displays or boxed glyph displays.
For each type of drawing, the driver pops up a VARKON inpmt() input window which asks for more information (which table, which range, which individual glyph). For example:
(Note: When a glyph is displayed, it is also plotted automatically. When a range is displayed, all of its glyphs are plotted automatically. When a table is displayed, all of its ranges and all of the glyphs in the ranges are also plotted automatically. This isn't efficient, but efficiency isn't the point here; once generated, these plots (converted to postscript or to bitmapped images) will be what I refer to for the most part.)
The driver is a straightforward example of setting up VARKON windows and buttons and then running an event loop; it isn't worth going through in detail. Here is the source: driver.MBS.
The glyph ranges may be plotted together in three tables which contain at most 8 range displays across and 8 range displays down. Each table fits, with bare legibility (if that) on a sheet of US letter size paper. The MBS module for orchestrating the printing of one of these tables is "show_one_table.MBS".
Here's an example of such a table. As displayed here as a fixed-size image, it is barely readable. As generated within VARKON, however, you can zoom and pan to examine details very closely. It does take a while to generate - from about 80 seconds for table 0 (plain) to about five minutes for table 2 (boxed) on a 900MHz processor based system.
As can be seen below, the module is trivial. It simply calls check_table() to verify that a valid table number was requested and to get its name, and then calls display_table() to display it. The only refinement is that it creates a coordinate system (at (0,0)) in which the table will be displayed (also, as it turns out, at (0,0) in that coordinate system). This allows the table to be repositioned (using display_table()) if that might be desirable later.
[Note: At present, you'll just have to read code for most of this.]
This module, get_glyph_radius.MBS, is the first of three low-level modules which do the heavy lifting. It involves VARKON file I/O and the ad hoc parsing of lines from a file. Because of this, its need for error detection is much greater. I don't pretend fully to have met that need, but there is some attention to it.
The "radius" is the half-width of the display box surrounding the glyph (it is purely a convention of my display; it has nothing to do with the size of the glyph's encoding matrix or with the left and right edges of the glyph as encoded).
This "radius" is characteristic not arbitrarily of individual glyphs but rather uniformly across ranges of glyphs (this assures the evenness of the display of an entire range). It is therefore encoded in the file "list_ranges_occidental.txt". I assume that a copy of this file has been placed in the subdirectory "hershey_data" of the home directory of the VARKON user.
This module, read_glyph.MBS, reads the glyph's data from the file data_glyphs_occidental.txt, a copy of which is assumed to exist in the "hershey_data" directory of the VARKON user's home directory.
Finally (whew), we draw a glyph: draw_glyph.MBS.
Note: Plotting everything takes quite some time.
VARKON outputs "plots" (it is a CAD [meta]program, after all) as ".PLT" suffixed files. These may be converted to Postscript using the "postscript" program supplied with VARKON. From Postscript, these plots may be converted further to bitmapped images in, say, PNG format using tools such as ImageMagick or The GIMP.
Here is a utility, written as a GNU make(1) makefile, which orchestrates the conversion from PLT to Postscript. It is intended to be run from the hershey_plots directory.
(So as to avoid confusion with the "hershey" project makefile, this makefile is called "makefile-convert". In use in $HOME/hershey_plots, it may simply be renamed "makefile" or it may be used with the "-f" parameter to GNU make(1).) Here it is as an ASCII file: makefile-convert
The Hershey glyph data in the file data_glyphs_occidental.txt are, I believe, in the public domain.
To ensure compatability with these data,
the three files I have created which describe them,
list_glyphs_occidental.txt,
list_ranges_occidental.txt,
and
list_tables_occidental.txt
are dedicated to the
Public Domain.
Important disclaimers of warranty
and liability in the presentation of public domain material.
The VARKON MBS programs and the makefile presented here are copyright 2003-2005 by David M. MacMillan and are licensed under the GNU General Public License as described in their source files. A copy of this license is included in the file "GNU General Public License (gpl.txt)."
The rest of this page is copyright © 2003-2005 by David M. MacMillan & Rollande Krandall.
Permission is granted to copy, distribute and/or modify copyrighted portions of this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. A copy of the license is included in the file entitled "fdl.txt" (GNU Free Documentation License).
The computer programs here are also present as files (in the original distribution, at least) and are released, as indicated in those files, under the GNU General Public License Version 2 or (at your option) any later version. A copy of this license is included in the file entitled "gpl.txt" (GNU General Public License).
Note: Those portions of this document which are in the public domain, if any, may be copied freely. The distribution of these public domain portions is subject to all of the disclaimers of warranty and liability noted herein.
This work is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Free Documentation License for more details.
You should have received copies of the GNU Free Documentation License and the GNU General Public License along with this work; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
This work is distributed "as-is," without any warranty of any kind, expressed or implied; without even the implied warranty of merchantability or fitness for a particular purpose.
In no event will the author(s), editor(s), or publisher(s) of this work be liable to you or to any other party for damages, including but not limited to any general, special, incidental or consequential damages arising out of your use of or inability to use this work or the information contained in it, even if you have been advised of the possibility of such damages.
In no event will the author(s), editor(s), or publisher(s) of this work be liable to you or to any other party for any injury, death, disfigurement, or other personal damage arising out of your use of or inability to use this work or the information contained in it, even if you have been advised of the possibility of such injury, death, disfigurement, or other personal damage.
CircuitousRoot & circuitousroot.com are service marks of
David M. MacMillan
&
Rollande Krandall.
Other trademark recognition.
Presented originally by CircuitousRoot.SM