Hi Jeremy, Thanks for your generous reply. The FrameScript process ensures unique markers as it collects the heading text. It appends numbers on the end of any duplicates it finds.
I understand and appreciate the reasoning and cautions behind your methods. However, in this case, the client is requesting this because the HTML is going to be uploaded to a system that requires this format for the anchor elements. I am trying to accommodate their requirements, even though they would not be appropriate for other systems. Thanks for the pointer to the Mif2Go help and your explanations. Rick -----Original Message----- From: framers-boun...@lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of Jeremy H. Griffith Sent: Thursday, October 10, 2013 11:08 AM To: 'Framers' Subject: Re: Mif2Go anchors and hrefs 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/ _______________________________________________ You are currently subscribed to framers as rick at rickquatro.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lists.frameusers.com/mailman/options/framers/rick%40rickquatro.com Send administrative questions to listadmin at frameusers.com. Visit http://www.frameusers.com/ for more resources and info.