May be I am missing something very basic here. But I am confused on the procedure of importing an image into FM by copying into document.
Whenever I am importing an image, a pop-up window prompting for graphic scaling is shown. My first doubt is to choose which option in this?
After reading through some of the posts, I started to keep the DPI 72 DPI and always used to keep the scaling in obeject properties 100%. But, at first, I didnt realize that the DPI and scaling are interdependent. So, after closing the FM file, when I re-open this, the scaling and the DPI were changed automatically!! Dont know how and why??? Is this any internal mechanism by which FM is auto adjusting itself the object properties or is it a bug?
But, if I import the image by reference, the DPI setting window won't appear at all. So, is this setting automatic when it comes to image import by reference?
I am not even sure whether I am following correct procedure here... Any help/ link to any other posts where this has been correctly addressed would be appreciable.
Additional query: Which image format is best to use in user guide (PDF) and Webhelp (HTML responsive)?? Please help me out in this regard.
Thanks in advance,
Before answering, can you tell me which version of FrameMaker you are using? The dialogs and behaviors have changed in Fm 2017, so knowing your version will help provide context.
Thanks for the reply. I use framemaker 2017 version.
In 2017 you have new image insert functionality.
The fourth of the new feature videos I created is for this feature.
Get access to all 10 videos at FrameMaker 2017 New Feature Videos - Tech Comm Tools and let me know if this clears up your insertion dialog question.
Regarding the format for PDF v. online help:
Vector graphics should use a format like Illustrator AI, PDF, or EPS
Bitmap graphics have more options.
Can you further describe the images you are placing?
Sorry, I wasn't clear in the original post. We import screenshots of web application products to FM. We publish user guide (PDF) and webhelp which contain mostly procedural information about how to use the application, initial configuration and troubleshooting stuff. So, mostly it will contain screenshots of the application. We don't use AI tool here due to budgeting constriants. We use SnagIt to take screenshots, do minor changes like cropping and adding borders in SnagIt and then save it in JPEG, and then import these screenshots into FM.
This is a sample of a screenshot of the app which we take:
And this is the screenshot of FM converted PDF output:
You can see that the screenshot's got blurred here. If this is zoomed, this gets worse. So, I am having doubt whether I am doing something wrong here. I keep the scale 100% and select 72 dpi while importing. (While I import, I use copy into document)
My questions are:
1) Is there any way by which we can retain the same sharpness which was present in the screenshot even in the PDF/html output?
2) If I change the image format from JPEG to some other format, will that make any difference?
3) Why sometimes the scaling and DPI settings change automatically once I reopen a file after closing?
I know these queries are very difficult to answer without looking at this personally, but appreciate even if you give supporting links where I can refer to.
Thanks in advance,
Copy link to clipboard
Very important: Do not use JPEG/JPG for screen captures.
The compression applied to JPG is what is making your images blurry.
I have had great success with all of these techniques
While the last option (pasting directly to FrameMaker) is likely going to invite a few comments here, it is far and away my recommended approach for screen captures. My books have hundreds of these captures, and they print without loss of quality, and do not slow down page display in Fm. Size of screen captures is related to the view size of your doc when pasting. For me, viewing my doc at 160% when pasting gives a consistent legible size to the images.
*Remember, RoboScreenCapture is included with FrameMaker
I was just going to start complaining, but then read your "While the last option (pasting directly to FrameMaker) is likely going to invite a few comments here" … 🙂
That said, let me throw in some arguments, why you should not do it:
Hi Stefan, and apologies to Vinayakrishna, as we're starting to hijack his thread!
I wish this were an easier topic to nail down, but for this entire topic, the answer is generally "It depends..."
There is no one-size-fits-all image handling advice, so all of this is meant as an academic discussion...
I believe each should evaluate their own workflow and make their own decisions based on (among other factors)
Here are my questions related to your list:
1. When you say "It blows up your documents" what do you mean? In my experience, when pasting from the clipboard, the .fm size is optimized, the images don't degrade scrolling speed, and my docs don't crash.
2. Why do you think it makes maintaining images more complicated? In my experience, when a screenshot needs modifying, a file saved to disk is generally not of much use. A new screenshot is required. Also, in my experience, screenshots don't have a high level of reuse. I would submit that the time spent processing, saving, and managing single use screenshots far outweighs the benefit of saving screenshots to disk and modifying/reusing them. Put another way, I think maintaining a library of screenshots is MUCH more complicated.
3. True, for XML (or other structured docs) pasting the image from the clipboard will create invalid structure. Invalid structure is never a good thing, and for structured workflows, I retract this method!!!!!
4. Do you expect the localization to occur on the original images via Photoshop? If not, what's the difference between managing the images placed in the doc versus managing nested folders of saved images? Either way, the localizer will need to reproduce the context of the screenshot and reshoot.
Matt, let me hijack your hijacking of the hijack:
re: When you say "It blows up your documents" what do you mean?
It increases the size of the .fm by the size of the image data (rather than just being a few dozen bytes of <ImportObFileDI...
re: ... when a screenshot needs modifying, a file saved to disk is generally not of much use. A new screenshot is required.
With an import-by-ref, the sourcing location contains at least the imported image, so you know what size and color depth the replacement must be, plus what the previous author thought the ideal file format was. In my practice, that location would also have the PSD or AI master, a PDF convenience copy, and perhaps a readme.txt with some tips. Also, I often found it quicker to hack the old screenshot than set everything up for a freshly rendered replacement.
re: ... for XML (or other structured docs) pasting the image from the clipboard will create invalid structure.
That was new to me, and implies that import-by-ref is future-proofing.
re: ...versus managing nested folders of saved images?
In general, you want to give translators the best possible asset base to work with. The archiving process I used to use put all the imports in a single subdir (this does, of course, require unique names). What you get back from translators can be pretty weird, like rendered from PowerPoint, and using images from screenshots of the reference PDF you happened to include. Yikes.
Yep, while all are good points, they further highlight that graphics management is the epitome of "Your mileage may vary"
However, in my experience, the pasted screenshot takes up the same amount of space as the image preview created by Fm when using Import by Reference.
While I agree that poor practices by authors is a concern, a proper preflighting of an image in Acrobat quickly and more accurately generates a complete list of those issues. In fact, in producing books via the IngramSpark system, I've needed to preflight in order to locate images imported by reference that were preventing proper processing (whether it was improper color mode, poor resolution, or missing fonts and other resources)
In the case of my 2017 books, the publisher changed their requirements, and thus flagged a few dozen images (imported by reference) that successfully processed in the Fm 11 and Fm 2015 books. Aggravating, but Acrobat gave me the best way to locate these few dozen images out of hundreds of placed images.
I heard once that "The best tequilla in the world is the one you like to drink!"
I think the same applies to placing images...
"The best image workflow is the one that works for your organization"
The trick is in identifying priorities, including
This thread does show, however, that workflow analysis (and graphics workflow analysis in particular) can make a big difference in the time and money needed to produce your content.
Now, if there were only a course that covered topics like this...
Hello Matt, Bob, Stefan,
Sorry for the late reply.
I am really glad that you all have hijacked the thread and so much good information has come out of this healthy discussion. I got so much new things which I was not aware. It may take a while to digest all the information got here.
I guess, as Matt pointed out rightly, "the answer is generally - It depends..." and "The best image workflow is the one that works for your organization", we have to proceed with best suited workflow for the organization + cultivating all the good practices mentioned in the thread.
This forum is a boon to people like me where we can interact with experts in the field directly. Thanks for that!!
re: While the last option (pasting directly to FrameMaker) is likely going to invite a few comments here,
As does just having clipboard in the workflow. Here's a random sample from any or many historical chats about this.