| The most commonly used tool is Capture. A few folks have used
DECslide/DECgraph. We've produce a book with a large number of screen
samples from Baseview.
There's been a need to edit the sixel files to get the blank space
correctly balanced.
Writers who've been using WPSplus to DECpage have used the Wps+
Two-dimensional editor. Those files will have to be handled when
we start to convert some projects to Document.
We handle a number of FMS-based products. At some point, those will
need to be converted to VAX Forms, which supports Postscript; until
then, we still need to be able to print the form displays.
There's probably even some Peco stuff kicking around.
|
|
I've been crawling around the PICMODE screen for months, now, and
my comments on the VAXMATE issues are my current attempt to break
away from just lines, boxes, and monospaced type. Also, using
PICMODE to do graphics for overhead slides (my most popular
deliverable) isn't all that great; the line density is too light,
and the type too small, for reading more than a few feet away...
I intend to use a combination of VWS tools (GRED/SIGHT/RENDER),
and my VAXmate. I'll use the VWS tools for "precision" drawings,
and the VAXmate for cartoons. I have a copy of NEWSROOM (??)
on order which is supposed to have a lot of clip art with it.
Slightly longer term, I will be moving to a PostScript environment,
and will be using Gent's sixel to PostScript translator for the
clip art stuff (unless, wonder_of_wonders, the PostScript driver
in the VAXmate can handle the artwork...)
I sense a more general question in your specific ones, namely
what do folks see as requirements for a generalized graphics
tools suite? Parenthetically, it's "device independence", but
in practical terms I would be happy with a working set of
translators. There are a lot of good (well, better than PICMODE)
graphics tools out there, none of which can (or want to) talk
to each other. When I talk to vendors about graphics transport,
they mumble something about DIME format files and wander off
to talk to someone else...
Now, if I can just get my KOALA Pad files off of my Atari, into
DOCUMENT... hmmm... where did I put my copy of Action!?
Harold
|
| I use GRED for almost everything. Sometimes in a rush to get something
out the door and I'm converting a "figure" from Runoff that was
just a .literal, I leave it as a <DISPLAY> or some other monospaced
example with |\/-_+ characters (blech!)
The scarcity of VS's around here makes the general user population a
bit testy at times, although most love the output they finally get.
VAX Sight is probably the next most used tool.
I've had requests for people wanting to use PROsight, and PICMODE,
but no one has pushed the point enough to try it, or they do manual
paste up after the fact.
One other request that comes up is for line-drawing character support
for output from PECO, and some tool thats floating around for producing
VTX frames, that generates line-drawing character figures. I can
try to find out the name if you're interested.
-tl
|
|
We are using;
CAPTURE To capture screens
GRED,SIGHT The light tables continue to gather dust
Baseview et al If the software will provide it's own graphics
who are we to grumble? :^)
DECslide To sixelize all sorts of stuff including FMS
IMAGE This has come in handy *a lot* and frequently
Software with art that was never touched by the scanner.
Many of the screens from CAPTURE and Baseview
etc. are a full 80 columns wide and won't fit
into Document. The only way we have figured
out to resize this type of art is to read the
.SIX into IMAGE, write it back out as a .UIS,
and then RENDER/SIZE it to fit the required
doctype. This works really slick! The image
software will also allow cropping of a sixel
file.
We have had to edit some sixel files with a text editor to get
them to look just like we wanted them to, but not to get them to
print at all. I've also had to remove formfeeds from the bottoms
of some sixel files.
Lance
|