Huge html file output

I have 2 FrameMaker 10 files (out of 9) that reach a point in the document conversion to html where Mif2Go keeps running and the html file it's creating starts to swell. It's been up to gigabytes when left to it's own devices. The only way to stop it is to end the process on the DCL driver.
I've isolated the error to somewhere within 10 pages of the offending Frame file. Comparing the offending section with files that do work and have similar sections, I can find no difference in tags, markers, etc.
Any ideas where to look? What to do?

Need test case

Hi! that sounds like a bug, but it's one we have not seen before. Could you make one fron the 10 pages you've isolated it to? We need the .fm, both .inis plus any you've edited in the %omsyshome% tree, the MIF (Very Important!0, and all outputs you got including the log file. You can stop the process with Task Manager as soon
as the HTML becomes bigger than you expected.

Huge HTM File

Any ideas?

Thanks,

Bill

Bill

Huge HTM File

I isolated the problem to mixing ordered lists with unordered lists. It seems that an unordered list nested inside an ordered list stalls the conversion process and swells the resulting html file until you end the process. I have a zip file with all the conversion documents to demonstrate this.

Hmm....there's no button to attach a file to this message. So you can download it here... http://WilliamLeRoy.com/MIF2Go password is MifFtooG0

Bill

Missing settings

Once we got it downloaded, which took a few tries because the download kept aborting, we checked your _m2html.ini and found the problem. You need:

[HTMLStyles]
Numbered1=LLevel1 List1 LFirst
Numbered=LLevel1 List1
Bullet_Dot=LLevel2 List6 LFirst LNest

Note the added LFirst, and especially the LNest, properties. In the User's Guid, par. 21.11.2.3, "Converting nested lists", explains these settings, and the necessity for LNest.

Also note that we no longer recommend this method of coding lists, since with CSS progress you have much better options. The method you used is one we devised for the Netcape 2 era... quite a while ago.

With just those changes (plus path changes for our test system), the file runs in under a second and produces output that Firefox has no prolem showing.

HTH!