Re: Thanks, Joel!

[jroth@xxxxxxxx (Joel Roth)]

Annie Fisher wrote:

> Hi, Joel Roth: I can't answer many of the issues you raised, but let me offer
> a few possible solutions, starting with the simplest.

> "I never did really understand what those NI calls were supposed to do."
>
> NI lets you avoid .kbd conflicts by overriding BIOS key assignments
> (especially needed for the Alt cursor keypad and keys like Pause/Break).

Thinking about this makes my head go all wobbly, but I know who to go to when
I have problems on that side of the keyboard. My strategy has
always been to do everything on the home keys.

> "Keyboard definition files: Mistakes here are death in a fast machine,
> because the error message is practically invisible."

> Don't know if this is true in v4, but to debug .kbd files in v3, loading with
> the "ldkbd" command instead of "load" keeps the error message displayed till
> the next keystroke.

Thanks! I'll try this. Hope it works for printer files.

> "We all know what a pain it is to write programs in XPL."
>
> Speak for yourself!  I have to force myself to *stop* writing xpl, and
> don't think I'm alone. Alas, the only decent documentation, Herb Tyson's
> brilliant "XyWrite Revealed," is out of print, and TTG marketing practices
> make the demand for a v4 revise underwhelming. Remaindered copies of the only
> third-party xyWrite 4 macro manual have been collecting dust on the shelves
> of a bookstore here for months.

At least they're there.

> "That said, XPL is *great* for what it was designed--customizing the Xywrite
> user interface. Most of these programs are fairly small."

> One chained xpl program I wrote runs to 50,000 bytes.

Omigod! Can you tell us what it did?

> XPL is as restricted or expansive as you want to make it.

It has this in common with assembly language. :-)

>Here are some v3 keyboard assignments that
> make it easier.

Thanks. These will be very helpful.

> "XPL programs print to file with STRIP.PRN to collect footnotes, then I run
> another utility to delete the LF characters the print driver insisted on
> including in the text."
>
> STRIP.PRN *should* leave only whatever you assign as line and paragraph
> endings, respectively:
>     LE<
>     PE<
> ... should leave nothing, joining the words at the end and beginning of lines
> and paragraphs. Alternatively, after the < you could use ascii 13 or 10 or
> both or a space.

I found that LF characters were included even if LE and PE were
set as you showed above. Perhaps a version-specific problem.

> "Another client needs two spaces after a period...."

> What am I missing? Unless I misunderstand, this should be an xpl piece of
> cake.

I answered this in another mail. Yes, it is manageable, but
beyond that seem talented at both XPL and Postscript.

> "I was quite intrigued by Annie Fisher's discussion of Postscript, although
> I'm not quite ready to invest the time."

> xyDos, however, is
> PS-numb--primitive support: EPS files must be coded into disk files manually
> and won't display, etc.

You can call it primitive, or you can call it "batch processing."
Certainly the time for each iteration (modify and check output)
is longer.

> Dan Kanagy suggested the ideal type solution--a Tech
> Group-SoftMaker font engine collaboration--to Kenneth Frank and got zero
> response.

In fact, NeXtStep is distinguished by its display Postscript support.
I haven't actually seen it at work tho... have you?

> Short of real support, using PS effectively with xyDos does require
> a substantial investment of time. For me, it's been worth every hour
> invested, but if xpl puts you off you may not have the patience for PS.

XPL doesn't put me off. I just don't think it's the best tool for
some things.

> Ross Smith's delightful "Learning PostScript: a visual
> approach" (Peachpit Press) is everybody's favorite primer.

I'll look for a copy.

> If any of this is of use, you can take it as thanks for your tip on renaming
> SHIFT, CTRL, and ALT in .kbd files.

Glad it helped. I just stumbled over it in the course of random,
desparate acts when I first reconfigured my keyboard. It was a
difficult time because everytime I came up with a new and better
layout, I had to relearn the new positions.

Seems like you've got a pretty good arrangement too.

> "Another `abandoned' product is Borland's Sprint, which I understand has an
> excellent formatter and text processing tools."
>
> As penance for passing up two copies of Sprint that I thought a year ago were
> overpriced at $20 each, I torture myself by browsing remaindered Sprint
> manuals. When I get to the parts about writing Sprint macros in C, I kick
> myself for my dumb judgment.

I've never seen it in action, just heard about it. I think you
could get a copy if you really wanted it. Seems like an MSDOS
answer to troff and its ilk.

And what about TeX? Certainly the learning curve is quite bitter
for these user-unfriendly programs.

--
Joel Roth