I'm running Framemaker 11 on a Windows 7, 64-bit machine with an i7 processor at 2+ ghz and 8.0 MB RAM.
My Frame files, with imported/referenced images, are scrolling extremely slowly. When I say slow, I mean as the page scrolls into view it freezes for 10 - 20 seconds before "catching up" and displaying the page.
I have a "background" image on my master pages that contains simple graphics for the top header and some borders to delineate areas of the page. Those backgrounds are imported. Thjese imported files are about 1.1 MB.
My remaining images are imported by reference on the various body pages. They are .ai files and are 2.5 - 5 (ish) MB in size.
I've been searching for an answer. My deadline is going to pass my by while I wait for pages to load. Please help!
FM tries to render the gaphic on each page so it takes time. You can always temporarily turn off the display of imported graphics using the esc v v shortcut. This is a toggle that works at the book level (if you select all files). The pages should load as fast as you can advance after you turn off the graphics.
Just remember to turn them back on when yo go to create your final output.
Thanks. I'll try that tomorrow. I'm sure it will work fine, but it isn't my "perfect" solutoin. I mostly want to see my text and graphics together for cross reference. It's been a few years since I was a heavy Framemaker user, but I spent the better part of the late 90s and most of the 2000's in Frame with similar or larger/more complex graphics. I don't remember this ever being an issue (always with .ai or .eps files - linked).
Could there be something else?
The .EPS and .AI files of that era were close to the same format as EPS and used low-res preview images (for precisely that purpose of not having to render the full graphic for screen work).
The current .AI files use a PDF-based format which FM thinks is a true PDF and tries to render (it does an internal conversion to EPS and creats a high-res preview raster all on the fly, so it's actually doing extra work). Directly importing current .AI files is not recommended as you can lose features and content because it's not a true PDF format. Create EPS files from the .AI files and try using those instead.
I was encountering the same problem with some of my larger AI files. I converted them to EPS, and it works much better (although my graphics designer is throwing an absolute fit because the images look horrible when viewing them in FM...I keep reminding him it's about the finished product ), so thanks for that!
One other question - I have one manual that loads extraordinarily slow, but all the images are imported JPGs. I have read that JPGs aren't the way to go in FM...any advice on a better file type for screenshots and photos?
Thanks a lot,
> ... I have read that JPGs aren't the way to go in FM ...
We convert them to EPS as well. EPS does raster. It does, however, always come in at "100%" in FM, and you cannot learn the dpi from FM. You can choose CYMK or RGB, depending on your color management needs.
> any advice on a better file type for screenshots and photos?
Screenshots are a different matter. Because they tend to contain long repeats of single pixel colors, we use TIF for that, as they compress well with any of the repeat-count compressions. You could also use EPS, but the FM preview is apt to be illegible.
A challenge with screen shots is avoiding having them re-sampled during render to PDF. I would recommend importing them at native res (typically 72 or 90 dpi), and keeping that below the threshold for whatever resampling is done in PDF print, Distill or Acrobat Optimize. If you need to scale screenshots, use integer multiples or fractions, and "nearest neighbor".
> ... although my graphics designer is throwing an absolute fit because the images look horrible when viewing them in FM.
You can improve EPS (and PDF import) preview by using the scaling trick (up to 500%) or so. Rescale the source image up (elect rescale stroke and effects) before saving to EPS. Rescale down after import to FM. The final file size won't change materially for vector art, and won't be much different for contone raster if your rendering workflow is set to resample down to what they were to begin with. The preview will be 4x sharper, but still indexed color.
Naturally. there is a small performance penalty for using the scaling trick. Also, the previews are metadata that will survive into, and inflate the size of the PDF, unless redacted downstream (Examine Document in Acrobat Pro; later versions of PDF printing and Distill may have an option for that too).
Another preview performance killer is rotation. Anything other than importing at 0 degrees can send FM off into la-la land.
Bad network fs performance can bog you down too.
This is fantastic information. I'd like learn more about your recommendaitons for future projects where an imminent deadline doesn't preclude time for my learning curve. Do you have any additional resources or links you could share for the "scaling trick" procedure? Most of your short description went over my head.
Great advice about rotation too. I haven't encountered a need to rotate, but I'll keep it in mind going forward.
> ... additional resources or links you could share for the "scaling trick" procedure?
Here's an older thread:
There is an upper limit to the size of a preview image, which is apparently some total number of kbytes. Doing the scaling trick at 400% save and 25% import usually doesn't hit it, and in my experience, apparent preview quality doesn't improve much above 400% anyway.
If you routinely use this trick, and neglect to redact metadata downstream, your PDF file sizes will balloon substantially.
Remember, JPGs are for photographs and are highly compressed. The compression has to be expanded to a raster image that FM can display, so the sizes (& work required) can add up. FM also uses the system TEMP space for a lot of the work, so it helps if this is on a fast drive and has lots of room.
For photos, JPG is a viable option. Balance your settings for compression to get better speed vs image quality depending upon your target output.
For screenshots, you're much better off with PNGs or if there aren't that many screen colours a GIF would suffice.
If you're creating for press-quality work (CMYK), then TIF or even EPS (yes it stores rasters, but gives the same low-res preview for speed) can be used. From Photoshop, if you save an EPS, make sure that you have the postscript interpolation option enabled for the smoothest colour gradations.
Just to take it one step further... What about Illustrator files with placed screen images. OK to use JPG? The TIF files are huge. I'm placing screen images in Illustrator to add callouts or to enhance other elements.
Great info... thanks for the thoughtful and helpful responses.
It really doesn't matter how big the TIFs are, an equivalent JPG will expand to be the same size within FM and for output to postscript when creating a PDF.
When saving the file from Illustrator, the placed image file format really doesn't matter, as the image info will be repackaged for the saved file format.
JPGs are for photos, but keep in mind that this format uses a lossy compression and depending upon the image contents (lots of straight linear objects, sharp transitions between objects, etc.) a JPG may introduce some undesirable artifacts vs. TIF.
Thanks for all the good stuff Error and Arnis.
Our final output is for print (CMYK), so I'll need to weigh the pros and cons of taking the time to convert the photo JPGs to EPS. The PDFs look awesome, but it just takes forever to load the FM files. More annoying on my end, but it is just one book that has this issue. I have a sneaking suspicion that the drive my TEMP folder is located on isn't all that fast and network resources are definitely limited here. We're a small company, and I'm the only one using FM to generate documents - everyone else is using ID or PowerPoint (don't get me started).
For screenshots, I'll look into PNGs...I started out trying to save screenshots as PNGs, but they just appeared blacked out, which, according to IT, could be a graphics card issue. As a workaround, I started saving them as JPGs because it worked and I had no time to futz around with anything. Now that I have some time, I'll revisit this.
Anyway, thanks again for the guidance once again!
I know I'm resurrecting an old thread, but this (esc v v) trick needs to be reiterated for these times of sequestration against coronavirus. Our network is highly secure, and when Frame makes calls to the linked grafix, it just HALTS and flashes as it tries to pull the files and redraw the screen. This makes waiting for the grafix to load a huge, time-sucking annoyance. How bad? Try a penalty of 60× real time! I actually missed a deadline because of this - fortunately my manager also has problems with her software working over the network, and there were no repercussions.
Turning off the grafix gets me back to work at my former fast pace.
Are you using FM2019. We do have a plan to provide a flag with the upcoming update 6 of FM2019 which should be helpful in these scenarios.
Yes, you are correct, this is FM2019.
Is there a comprehensive list anywhere of the Escape Codes for Frame? The ones I know (which are a lot) I've found and remembered through necessity; but it sure would be great to have a list...
InDesign has a low-res mode for displaying graphics so you can still see them, but they display faster. Perhaps this feature could be added to FrameMaker.
Agree. Both low rez AND high rez preview would be a big benefit to FrameMaker.
Or, perhaps you could cache graphic display to happen after text is displayed like web browsers do.