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.
My suggestions, which may be disputed but are consistent with what I've
done, include the list that follows.
* Crop the images to what is really needed. The full screen view of the
application is really only necessary for the first, introductory image of
the application work area, whatever that is.
* Resize the cropped image in PSP to something as small as possible, but
still readable.
* Reduce the resolution the lowest resolution that is still readable. You
might want to do this before resizing. I don't know. I think that 72 might
be grainy and not always "right."
* <I guess I should mention this.> Make certain that you are using basic
display colors without gradients when you take screenshots to minimize the
number of colors used to render the graphics. This can help to reduce
graininess in lower resolutions. If you're using Windows, then pick
"Windows Default Colors" or some other similar boring scheme (theme) to
reduce your graphics colors.
* Sometimes a cropped screenshot in a basic graphics program, like Paint,
will produce smaller images.
* GIFs are good for web pages, but can screw up documents because of how
compression is handled. PNG may be okay for web and portability. JPEG
compresses better without sacrificing image quality. Bitmaps, like BMP, are
crappy. That is pretty much the extent of my graphics knowledge.
* Linked images do reduce file size.
The rest of your bullet points are about storage. If you can store your
images in a central location for all projects that's great, I tend to store
them in each project location.
My best advice is to experiment with suggestions that you get, but keep in
mind that sometimes a small graphics filesize can produce a larger than
expected filesize for your document depending on how the graphic is rendered
(I think that's right).
Lauren
> -----Original Message-----
> From: techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com
> [mailto:techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com] On
> Behalf Of Ami WRIGHT
> Sent: Wednesday, July 18, 2007 6:29 PM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: FrameMaker Graphics
>
> Hi everyone,
>
> I'm setting up processes for the doc department of a small software
> company. We use FrameMaker, Paint Shop Pro, and WebWorks. Much of our
> documentation gets translated, currently to one language, but
> possibly to
> more later. We provide our documentation as PDF files and
> WebWorks files
> that are included with the software builds. We don't provide
> hard copy of
> anything. We'd like to minimize the size of our FrameMaker files, and
> especially of the PDF files, since the PDF files actually get
> distributed.
>
> The current question that I've been working on is standards
> for graphics. I
> did some research on-line, including the techwr-l archives,
> about what the
> options are and what the consequences are of the various
> options. There
> isn't a lot of definitive information, but this is what I've
> come up with:
> * Graphics should be linked, not embedded
> * Format should be GIF
> * We don't need to save the Paint Shop Pro files after the
> GIF is created
> * DPI should be 72
> * Graphics should be in a standard subdirectory for each
> document (meaning
> all the graphics for a document go in a sub-directory of the
> FrameMaker
> files, and the subdirectory should always have the same name for every
> document)
> * The filenames for graphics do not need to reflect the
> language (same
> filename regardless of the language, but they'll be in
> different directories)
> * Try to use short names, to avoid having them munged if we
> need to zip
> everything
>
> If anyone has any experience that suggests that any of those
> is actually a
> bad idea, or has other suggestions that might be better,
> please let me know.
>
> One thing that I don't really like is that the graphics
> always need to be
> resized to make them small enough to fit the page. I tried resizing in
> Paint Shop Pro, but then the screen shots were unreadable.
> Does anyone have
> any suggestions about how to resolve that problem? Do I need
> to just resign
> myself to resizing in FrameMaker every time I place a screen shot?
>
> Thanks,
> -Ami
>
>
> -----------------------------------------------------------------
> Ami Wright
> "Technical" tech writer
> American with international experience
> www.amiwright.com
> -----------------------------------------------------------------
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Create HTML or Microsoft Word content and convert to Help
> file formats or
> printed documentation. Features include support for Windows
> Vista & 2007
> Microsoft Office, team authoring, plus more.
>http://www.DocToHelp.com/TechwrlList
>
> True single source, conditional content, PDF export, modular help.
> Help & Manual is the most powerful authoring tool for technical
> documentation. Boost your productivity! http://www.helpandmanual.com
>
> ---
> You are currently subscribed to TECHWR-L as lt34 -at- csus -dot- edu -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
>http://lists.techwr-l.com/mailman/options/techwr-l/lt34%40csus.edu
>
>
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/ for more resources and info.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
