Excuse me, but what a laugh--as if each of those journalists had carefully
weighed all the choices, gone to a store, and bought xyWrite! If they'd
chosen a word processor in the '80s it would have been WP because sales clerk
"experts"--relying on reviews directed to corporate buyers and relieved by WP
toll-free tech support of ever having to offer any--would have advised PC
neophyte friends to get WP. Since all their friends used WP, so would those
journalists. Now they wouldn't even weigh the choices. "Word processor" = WP,
unless you're real hep and get that maverick winWord.
They use xyWrite because xyWrite's Atex roots gave XyQuest credibility with
publishers. Publishers, not writers, bought xyWrite because it is a text
editor. The word processing stuff is add-ons journalists use at their peril
in the office--if they even know they're there, and they usually don't
because they rarely read and may never see the documentation.
XPL (and any supplementary language TTG may introduce) and the tools Jim uses
to configure xyWrite let editors do things with xyWrite that reporters know
and care little about. Editors in the Prodigy newsroom upload xyWrite files
to the service with an xpl program. I've mentioned before a massive, chained
xpl program I wrote. To pure ascii xyWrite files it added typographic codes
for every editorial format one Manhattan weekly used and transmitted the
files to production fully coded, ready to print. The destination was usually
a server but it could and in crunches did send them directly to an
imagesetter; galleys could be pulled and pasted down without typesetter
intervention. Another xpl program I wrote character-counted headlines (the
time-tested half-, one-, one-and-a-half-, two-unit system) while editors
wrote them. Never fast enough; that led me to C: The hed counter I ported was
so fast (integrated with a do command on a dedicated key) the editor wanted
me to market it nationally.
Now I'm gone, he's gone, the paper has switched to QuarkXPress, editors
pre-"style" files with MacWord since its style sheets are so QXP-compatible,
and last I heard a consultant was trying to sell the publisher on switching
the reporters to Macs too. The decision, in any event, is his. When XyQuest
ignored the PostScript publishing explosion, XyWrite and publishing lost
their symbiotic relationship.
Ken, I admire your candor on issues you choose to address, but I've yet to
see any response to any disquiet regarding xyDos or xyWin and PostScript,
Type 1 fonts, ATM, etc. HP printers are OK--I have a 4MP myself--but PS, not
PCL, is the publishing industry standard. XyDos 4 adds nothing to v3 PS
support and if Chet Gottfried is right about xyWin's PS limitations--e.g., if
the chars he says turn to bullets aren't just the consequence of an
inaccurate PS prolog encoding table--xyWin doesn't make the cut for serious
dtp-tilted Windows word processing (the only need I thought I might have for
it). And please tell me we're not talking here about a Windows word processor
that can't even handle EPS files.
When the QXP revolution occurred XyQuest was in chaos, done in by IBM and a
misconception--I believe--of what it had created. XyQuest made seminal errors
in defining xyWrite as a word processor and not as a category-of-one
user-programmable DOS shell/"text processor," a text editor with a full set
of word processing features, making both a text editor and a conventional
word processor optional--and in not naming it something like FrontEnd or
dosPower that implied wide applicability, cultivating independents churning
out modules like offline email readers, compiler front ends, file managers,
specialized professional interfaces, etc. I gather, however, that XyQuest all
but discouraged third-party development. Judging by an answer to a query a
few months ago, TTG doesn't understand what an SDK is. (Meanwhile,
third-party developers churn out QuarkXtensions and WP s/w peripherals.)
XyWrite should have been treated as open-ended and indispensable to every DOS
user, something of a DOS counterpart to Windows. It of course deserved a
tutorial as radically different as the software. (XyQuest was as delinquent
with configuration info as TTG. It took Herb Tyson's "XyWrite Revealed" to
lift the veil, and it cost $5 less than that insulting XyQuest xpl pamphlet.)
The first time XyQuest read that lightning-fast-but-steep-learning-curve
drivel it should have hired an expert to design an intuitive default
keyboard.
With xyWrite positioned as a word processor and burdened with that default
keyboard, as the menu'd cousins gained popularity inevitably XyQuest and the
trade press, then TTG, saw xyWrite as a difficult if flexible menu-impaired
word processor that--oh, yes--incidentally has ascii-base files, rather than
as an ascii-base shell adaptable with a new module to every text-intensive
situation. Just as XyQuest erred in regarding DOS WordStar, WP, and Word as
the competition, TTG does in going after specialized word processor market
segments instead of focusing first on what can be done with that ascii base.
Windows notwithstanding, as long as ascii is in use opportunities will
emerge. But who can blame Ray Duncan, in his recent PCMag HTML primer, for
advising readers that
"Preparing a document in HTML is more like application
development than desktop publishing, because it involves
... modifying the HTML source in a text editor, loading
the file into a Web browser to see how it looks and prints,
figuring out what the problems are, and going back to the
text editor. ..."
instead of starting, "If your xyWrite isn't already loaded ..." and
explaining how to configure a xyWrite printer driver for HTML to convert
attributes to codes when you print to disk. ... The Web explosion found TTG
as unprepared as XyQuest was at the time of the PostScript explosion--too
preoccupied with business word processor concerns, oblivious to the rich
potential inherent in what underlies the wp frills.
That the choice for any supplement to xpl is coming down to VBA or REXX is
dispiriting. Where is the critical mass that should be clamoring for a subset
of C, as legendary for compactness and speed as xyWrite? Some similarities
are uncanny. A
{sv86,foo bar}{sx86,{is00}e{is86}}
construction is precisely equivalent to the C strchr function. A
{sx86,(@siz({is00}))-(({is86}e{is00})+1)}
procedure where the content of a variable is processed and stored on the fly
is the kind of shorthand that helps make C so fast. (Count my vote on a
xyWrite II resurrection as yes.) Interesting to read that TTG programmers use
EDITOR as an editor. The only other instance I ever encountered was a letter
to the editor from a Rockwell engineer sneering at PCWeek's advice not to use
a word processor as a programming editor, detailing how he used xyWrite. At
the time, I was in a tumult of xyC. Why isn't every programmer who loathes
IDEs? Tim Baehr mentioned Brief's anemic macro utility. C, like PostScript,
works in my system like an extension of xyWrite.
One trap I hope Ken and all subscribers avoid is thinking this list is a
microcosm. The 'net is still academic at the core, and I see no particular
reason to suppose that subscribers are typical xyWrite users. Not to mention
that I find that the more heed I pay the list the less I push my software,
xyWrite included. But for Robert Holmgren--who must have written a clone of
himself to help ;)--who can make time to do both effectively? --annie
========================== annie fisher <okAnnie@aol.com> nyc