Mif2Go - FM graphic sizing issue when outputting to HTML

[bja]

Jeremy is correct.

I  initially sent this query to the list (Jeremy must get a squillion
queries and I thought the list could answer this one) but for some reason it
didn't get posted so after waiting 50 minutes or so I also sent the query
direct to Jeremy (and corrected the ENBEDDED typo:)).

Jeremy has since answered my query and I have since taken the necessary
steps to resolve the issue.

Thanks again Jeremy.

A pity it took 4.5 hours for the posting to hit the list but fortunately
Jeremy was much quicker. :)

Let's see how long it takes for this one to be posted.

Cheers,

Bruce


-----Original Message-----
From: framers-bounces at lists.frameusers.com
[mailto:framers-bounces at lists.frameusers.com] On Behalf Of Jeremy H.
Griffith
Sent: Wednesday, 7 May 2008 12:25 PM
To: FrameUsers
Subject: Re: Mif2Go - FM graphic sizing issue when outputting to HTML

On Wed, 7 May 2008 07:33:20 +1000, "bja" <moo-man at optusnet.com.au> wrote,
but the list diddn't post it for some hours.  In between, we answered the
same post, also sent to us, directly:

>I have dozens of graphics EMBEDDED in my FrameMaker documents at 
>various dpi settings. All print well of course.
> 
>I convert to Standard HTML using Mif2Go.
> 
>By default Mif2Go retains the FramaMaker image sizes so many of the 
>graphics are unreadable in the finished HTML.
> 
>To resolve this, I set the following statement in the mif2htm.ini file:
> 
>[GraphScale]
>*=0
> 
>In the past (using FM7.1), this setting reverted the graphics back to 
>their original DPI setting and undid any FM editing as well (such as
rotation).
> 
>Now, I am using FM8.0 and the above statement does not appear to work 
>any more.

It won't for embedded graphics, only for referenced.  The reason is that
with embedded graphics, we have to have Frame use its native graphic export
filters to produce images, and those always resample the graphics to the DPI
specified at the size of the anchored frame.

>This should have the same effect as the *=0 statement so I am wondering 
>if there is something I am not taking into consideration or if this 
>might be another FM8.0 issue.

It's not 8.0, it's always the case for embedded graphics.  Another reason
that's a Real Bad Idea, as if more were needed...  ;-)

>As an aside, I cannot test this as I am no longer on site and only have
>FM7.1 at home (I do have a copy of the mif2htm.ini file though). I am 
>just trying to be of assistance to a previous manager so any help would 
>be greatly appreciated.

What you can do is labor-intensive, but you only have to do it once:
change from embedded to referenced.  If you still have the original
graphics, you can re-import them by reference with the embedded one
selected, and the referenced one will replace the embedded.

If you *don't* have the originals, you can export the embedded ones from
Frame with Mif2Go, rename them appropriately, then re-import as above.  See
par. 29.2.3.2, "Exporting embedded graphics before converting".

HTH!

-- Jeremy H. Griffith, at Omni Systems Inc.
  <jeremy at omsys.com>  http://www.omsys.com/
_______________________________________________


You are currently subscribed to Framers as moo-man at optusnet.com.au.

Send list messages to framers at lists.frameusers.com.

To unsubscribe send a blank email to
framers-unsubscribe at lists.frameusers.com
or visit
http://lists.frameusers.com/mailman/options/framers/moo-man%40optusnet.com.a
u

Send administrative questions to listadmin at frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.


--
No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 269.23.9/1418 - Release Date: 5/6/2008
5:17 PM