On Thu, 10 Oct 2013 10:17:49 -0400, "Rick Quatro" <rick at rickquatro.com> wrote:
>I am using more "intelligent" Cross-Ref marker texts in my book because of >the requirements of an downstream process. The marker text is derived from >the title and heading text, so you will have: > >Discovering_Applications >Discovering_Local_Applications >Discovering_Applications_Over_IP > >(I am using FrameScript to do this, so it is automated.) Have you GUARANTEED that the names are unique within each file? Frame claims to, and usually does. We see maybe one or two cases a year, in our own docs, where Frame duplicates the *number* in a cross-reference marker. Those result in puzzling failures to go to the right place. Once we have identified the problem, in a few hours work, we delete and have frame recreate the marker, and all is well again. If you are deriving these names from headings, you are doomed. Headings repeat a *lot*. >When I convert to HTML using Mif2Go, I end up with these as anchors: > >Racdiscovering_applications >Racdiscovering_local_applications >Racdiscovering_applications_over_ip > >My question is: is there a way to eliminate or control the three character >prefix (Rac) that is added to the anchor text? If not, is it always "Rac"? >Or, is it always 3 characters? My goal is to eliminate this prefix if >possible. Cross-reference markers always get the "R", just as markers based on object IDs get "X". This is necessary because otherwise they could conflict with hypertext newlink markers, which are *not* prefixed. The "ac" will be different for each source file; it is the FileID in your mif2go.ini file. That is necessary if the file is ever used in a book project, to prevent conflicts between identically-named markers in different chapter files, which are plentiful. IOW, without them, there is zero chance of your Hrlp TOC and IX working correctly, as all references would go to the first file to use the marker. You might want to reconsider your goal here. Traffic would move faster if we eliminated traffic lights and stop signs, but... ;-) This is discussed at length in User's Guide par. 5.3.4.1, "Understanding how and where FileIDs are assigned". The User's Guide is a faster way to answer questions than email... ;-) >---------- >Let me go further: my ultimate goal would be to have anchors that look like >this: > >Discovering-Applications >Discovering-Local-Applications >Discovering-Applications-Over-IP > >If I use dashes in the Cross-Ref markers, they get deleted, so I am going to >replace the underscores with dashes after the HTML is created. Then you will break the infrastructure a second way. Dashes are not permitted in some of the referencing contexts (Help systems), which is why we replace them. >But it would >be nice to maintain the original case as well. You need to remember that UNIX (on which many of the output files end up, as almost all Web servers use it) is case sensitive. Windows is not. So people tend to be inconsistent between actual filename and reference, since it doesn't matter on Windows. This results in lots and lots of broken Web links. So we force the filenames and refs to lower case so that they will work. All of these "annoyances" are the result of seeing really large numbers of bug reports and complaints about each of these issues. You should expect the same if you remove the seat belts from the vehicle. ;-) -- Jeremy H. Griffith, at Omni Systems Inc. <jeremy at omsys.com> http://mif2go.com/