Why We Didn't Give You WYSIWYG troff
nils-peter.nelson
I've resisted responding up until now to the question
"Does anyone know of a WYSIWYG troff?" but guess I
owe the world an explanation, as far as Bell Labs
is concerned.
First, making the current troff WYSIWYG is technically
infeasible, due to the way it buffer up text internally,
then spits out when it sees fit.
Something that is new, but generates troff as output is
feasible, and there is a program called snaz internally
in Bell Labs that more or less does this. It was designed
for the Blit/5620/630/730 terminals.
But the *real* reason is...
A while ago a large internal documentation organization
inside AT&T had a shoot-out between troff and one of the
well-known Unix WYSIWYG formatters on a Sun 3. Two different,
trained groups were given a large document to produce,
one with troff, the other with WYSIWYG. The troff group
finished substantially ahead. The experiment was deemed
a failure (since it was supposed to show WYSIWYG improved
productivity) and repeated. Same result.
Subsequent analysis indicated that the WYSIWYG group spent
a lot of time "prettying" up layout at an early stage
of authoring; a good deal of this effort was undone by
subsequent changes to the text. The troff group was more
or less forbidden to address layout; they used an
SGML-flavored set of macros, based on -mm, that automatically
determined fonts, header placement, page breaks, etc.
The credit goes, really, not to troff, but to a well-defined
batch markup language that allows authors to concentrate
on *content* and leave layout to the software.
Given this fact, and that for those who really want WYSIWYG
there are some 50 commercial alternatives, we elected not
to pursue WYSIWYG troff. Instead, we capitalize on windowing
systems (layers, mux or X) to do screen-based editing of
batch troff in one window, with troff output in another
window. This gives the "in-the-office" feedback authors need
without true WYSIWYG. (Rick Beach of Xerox described this
difference cogently in Science several years ago.) The software
here is proof/xproof and xtv (based on xditview).
We did, as you may know, do a WYSIWYG pic, called Picasso,
because drawing is exactly the opposite case-- for
most illustrations object placement is easy and natural
in WYSIWYG, awkward in batch. But our conclusion for text
was: let the software determine the layout, not the
author. An intentional result of this is a very
consistent document appearance across geographically
disparate groups. (Style is not as easy to enforce with
WYSIWYG systems.)
I'd enjoy seeing responses, since this is an important
issue to all of us. Lest I be misconstrued, there is
no doubt that WYSIWYG is more productive for advertising
layout, for pictures, and anytime form is more important
than content. But for the sort of industrial-strength
documentation we do at AT&T, batch markup languages
appear to have an advantage.
Robert Hartman
>
>A while ago a large internal documentation organization
>inside AT&T had a shoot-out between troff and one of the
>well-known Unix WYSIWYG formatters on a Sun 3. Two different,
>trained groups were given a large document to produce,
>one with troff, the other with WYSIWYG. The troff group
>finished substantially ahead. The experiment was deemed
>a failure (since it was supposed to show WYSIWYG improved
>productivity) and repeated. Same result.
>I'd enjoy seeing responses, since this is an important
>issue to all of us. Lest I be misconstrued, there is
>no doubt that WYSIWYG is more productive for advertising
>layout, for pictures, and anytime form is more important
>than content. But for the sort of industrial-strength
>documentation we do at AT&T, batch markup languages
>appear to have an advantage.
I suspect that when all is said and done, troff with a previewer yields
faster turnaround for large documents sets, and requires fewer hand
motions than the leading WYSIWYG publishing system (WPS) for UNIX.
Now, if I could only make last-minute corrections and fix page breaks in
the previewer--and then write back my updated file!
When it comes to formatting consistency, the issue really isn't WYSIWYG
vs. batch. It's really a question of where the style catalogs are
defined. In troff, the standard styles (macros) are maintained in a
separate, centralized, unwritable file. There is no reason why a
WYSIWYG system couldn't do likewise, and source in a style catalog as
instructed in each file containing marked-up text. There is simply no
reason why the leading WPS has to duplicate all that formatting data in
each and every uneditable binary file. I could almost understand if
the binary files were smaller than the equivalent troff input files,
but they're HUGE!
A WYSIWYG interface on top of a text-based command/markup language like
troff would give the user access to the best aspects of both styles of
input. Maybe that's why people are asking for it.
-r
Herman Rubin
..................
> I'd enjoy seeing responses, since this is an important
> issue to all of us. Lest I be misconstrued, there is
> no doubt that WYSIWYG is more productive for advertising
> layout, for pictures, and anytime form is more important
> than content. But for the sort of industrial-strength
> documentation we do at AT&T, batch markup languages
> appear to have an advantage.
I disagree that at least approximate WYSIWYG is more important
only when form is more important than content. If one is producing
a document, or even a rough draft, in a language where non-ASCII
characters are many, and where such things as subscripts and
superscripts are needed, it is important to see what the content
is at creation time. In some cases, this could be done with only
two fonts available at a time, but this will definitely be a minimum,
and with the other requirements, maybe more. We currently use TeX
or LaTeX, which is far more human-readable than troff, but the text
is frequently misinterpreted and requires at least previewing to
read. Modularizing this can be done, but is time-consuming for the
author.
We are talking here about the time of the investigators and researchers
in communicating their findings. Typing is far easier and quicker than
writing; I would have no problem getting a secretary to convert a
handwritten version into TeX. But with proofreading, etc., it would
take far less of my time if there were a not-quite-WYSIWYG means of
producing a document with a built-in translator to a typesetting
language like TeX or troff.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hru...@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
Guy Harris
>SGML-flavored set of macros, based on -mm,
Ah. I've somewhat burned out on "troff-plus-macro-package", largely
because the main stuff I've done with that combination uses "-man" as
the macro package, which is an obstreperous beast that you have to beat
about the head and shoulders to get to do certain kinds of layout that
I've wanted to do. I have a similar problem with "tbl", which is
similarly obstreperous.
>The credit goes, really, not to troff, but to a well-defined
>batch markup language that allows authors to concentrate
>on *content* and leave layout to the software.
Exactly. Unfortunately, absent such a markup language, batch systems
can really give me, at least, a pain where a pill won't reach it, and in
the grand UNIX tradition "you *can* make XXX work by doing YYY" all too
often turns into "...so we won't do YYY for you, because you can do it
yourself."
Greg A. Woods
> feasible, and there is a program called snaz internally
> in Bell Labs that more or less does this. It was designed
> for the Blit/5620/630/730 terminals.
Humph! More great software that isn't in the Toolchest, and will
never see the light of day otherwise! :-)
Somehow I wonder if layers wouldn't be (have been) more widely used if
there wasn't more software available and a better description of
layers(5) and layersys....
> But the *real* reason is...
I sure had to laugh when I read your story about troff vs. "whatever"
WYSIWYG package. I've been repeating the stories from the original
UNIX papers w.r.t. training people to use ed/troff for a number of
years. Now I have a more current (and perhaps believable) one!
Personally I (as should be obvious by now :-) am a troff user/fan, and
am in full agreement with the "batch" text-processing philosophy.
I too use a text editor (jove in my case), and I often use xproof
under layers on a 5620 to preview documentation. It's not as clean as
I'd like. I've tried the trick of writing a programme called 'watch',
ala Pike's description in the Blit papers, but it doesn't work very
well for anything complex, even if you don't use '-mX', since there's
no apparent way to totally re-set troff in one quick command, and even
if each macro package provided a consistent reset macro, it seems there
are things which cannot be reset at all.
Re-starting a troff pipeline, especially when using a complex macro
package like mm(5), is a bit more painful than one would desire, no
matter how powerful your system is.
If there's any such trick I've failed to discover, I'm sure it would
make the previewing process much easier for everyone.
How does it go? "A picture is worth a thousand words."? Yes, pic
code is not so easy to work with, but xcip and Picasso are! Obviously
such tools must produce output which can be included in "batch"
documents, but at least these two do. Of course in the world of
PostScript printers, PS inclusion (with psfig, for eg.) is necessary,
and PS previewing is desirable.
As you say, "authors" are likely to be more productive with a WYSIWYG
tool any time form is more important than content. I hope that time is
never for documentation, technical papers, contracts, etc. It
certainly describes most advertising though! :-)
--
Greg A. Woods
woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada
+1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL
Greg A. Woods
>[....]
> handwritten version into TeX. But with proofreading, etc., it would
> take far less of my time if there were a not-quite-WYSIWYG means of
> producing a document with a built-in translator to a typesetting
> language like TeX or troff.
IMHO, I think you are looking for an improvement in I/O devices,
rather than an improvement in text processing software per se.
If so, then given the situation today, I think you are either dreaming
the impossible, or building a folly. Either you work with character
terminals, in which case you can't assume anything but ASCII character
sets, and nroff is your only friend, or you work with bitmap screens,
in which case you may as well have full previewing capability, along
with a terminal window that can display the appropriate character set.
Of course if you work with both/all terminals, you should remain
compatible with the LCD, so you're stuck with ASCII again.
David J. MacKenzie
>> feasible, and there is a program called snaz internally
>> in Bell Labs that more or less does this. It was designed
>> for the Blit/5620/630/730 terminals.
The EZ word processor that is part of Carnegie-Mellon's Andrew system
also does this. It's X-based. However, Andrew is a pain to get
working.
--
David J. MacKenzie <d...@eng.umd.edu> <d...@ai.mit.edu>
Paul De Bra
>In article <1991Aug2.2...@cbnewsl.cb.att.com> n...@cbnewsl.cb.att.com (nils-peter.nelson) writes:
>> Something that is new, but generates troff as output is
>> feasible, and there is a program called snaz internally
>> in Bell Labs that more or less does this. It was designed
>> for the Blit/5620/630/730 terminals.
>Humph! More great software that isn't in the Toolchest, and will
>never see the light of day otherwise! :-)
Snaz isn't just written for the 630/730 terminals but also runs under X
on several different systems (and much better, i.e. faster than on the 630).
(the blit/5620 are not supported, mostly because of lack of memory.)
DWB is a stable, reasonably well documented and supported package.
Snaz (the almost WYSIWYG editor) and Monk (the underlying language)
are still in the research phase and are not yet stable and not yet
well documented. As they become more stable they will first be
distributed internally (monk already is), before being offered to
the world (if ever).
Some companies try to make money on software that isn't ready yet.
I don't think that helps anyone. Personally I think you're better of
with a somewhat more primitive tool that works reliably than with
the hottest tool which core dumps or produces bogus results.
Herman Rubin
> In article <15...@mentor.cc.purdue.edu> hru...@pop.stat.purdue.edu (Herman Rubin) writes:
> >[....]
> > handwritten version into TeX. But with proofreading, etc., it would
> > take far less of my time if there were a not-quite-WYSIWYG means of
> > producing a document with a built-in translator to a typesetting
> > language like TeX or troff.
>
> IMHO, I think you are looking for an improvement in I/O devices,
> rather than an improvement in text processing software per se.
NO. I do not need an improvement in I/O devices.
> If so, then given the situation today, I think you are either dreaming
> the impossible, or building a folly. Either you work with character
> terminals, in which case you can't assume anything but ASCII character
> sets, and nroff is your only friend, or you work with bitmap screens,
> in which case you may as well have full previewing capability, along
> with a terminal window that can display the appropriate character set.
> Of course if you work with both/all terminals, you should remain
> compatible with the LCD, so you're stuck with ASCII again.
There is an intermediate, which has been technologically feasible for lo
these many years. Even with bitmapped screens, for the purpose of
writing papers, communicating, etc., this is much easier than the
usual procedures available.
A character terminal uses a read-only table to do a local bitmap from the
binary of the ASCII character. Those terminals which give a choice of
fonts merely choose which table is to be read. What is needed is a
means of shifting between fonts and a means of producing fonts when
needed. The first merely needs assigning an unused non-printing
character for the shift, and the second is well-known technology.
Using 8 bits instead of 7 makes the job easier.
This gives not only previewing capabilities for a body of non-ASCII
text, but direct editing capabilities for it. These do exist, but
are not sufficiently linear to convert into troff or the much more
understandable TeX, as the font- and style-change information are
not intermixed with text.
Carl W. Bergerson
>
> I've resisted responding up until now to the question
> "Does anyone know of a WYSIWYG troff?" but guess I
> owe the world an explanation, as far as Bell Labs
> is concerned.
> But the *real* reason is...
> A while ago a large internal documentation organization
> inside AT&T had a shoot-out between troff and one of the
> well-known Unix WYSIWYG formatters on a Sun 3. Two different,
> trained groups were given a large document to produce,
> one with troff, the other with WYSIWYG. The troff group
> finished substantially ahead. The experiment was deemed
> a failure (since it was supposed to show WYSIWYG improved
> productivity) and repeated. Same result.
> I'd enjoy seeing responses, since this is an important
> issue to all of us.
I find this very interesting.
When I found nroff/troff about eight years ago, I thought it was
the neatest thing since sliced bread, having used several less
capable roff-like packages previously.
I succeeded in crafting my own version of -mm (without source
availability) so a group of writers could concentrate on substance
not form. We told them to think of their text as composed of
objects such as headers, paragraphs, lists, and so on. Worked
pretty well, too.
But there were problems. I never got around to writing indexing macros,
although I think I designed them right. And running spell, style,
and diction in batch mode always seemed a little user-hostile
to me.
Since losing access to troff five years ago I've used a number of
PC based wp programs. Word for Windows (w4w) is the only one with
(almost) true WYSIWYG. It incorporates the ability to do indexing
and in-context spelling checking, and with the use of add-in packages,
you can perform in-context grammar and style checking.
w4w also incorporates a feature called a bookmark, which identifies
a block of text with a lable. When this label is referred to, by the
writer, elsewhere in the text, w4w will print the page number of
the designated block of text. Real handy, now if only w4w had floating
keeps . . .
w4w also has a few other shortcomings. Its style sheets (troff's macros)
are included by value in each document and can be altered on a document
by document basis. w4w has a definite _view_ of what constitutes various
text objects such as paragraphs and, while w4w allows you to modify
many of the attributes of its pre-defined notion, it just isn't as
flexible as troff, where the macro author defines the concept of
what constitutes a particular text object.
In summary, I think troff has some basic limitations that cannot
be addressed properly in its current form. However the programs
that have adressed these issues and fixed them to some degree have
brought limitations of their own. All in all, I think that it would
be easier, to fix w4w than troff. But let's see, which dog would
I like to wag, AT&T or Microsoft . . .
--
Carl Bergerson uunet!p4tustin!carl
Point 4 Data Corporation ca...@point4.com
15442 Del Amo Avenue Voice: (714) 259 0777
Tustin, CA 92680-6445 Fax: (714) 259 0921
Denis Lynch
> A while ago a large internal documentation organization
> inside AT&T had a shoot-out between troff and one of the
> well-known Unix WYSIWYG formatters on a Sun 3... The troff group
> finished substantially ahead.
..
> the WYSIWYG group spent a lot of time "prettying" up layout at an
> early stage of authoring
..
> The credit goes, really, not to troff, but to a well-defined
> batch markup language that allows authors to concentrate
> on *content* and leave layout to the software.
This is an extremely significant posting, at least to my ears. In some sense,
it confirms a viewpoint that I've been espousing for years, but that doesn't
seem to have taken much hold in the commercial world.
The first observation, as Nelson points out, is that authors should spend time
authoring, not formatting. Indeed, most "word processors" provide lots of
support for formatting, but very little for authoring.
Another observation, seldom made by adherents to the last point, is that seeing
a document in nearly-final form while it is being entered helps the authoring
process. I don't have experimental evidence to support this, but I'm convinced!
The obvious solution here is an authoring environment that supports WYSIWYG
entering of text, but without taking formatting advice from the author. In
other words, an environment that has strong formatting abilities, but the
formatting is specified completely by a "style sheet" analogous to a troff (or
TeX) macro set. An editor that shows a ruler or font menu seems inappropriate
to producing documents of any size or serious intellectual content; at the same
time forcing an author to work while looking at a single ragged column of
mono-font type seems excessively Draconian.
A natural implementation framework would be an SGML-based "structure editor"
that uses a DTD to understand the structure possibilities, with a parallel
Format Description that specifies rules for displaying each structure element.
Looked at from another way, what is really needed isn't a WYSIWYG version of
troff, but a WYSIWYG version of 'mm' or latex. The best way to provide such a
thing would be an environment that worked with a declarative form of structure
and format definition.
As far as existing art, I'm (slightly) aware of an experimental editor called
Quill that was developed at IBM. The commercial product Author/Editor wants to
be headed in the right direction, but isn't quite.
How come nobody has produced such a thing? Am I missing something, or is this
an opportunity to get rich (or just famous)?
--Denis Lynch, ESL Inc.
Greg A. Woods
> In article <1991Aug6.1...@eci386.uucp>, wo...@eci386.uucp (Greg A. Woods) writes:
> > IMHO, I think you are looking for an improvement in I/O devices,
> > rather than an improvement in text processing software per se.
>
> NO. I do not need an improvement in I/O devices.
> A character terminal uses a read-only table to do a local bitmap from the
> binary of the ASCII character. Those terminals which give a choice of
> fonts merely choose which table is to be read. What is needed is a
> means of shifting between fonts and a means of producing fonts when
> needed. The first merely needs assigning an unused non-printing
> character for the shift, and the second is well-known technology.
> Using 8 bits instead of 7 makes the job easier.
Like I said, you are looking for an improvement in I/O devices. Of
all of the non-bitmap capable screens I have access to, only one
allows a new font to be used, and such new font must be downloaded to
the terminal.
If you wish to remain compatible for the non-bitmap world, i.e. the
existing forest of ASCII terminals, then your dream, IMHO, is a folly.
In the world of bitmap screens, there's no excuse for not providing
complete preview capability, though it would be interesting to have an
editor on a bitmap screen that could generate, say, troff sequences
for special characters, while displaying a glyph for the special
character.
Chris Lewis
>NO. I do not need an improvement in I/O devices.
Well, at least a hardware change in most existing ASCII terminals.
>A character terminal uses a read-only table to do a local bitmap from the
>binary of the ASCII character. Those terminals which give a choice of
>fonts merely choose which table is to be read. What is needed is a
>means of shifting between fonts and a means of producing fonts when
>needed. The first merely needs assigning an unused non-printing
>character for the shift, and the second is well-known technology.
>Using 8 bits instead of 7 makes the job easier.
Virtually all character/ASCII terminals are essentially bitmap displays, where the
fonts are stored in ROM. There usually aren't capabilities for displaying
bitmaps directly. The terminal memory contains the ASCII characters,
which are mapped thru the character generator (usually a ROM) into bitmaps
for each character. Relatively few terminals permit downloadable fonts -
because it's relatively expensive and of relatively little utility to add
additional circuitry to permit downloading to a character generator RAM.
Wyse 60 is one common terminal that does have downloading. On the other hand,
I know of no character terminal that permits proportional fonts or fonts of
different sizes. Character terminals use fixed size character cells. Given
those limitations, it doesn't really seem that worthwhile to try to support a
troff on any sort of (pure) character terminal.
On the other hand, bitmap displays (ie: 5620) have enough memory to display
the whole screen in terms of individual bits, so it gives the application
programmer the facilities for doing anything they want.
[I just wish I could find out the escape sequences for this durn 5620
display so I could use it as a previewer for troff/psroff with HP or
PK format fonts. How do you send a raster to a 5620?]
>This gives not only previewing capabilities for a body of non-ASCII
>text, but direct editing capabilities for it. These do exist, but
>are not sufficiently linear to convert into troff or the much more
>understandable TeX, as the font- and style-change information are
>not intermixed with text.
WYSIWYG editors usually give you form, not structure.
--
Chris Lewis; UUCP: ...!{cunews,uunet,latour}!ecicrl!clewis;
DOMAIN: cle...@ferret.ocunix.on.ca; Phone: Canada 613 832-0541
Psroff info: psroff-...@ferret.ocunix.on.ca
Ferret mailing list: ferret-...@ferret.ocunix.on.ca
Herman Rubin
I am quite aware of all of these. I am interested in a quick way of
producing manuscripts, and the problem of proportional fonts or fonts
of different sizes is quite minor. That can be left to something like
TeX or *roff to carry out. It does not bother me if I need a whole new
font for subscripts and another for superscripts, nor that it will not
look exactly like the output.
For the Latin and Greek alphabets, subscript and superscipt, we have
300 characters. In addition, there is a whole slew of special characters.
I would think nothing of having additional fonts, if necessary, for Italic
or boldface, although this may not be necessary. There are systems, like
the word processors on some microcomputers, which have some of this.
But I will be able to see what I have produced, and the translation into
a typesetter like TeX will be trivial. I do not want a previewer; I want
to type in something I can immediately look at, and have it converted into
the source file for the formatter easily.
Gary Pianosi
> [deleted discussion of WYSIWYG troff and offer an alternative]
> ...
> The obvious solution here is an authoring environment that supports WYSIWYG
> entering of text, but without taking formatting advice from the author.
> A natural implementation framework would be an SGML-based "structure editor"
> that uses a DTD to understand the structure possibilities, with a parallel
> Format Description that specifies rules for displaying each structure element.
>
Well said! I agree whole-heartedly with this posting, however I'm left
wondering about the later statement that:
> ... The commercial product Author/Editor wants to
>be headed in the right direction, but isn't quite.
I'm not sure how Author/Editor is "not quite" headed in the right direction.
The combination of a good SGML editor and a translator from SGML to your
choice of formatting language makes for a very productive authoring environment.
As an example, you should check out the 'format' system (an SGML to Latex
translator) written by Tom Gordon (tho...@gmdzi.gmd.de). He has implemented
a DTD which describes the structural definition of Latex documents, including
special character mappings. Author/Editor together with 'format' seems to
be a good system for creating Latex documents.
Caveat: While I have no connection with Author/Editor (or SoftQuad), I have to
admit that I am somewhat biased towards this type of environment. Here
at the University of Waterloo we have developed an SGML-based document
editor (Waterloo Rita), and I am currently looking into ways making it
a better tool for creating Latex documents on Unix.
-- Gary Pianosi.
--
E-mail: ga...@csg.UWaterloo.CA Phone: (519) 888-4678
Computer Systems Group, University of Waterloo, Waterloo, Ontario, Canada
Tom Shields - Unisys
In article <5...@esl.ESL.COM>, d...@esl.com (Denis Lynch) writes:
[...stuff deleted...]
|>
|> The obvious solution here is an authoring environment that supports WYSIWYG
|> entering of text, but without taking formatting advice from the author. In
|> other words, an environment that has strong formatting abilities, but the
|> formatting is specified completely by a "style sheet" analogous to a troff (or
|> TeX) macro set. An editor that shows a ruler or font menu seems inappropriate
|> to producing documents of any size or serious intellectual content; at the same
|> time forcing an author to work while looking at a single ragged column of
|> mono-font type seems excessively Draconian.
|>
|> A natural implementation framework would be an SGML-based "structure editor"
|> that uses a DTD to understand the structure possibilities, with a parallel
|> Format Description that specifies rules for displaying each structure element.
|> Looked at from another way, what is really needed isn't a WYSIWYG version of
|> troff, but a WYSIWYG version of 'mm' or latex. The best way to provide such a
|> thing would be an environment that worked with a declarative form of structure
|> and format definition.
|>
|> As far as existing art, I'm (slightly) aware of an experimental editor called
|> Quill that was developed at IBM. The commercial product Author/Editor wants to
|> be headed in the right direction, but isn't quite.
|>
|> How come nobody has produced such a thing? Am I missing something, or is this
|> an opportunity to get rich (or just famous)?
|>
|> --Denis Lynch, ESL Inc.
I've seen a demonstration of a product called ArborText that may well fit your
criteria - its SGML-based, supports fairly fancy WYSIWYG editing, and has a real
slick WYSIWYG table layout definition mode that generates all of the SGML totally
behind the scene. I didn't see enough to be able to tell you exactly how much
control is available in the format description, but if you are interested in such
a tool, ask for a demo yourself, you'll be glad you did
sorry, I don't have a telephone number handy, but they are `up and coming' in
the SGML world, so it shouldn't be too hard to find them - if it weren't Friday
evening, I could probably get more info for you; if I remember Monday, I'll post
a telephone number and address
--
------------------------------------------------------------------------
Thomas E. Shields, PhD, CCP STARS Center - 7670
STARS Deputy Architect Unisys Defense Systems, Inc.
(703) 620-7028 Tactical Systems Division
(703) 620-7916 FAX 12010 Sunrise Valley Drive
shi...@stars.reston.unisys.com Reston, VA 22091
------------------------------------------------------------------------