<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Chris Coggins wrote:<BR> <BR>
<DIV id=SkyDrivePlaceholder></DIV>
<DIV>>What is happening on the problem user's computer is that the frame file he generates </DIV>
<DIV>>retains the object faces PDF and EPSI, and also adds a FrameImage facet after going </DIV>
<DIV>>through the same steps listed above. His frame files are enormous, 19 megs for the same </DIV>
<DIV>>file used above, and the resulting PDF files are also huge (17megs). When compiled into a </DIV>
<DIV>>complete book, he's generating 200meg PDFs whereas the rest of us are only putting out </DIV>
<DIV>>10meg books.<BR>><BR>>Can someone help me understand what's happening during the import/embed process </DIV>
<DIV>>and why we're getting different results across our users?<BR><BR>Generation of a FrameImage version of imported graphics is an option that is enabled/</DIV>
<DIV>disabled from the Preferences dialog It's in the Compatibility Preferences section and it's</DIV>
<DIV>called somethng like Save FrameImage with Imported Graphics. </DIV>
<DIV> </DIV>
<DIV>FrameImage is an archaic and largely obsolete method for ensuring cross-platform</DIV>
<DIV>portability of graphics. The idea was that if FrameMaker stored a version of the graphic </DIV>
<DIV>in a format that it was guaranteed to understand, it wouldn't matter whether the original</DIV>
<DIV>graphics was in a UNIX-specific, Windows-specific, or Mac-specific file format. But since</DIV>
<DIV>only the Windows version of FrameMaker is still a living product, there's no point to </DIV>
<DIV>FrameImage. And that's doubly true if you're already usiung PDF, which is highly portable.</DIV>
<DIV> </DIV>
<DIV>-Fred Ridder</DIV> </div></body>
</html>