`power' v wp xyW (long!)

[OkAnnie@xxxxxxxx]

Jim Besser writes: "[... T]he journalists at the keyboards
weren't computer hobbyists, generally; they were people who used
the program because it made life easier for their production
people, or because it offered specific features--speed, ease of
formatting, etc.--that other programs did not provide."

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  nyc