Re: Another Mif2Go Question

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Tue, 8 May 2001 09:58:26 +1000, hedley_finger@myob.com.au wrote:

>Glenn is correct in stating that you can produce other kinds of HTML-based
>help from mif2go.  But MS HTML Help and JavaHelp are the only HTML formats
>that package Java applets, ActiveX controls, and JavaScript controls to
>display those nifty Contents tree, Index listing, Search, and Favorites
>tabs.  Unlike ForeHelp, RoboHelp, Webworks Publisher, etc. which supply
>their own proprietary 'universal' cross-platform formats complete with
>navigation functions, mif2go does not.  

Correct, though we will certainly support the first *standard* format
to come along, and may be adding a cross-platform viewer to the package 
soon.

>If you use one of the other vanilla
>HTML/XHTML formats you will have to roll your OWN JavaScript or obtain it
>from elsewhere.  You can use macros to incorporate applets and scripts into
>the HTML output stream.

True.  You can also use the FrameMaker TOC, IX, and any other lists you
like in your navigation scheme; we fully support framesets.  This is not
difficult to implement.  IMHO.  <g>

>But I have to tell you that, although I am a FrameMaker expert, I have been
>trialling-and-erroring (horrible word!) for over a week to get satisfactory
>results and the end is not yet in sight.  You configure mif2go by editing a
>very large *.ini file that is partly documented in a manual and partly in a
>cryptically commented version of the file.  If you are not a FrameMaker
>expert, be prepared for a learning cliff.

LOL!  Yes, we agree, the existing docs could use a lot of improvement,
and in fact have a total replacement doc (in FM) almost ready to go out.
Much of the problem is that we use a development model common in the
open-source community, in which corrections and enhancements are made
*very* often, sometimes twice in a week.  Having the docs track the
engineering is a major effort, one at which we have not done well.  But
the alternative, holding up software release until all is in sync, is
not appealing either; it forces people to live with pain that could
have been avoided.  Instead we live with the always-current "cryptically
commented" m2h_full.ini (with comments from engineers), plus a manual
that does a much better job at explaining but isn't totally current.
Not ideal, but then we also want to keep Mif2Go affordable for all...

>That said, the initial output with vanilla settings was quite impressive
>although the output was bloated with <font> tags that I am presently
>replacing with <span> tags via macros to handle char formats.

The <font> tags are there by default because NetScrape 4.x has poor
support for CSS, the more desirable alternative.  They can be turned
off with a single setting if you only want to use IE.  And the <span>
tags are created with a single setting for each char format...  It's
hard to see how we could have made it any simpler.  Of course, making
HTML that supports all the browsers out there is almost as much fun
as herding cats... there's not much we can do about *that*.

>Once this pain is over the result should be a universal process with all
>mif2go options, CSS formats, and macro includes that can be applied to all
>of our user guides with 'just a click of the button'.  But there is
>considerable pain getting there.

If we understood the source of the pain, we'd do our best to eliminate
it.  We've noticed that some customers have problems, others (who are
creating output just as complex) have none at all... perhaps that is
just the nature of life.  One size never fits all.

-- Jeremy H. Griffith, at Omni Systems Inc.
  (jeremy@omsys.com)  http://www.omsys.com/

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **