Mif2Go anchors and hrefs

[Jeremy H. Griffith]

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/