Before I started here, the team was using FrameMaker 8 and migrating to FM 10. During the migration, we noticed that images in the documents we opened, converting them to FM10, had their image scaling data changed.
Typically, we acquire screen shots using the highest resolution screen supported - mine is currently set at 1440 x 900. We scale the images to a width of 510 pixels (optimally) but no more than 600 pixels in our screen capture utility. We save the screen shots as Grayscale JPEGs. This process has, historically, provided images that fit our text column flow perfectly.
In previous versions of FM, the images imported by reference appeared as 100% scaling in the FM image properties. Now, they appear as 75% scaling. We're wondering why and if there is any effects we need to be aware of in terms of PDF and HTML Help file sizes.
While testing the import process, looking to see if the FM scaling data affected the image size, we saw that the pixel dimensions given by SnagIt varied wildly from the pixel dimensions given by FM. For example, the SnagIt dimensions for one image indicated it was 505x493 pixels whereas FM gave the dimensions of the source file as 507x315 pixels. Both are, as far as I know, giving me the source file dimensions but they are different.
We might not have noticed this, the images looked okay, but we were carefully going through the transition to FM10 and looking at every detail.
Question: why is FM10 auto-scaling the images to 75%?
Question: does this scaling do anything to our output that we need to be aware of?
Question: why do we get two different dimension data from the two software packages?
There are a number of messages kind of related to migration between
revs in the forum, but to summarize, I think it's usually a really
good idea to MIF-wash (Save FM as MIF, reopen that and SaveAs .fm) any
migrated documents to remove any artifacts from previous revs.
I'm not sure it'd change/fix your files, but it may help some.
(If you download the MIF2Go eval from omsys.com, they install a MIF
washing utility that works on component files in books and stays on
your system even if you don't buy the product.)
"... In my opinion, there's nothing in this world beats a '52
Vincent and a redheaded girl." -- Richard Thompson
No disclaimers apply.
I support www.TheGrotonLine.com, hyperlocal news for Groton MA.
For images, the %scaling value isn't what is intiailly used when importing. What is the dpi value that you specify when you import the image? That determines how FM "scales" the image, i.e. it assumes 72dpi is 100% and adjusts the image relative to that.
Also, for screen captures, you really should be using a non-lossy format such as PNG (or even GIF) instead of JPG. I would check the JPG files produced in Snagit in an image editor or a viewing tool such as IrfanView (that provides detailed image info) as the disparity that you indicate (505x493 vs 507x493) is very large.
I'll ask the group about the image format used.
We import using 96 dpi. I think the team developed this process based on past experience. They didn't have this in FM 8, it just since they upgraded to FM 10 (which is where I join the team).
I'll keep poking around, see what I can see. The 75% doesn't seem to be harming the image quality at all, in fact when one of the writers changes the scaling to 100% the images look wretched.
This all may become moot, or critical, as we move towards single-sourcing and DITA.
It's unlikely to become moot. As Arnis pointed out, you're using a file format (jpg) that's ill-suited to screen shots because it's lossy. It intentionally throws away data every time the file is re-saved, so each time the image file changes, quality degrades. The process of maintaining the images is unlikely to change just because the wrapper around the images changes.
Again, as Arnis pointed out, PNG would be a MUCH better choice because it's stable....
We save the screen shots as Grayscale JPEGs.
Are the screen images contone (e.g. real-world photos, CGI imagery),
or flat (e.g. dialogs, line art)? JPEG uses curve-matching compression,
which is great for tones that vary smoothly, but introduces nasty ringing
edge artifacts on sharp edges of flat tones.
TIF(zip), uses repeat-count compression, and is both non-destructive to flat
tone images, and often compresses them more efficiently. We use EPS
for the import format (no compression) and let Distiller or Acrobat post
determine the compression to use.
This process has, historically, provided images that fit our text column
flow perfectly.In previous versions of FM, ...
What is the target delivery format?
... the images imported by reference appeared as 100% scaling in
the FM image properties. Now, they appear as 75% scaling.
In case you want to try it, I have never seen imported EPS objects
change size when migrating a document to a later rev of FM.
We import using 96 dpi.
If the target is PC screen display at 100% page size, that's probably a
decent target. PC screen resolutions today probably range from 80 to
110 dpi, and I'd guess that 96 is very close to the sweet spot.
We use (and I favor) bringing in all contone content at 200 dpi or
higher. We bring bitmap (bi-level line art) in at 600. But then our
target media is 600 dpi B&W bitmap on paper. However, we like
to give web readers of the PDFs reasonable detail in images.
Apple's "Retina" crusade is trying to move the industry to 300 dpi
displays. I'd be happy with 200.
While the JPEG algorithm does a great job at compressing gradients (such as the ones you find in photographs and illustrations with wide tonal ranges), I will echo the comments made by others on this forum that it is not suitable for bi-level images, text, and line art (dialog boxes) as it will introduce artifacts and not provide as great a degree of compression either. IrfanView has a great batch conversion utility that will convert all your images to a more suitable format. (TIF or PNG.)
There is another issue associated with the MIF-wash that has caused scaling problems for me. I do not get the scaling error you mentioned but if I have an anchored frame with an image inside it, the MIF conversion will sometimes rescale the anchored frame (Object Properties gives you the rounded off version of the "stored" dimensions you see in the MIF file (e.g. 2.828 displayed in the Object Properties window may actually be shown as 2.82899 in the MIF file).
Through trial and error, I have think that "manually" resized frames (i.e making the anchored frames fit the edges of the body frames with Gravity turned on) may give you an anchored frame that fits perfectly at the edges in the FM file, but upon saving as MIF and opening the MIF file in FM I always find some anchored frames resized larger by a thousandth of an inch (so the previous example might become 2.829) which is enough to pop it out of its frame and into the next available body frame). Not sure if this is what is happening, but in my application this has always been an annoyance requiring resizing in the MIF file. Fortunately, all my dimensions are consistent and I can simply fix this through "Replace All".
Europe, Middle East and Africa