Mif2Go Prev and Next navigation macros

[Jim Owens]

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/
> 
>