Mif2Go anchors and hrefs

[Rick Quatro]

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-bounces at 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.