persistent HTML Help filenames, id values

[naglists]

Hi,

Styler .style sheet. Arbortext 6.0 m010.

I know that you can control the name of a chunk by setting Breaks (tab) >
HTML Chunking button > Persistent file name (drop-down) > from attribute
(drop-down).

Has anyone been able to set the id value?

For example, I get the following output (via View Source in the .chm / HTML
Help file):

my title

And "#styler-id1.4.4.1" is the named target of the TOC entry and it is also
possible to open the .chm to the page and location (what I am ultimately
wanting to do) by executing something like:

ss hh "c:\path\filename.chm::/persistentchunkname.htm#styler-id1.4.4.1"&

Except I want to be able to control the id value so it would be this
instead:

ss hh "c:\path\filename.chm::/persistentchunkname.htm#persistentidvalue"&

It's easy right? You know JUST how to do that. Bueller? Bueller? Bueller?
....

I've played a little bit with HTML Help source edits, but all that is
accessible is:
<xsl:call-template name="object.id">

And removing that and replacing with an xsl:text forcing it to "qwerty"
doesn't survive the composition. Something else, I believe the function
generate-id(), ends up overriding whatever you insert where the
xsl:call-template call referenced above is made. generate-id() is
apparently a core function ... I can't find it anywhere accessible.

Oh, and I'd be happy with some other way to get where I'm going ... to be
able to author persistent links to HTML Help content generated by PE. We
went down a similar path re: id maps and DMP a while back. Am assuming the
limited functionality there is the same as here since the path is the
same/similar by way of HTML Help generation as an intermediary format.

Thanks ...

--
Paul Nagai

[ClayHelberg]

Hi Paul--

Try adding the desired labels as ID attributes on your <title> elements (or whatever the element is that is the TOC link target).

If I take the standard DocBook sample document, and use a script to set every <title>'s id attribute to "titleX" (where X is a unique number for each title), then my CHM TOC links look like this:

mk:@MSITStore:C:\work\TerraXML\test\tocnumbering\Document1.chm::/sect1sect2.html#title3

HTH

--Clay

[naglists]

Thanks, Clay. I was distracted by the fact that our linking relies on ID
attributes on the title parent, not on title. If I add any attribute, type
ID, to title and populate it, it works as you say. So now I'm trying to
hack away and cheat the fact that our IDs are on title parents to see if I
can get away without requiring an additional (or relocated) ID attribute.

But ... worst case, I can write the parent ID with "title" appended or some
similar strategy to the title element on save.

Thanks again.

[ClayHelberg]

Hi Paul--

I feel your pain, and I have often wondered about the reasoning behind the way they render links as pointing to title text rather than containers. It certainly makes things more complicated in situations like this.

You might be able to rig something in your publishing process to do this on the fly (propagating modified container ID's to the <title> element), via customizing comp_htmlhelp::htmlhelp_preprocessing ().

--Clay

[naglists]

[Crazy. Just found this in Drafts ... actually sent before it was the
weekend. Does that count as time travel?]

Now I have a couple of ways to skin the cat. Thanks again Clay.

I created a file named htmlhelp_preprocessing.acl and copied the function
htmlhelp_preprocessing into it and started the whole thing off with
"package com_htmlhelp" which overwrites just that one function leaving all
the rest in the core source alone.

Then I added this to the end of the function, just before return 1: