> I put an image into an anchored frame ...
Two conjectures (and there may be more):
- The image isn't really in the Anchored Frame (AF).
- It's just an eggregious display artifact.
I can simulate this by repositioning an object in an AF, and failing to keep the sprite inside the frame. This causes the graphic to actually be on the page, and no longer part of Flow A. Even so, unless I also do a Send-to-Back, it ends up obviously on top of the frame line, unlike your screenshot. Chances are this isn't what you have.
What's the graphics file format?
Does screen refresh (Control-L) have any effect?
Does changing the zoom level have any effect?
All good suggestions…
The image is really inside the frame. I think it may be a display artifact because when I print, the pages look okay. Screen refresh has no effect. Zoom level has no effect. Graphic was pasted in.
I found that if I import and link the graphic rather than pasting it, the problem goes away. However, for the particular project I'm working on, pasting is the most efficient workflow.
> Graphic was pasted in.
So if the original was brought by Copy-Into-Document, then the pastie will be as well.
Any idea what the original graphics file format was? When first pasted in? In what version of FM? On what platform?
I'm wondering if there's some chance here for graphics import filter problems. Do CID images get re-filtered? Just on document open? I don't know.
> I found that if I import and link the graphic rather than pasting it, the problem goes away.
Import-by-Reference is all we do except for the most trivial FM graphics elements, so this may explain why I've never seen this. Import-by-Reference also has multiple advantages for document and image stewardship.
Framemaker certainly exhibits multiple often-annoying artifacts when working with images in anchored frames, but I've always found the AFs and any Graphics Frame inside an AF, to be quite reliable clipping paths in both preview and output.