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:Fig. vs Figs.? (take II) From:Geoff Hart <ghart -at- videotron -dot- ca> To:techwr-l List <techwr-l -at- lists -dot- techwr-l -dot- com>, Adam Turner <adam -dot- turner -at- gmail -dot- com> Date:Tue, 20 Nov 2007 10:08:18 -0500
Adam Turner provided more details: <<I should have given a little
more context to my question "Is the word figure singular or plural in-
text when describing alphabetically labeled divisions of a single
numbered figure? EXAMPLES *Fig. 12 (a), (b), and (c) shows* OR Figs.
12 *(a), (b), and (c) show ">>
As I noted, it's still one figure, not two. My original suggestions
remain valid on that basis. However:
<<I am talking about academic engineering journal articles where the
abreviation "Fig." is the norm with or without parentheses.>>
Over the years, I've worked for many dozens (possibly hundreds at
this point) of non-engineering peer-reviewed journals, and I don't
recall any of them that prefer the abbreviated form outside
parentheses -- that's 20 years of experience talking, just to be
clear here. But if that's the journal style, you need to follow it.
The answer to your question then becomes: "How does each specific
journal handle such questions?" It's no longer a case of right or
wrong, but rather one of following the journal's style, which is
often illogical or annoying. Follow it anyway. If they're not
consistent, pick whichever approach you prefer and use that approach,
and have the original article handy so you can cite it if the journal
editor disagrees with your choice.
<<"This definition (6) may also be useful to attenuate small-scale
discontinuities or to take into account some geometrical features of
the images under study, see Figs. 3b and 3c.">>
That's sloppy writing, and I wouldn't accept it in my own editing
work. But if it's the lingua franca of engineering journals, so be it.
<<Also, it is fairly common practice to include a number of images in
a single numbered figure. This is probably a space saving device
given the size limitations of scientific articles.>>
Ideally, figures should only be combined when they present related
information that must be compared within a single visual field.
Grouping figures doesn't save any space if they contain unrelated or
significantly different content: the graphic takes up exactly the
same amount of space, and if the caption is significantly different,
you save only a few characters because most of the caption must still
be repeated. Only when the majority of the caption is identical for
all sub-figures is there any significant space saving, and the saving
is small compared to the overall size of the figure.
<<We also know that published papers don't always show best
practices, but I would like to give guidelines to my graduate
engineering students.>>
When I've lectured to grad students on journal publishing, one of the
best guidelines I've provided is: "For details such as these, ignore
the author guidelines, and go right to the journal itself (published
articles). That shows you how the journal's editors handle these
situations. Follow their guidance, even if you don't like it; there
are many bigger battles you'll have to fight."
----------------------------------------------------
-- Geoff Hart
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
www.geoff-hart.com
--------------------------------------------------
***Now available*** _Effective onscreen editing_
(http://www.geoff-hart.com/home/onscreen-book.htm)
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-