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.
Yeah... i never was able to figure out what the deal was with pngs in terms of resolution; they just didn't follow the same rules as other graphic formats.
The solution I suggested worked within my particular context, but apparently its not universal.
Hopefully, somebody else will post info that will clear up the mystery for both of us!
Thanks, Lynne. All sound logical, but at every step there seems to be a gotcha that causes a bad final result...
>As I recall, the trick is that you want to stick with 96 dpi (the
>optimal
>resolution) when dealing with pngs. So if you take the png at 96 dpi,
>import it into your callout-adding tool, then export at 96 dpi (or a
>multiple of 96), the resolution should be fine.
But Snagit for Mac doesn't provide a way to specify capture resolution :-(.
>downloading from Google Slide, then into/out of Snagit may be what's
>causing the resolution to fall apart.
Nope; doesn't matter if I import into a Google app or a Microsoft app or anything else I've tried. The capture looks fine in the Snagit editor, and then looks noticeably blurry in any other app if the size isn't exactly, physically (not pixels or dpi or whatever), the same as the capture. And the actual app's display size is much too big for inclusion in the doc.
>You may want to try Inkscape (a freeware that's compatible with Mac);
>you import your screen shot, add callouts, then export to png with no
>background to trim out.
Sounds good for eliminating the extra Snagit step to trim out the background, but not likely to improve the overall result given that importing the capture into any app results in blurry-ness.
>I'm a little confused about your question regarding callout text size;
>if you add callouts to a graphic, then export that as a png, it's
>effectively all one image, so there's no way that the callouts won't
>resize if you resize the png.
Correct! But I do not want the callout text to resize. I want the callout text to remain big enough to read (9 pt) with a reduced-sized PNG of the capture.
> So say that you want the callouts to be displayed in the doc at 9 pt.
> You'd add 9pt callouts, then export to png, then import into your doc
> at a
> 1:1 ratio, the callouts will be the size you want.
So here I'd have to determine, irreversibly, what size I need my capture to be in before I add the callouts. And through experience, I know it's highly likely that to accommodate production-edit changes, such as making a screenshot just smaller enough to appear at the bottom of a page instead of moving to the top of the next page. When I do this, of course I need to slightly move the callouts/text, but that's infinitely easier (in Google
Slides/PowerPoint/Visio) and quicker than redoing the entire capture. Oh, I guess I could save all the callouts in the .snagproj (Mac equivalent to the Windows .snag file) and edit that. I think long ago I must've found it cumbersome to use the lines and text boxes in the Snagit editor vs.
Visio/etc. And so for years I've been using the workflow as I described it.
All that said, this all might end up being moot for PDF output (vs. online HTML, which I'm heading to soon w/a redone Jekyll site) because creating good PDF without downsampling/etc. for images requires using a *real* PDF creator, which at my current contract isn't likely to be an option. It's an open source world!
Thanks for the tips,
-Monique
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
