On Wed, 05 Nov 2008 15:21:53 -0500, Jim Owens <jowens at magma.ca> wrote:
>I'd like to use these, but I'm having trouble. > >The latest beta revision history file for Mif2Go explains that the >$_prev and $_next macros have been updated to support browsing backwards >in true sequence, even across chapter breaks. (Formerly, according to >the documentation, the "Prev" button would leap from the first topic of >a chapter to the first topic of the previous chapter.) The history file >also says that the [FileSequence] section has been deprecated. > >I've downloaded and installed the latest dwhtm, m2gframe, and m2rbook >dll's. First, please recheck that you have the *very* latest betas. We update them quite often, and this is a feature we just completely recoded with many improvements. It does work for the User's Guide. >I've set StartingSplit=Yes as suggested in the history file. For >personal preference, I've set UseNavButtons=Yes. Because the >[FileSequence] section is deprecated, I haven't added it to my ini file. That's all good. >I've referenced a macro for [Inserts} Top=, and in the macro I've >invoked <$_prev><$_next>. Correct. >The buttons appear in the output as expected, and within a given chapter >they work. However, they do not go from chapter to chapter. At the end >of a chapter, the Next button does nothing. At the beginning of a >chapter, the Prev button does nothing. In addition, for the first topic >in a chapter, the text in the Prev button reads "Test File from Mif2Go". So the inter-chapter links are not working. See if you have a .lst file in your working directory; if not, you may not have the latest m2rbook and m2gframe DLLs installed. You should also have a file m2g_log.txt, which may contain entries descriptive of the problem, another new feature. If so, we'd like to know what the log says. >There is a special consideration regarding my Framemaker source: each >chapter begins with a single paragraph tagged either "Chapter" or >"Appendix", followed by an "h1" paragraph. I am using the h1 paragraph >as a split point. That should work. >The Chapter and Appendix paragraphs are not used as split points. They >provide for some fancy formatting on the chapter title page and in the >TOC. Each one contains a ChapterNumber variable, some autonumber text >(set to white), and a Frame Above. I have assigned "=Delete" to them in >[HTMLStyles], but I suspect that they are causing an HTML file to be >created anyway. Regardless of how I set StartingSplit (Yes or No), the >output includes an HTML file named for the chapter, and this file >contains three <a name=> elements, as well as the standard header and >footer that we use on all pages. Yes. The history file really isn't the full doc; that will be in the next User's Guide, in final production right now for 52. But this file is indeed created, and necessary. When you use [Automation], though, it is not retained in the Wrap directory, so it does not become part of your deliverable. >This file is the one linked from the "Test File from Mif2Go" button. That is *not* right. However, we see the problem. Even though you have marked the para for Delete, it is still there, and Mif2Go knows it. You see, StartingSplit simply allows a split before the starting para, provided that para is indeed set to Split in [HTMLStyles]. It sounds like yours isn't. So as far as Mif2Go is concerned, the first file is still part of the deliverable. Does the Prev button on the first file actually link back to the previous file? If so, the links *are* working; likewise, the Next button at the end should link to the first (removed) part of the next file. In that case, what you need to do is fairly simple. Just use Frame conditional text to remove the first unwanted part of each file for this output. Mif2Go can handle hiding this condition for you, another newly-added feature. That's the easiest way to get what you want. This isn't a bug; Delete has a more limited purpose, by design. It only removes the paragraph content, and any Frames Above/Below, from the output. But the para content is still usable in macros; in fact, we use such paras that way for special purposes in producing the User's Guide. Delete does *not* remove any anchored frames or tables that are anchored in the Deleted para, so it is also used to remove anchor paras that are not wanted in HTML output. Conditional text would, in that case, remove the figures and tables too, not what you want. >If I comment out Chapter=Delete, I get the same file, but containing >the Frame Above referenced by the Chapter tag. Right, but in that it's not used anyway, conditioning it out would be better. >I even tried deleting the Chapter tag in one chapter. With >StartingSplit=Yes, I still get a "Test File from Mif2Go" Prev button on >the first page of the chapter, and the button opens an empty page >(except for the headers and footers). With StartingSplit=No, I get a >blank Prev button at the beginning of the chapter, and this button does >nothing; and the Next button for the last topic of the preceding chapter >still does nothing. You still have *some* content before the first h1, though. That's the problem. >I hope I haven't provided too much detail. I would like the Prev and >Next buttons to work end-to-end. That should happen as soon as the first h1 really starts the file (because the content before it is conditioned out). >Once they're working, I'd also like to >use graphics for the links instead of text (as in <a >href="next_topic.htm"><img src="Next.gif"/></a>). You mean, instead of buttons, right? You can do that by editing the [NavigationMacros] themselves, replacing the <$$_*title> in each with your <img> tag. Note that the user will no longer know where the link will take her, though; we advise against this. >P.S. I considered writing my own macros, but I came up against this >problem: when writing the last topic in Chapter 1, I haven't processed >Chapter 2 yet, so I can't define the link to Chapter 2's h1 topic. I >seem to need two passes, one to define all the topic file names, and >another to add links to any topic file names that occur later in the >document. Is there a way I can do this? It's not really necessary. We had a similar system before the rewrite of the <$_prev>/<$_next> code, and it was hard to maintain. That's one of the main reasons we made this enhancement. If you continue to have any problem with this, please send us a trimmed-down test case, like a book with two or three one-page files, so we can help you further. Include the .book, .fm, .mif, both .inis, .prj, and *all* output files (including the log), all in one .zip. We'll look into it promptly. HTH! -- Jeremy H. Griffith, at Omni Systems Inc. <jeremy at omsys.com> http://www.omsys.com/
