TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Screen Captures in UNIX From:Graham Dowden <Graham -dot- Dowden -at- NMS -dot- OTC -dot- COM -dot- AU> Date:Tue, 14 Oct 1997 10:01:42 +1000
Sarah Lathrop wrote:
>
> I am working on a reference manual for our UNIX based software system.
> The displays were recently redone by a graphic designer in the colors
> of the 90's. They are beautiful to look at, but the screen-capturing
> process has become a nightmare.
That is a bit like getting a car designer to draw a few strokes
of pastel on some coloured board and expecting a reliable vehicle to be
produced without proper engineering input into the design - looks great,
but may not be practical.
> I experimented with xv to capture the screens.
> I am getting ugly dithered patterns for many of the colors.
The process of capturing and printing graphics has the following steps and
possible problems.
1 X display
Some applications "steal" the colours which another application requires
from the X colormap. Oracle forms are notorious for this. Try closing
down other applications or starting the capture program after the
application being documented.
2 Capture
The Unix utilites xv, Snapshot, Imagemagick etc should capture colours
correctly if no other application has stolen them. Some snap programs
can themselves steal colours. The xv Image Info window displays the number
of colours and bits per pixel in an image, enabling colour verification.
3 Saving
Images can be saved in full/reduced/dithered/grayscale/monochrome
format. Make sure the right format is used.
4 Import
The application into which the graphic is imported may change the
image, eg. reduce or dither colours it can't handle.
5 Display
The device on which your the writing program runs may also change the
appearance of the imported graphic, eg. dithering 16M colours to 256
due the graphics card limitations. This does not change the actual
graphic.
6 Output
Printer driver, driver configuration and printer may change colours
which can't be handled.
The best thing to check the whole process is to to create or edit
a test image file containing all colours labelled with RGB values.
Import the test file into FrameMaker and print it, then photocopy it,
finding out which colours dither and look OK on final copy. Then apply
a batch job to all captured screens to reduce/alter colours, eg. with the
Imagemagick convert utility.
Regards,
--
Graham Dowden
dowdeng -at- nms -dot- otc -dot- com -dot- au
Telstra, Paddington, AUSTRALIA
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html