Thanks as always for the prompt response. I've tried your suggestions, but without success. To spare others, we can continue off-list until this is resolved.
Jeremy H. Griffith wrote: > 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/ > >