Re: Trouble with WWP and JavaHelp

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Mon, 13 Nov 2000 16:09:23 -0800, "David Knopf" <david@knopf.com> wrote:

>Jeremy H. Griffith wrote:
>
>| That sure looks like a WWP bug.  Have you notified Quadralay?
>
>No need. This works just fine in the current version of WWP.

Are you sure?  You seem to have missed the point entirely, below.

>| Also, the way JavaHelp works, any entry that appears in two different
>| markers, like your:
>|
>| 	secondary entry 12, 15
>|
>| is going to be problematic because you only get to specify one of
>| the targets, not both:
>|
>|     <indexitem target="secondary target" text="secondary entry"/>
>|
>| which means one of your refs is just gone.  When we asked Sun about
>| this design error, we were told "don't do that", i.e., make sure
>| every single index marker is **unique**.  If you avoid this "error",
>| you may find that the WWP bug (missing first-level line) goes away.
>| Or not.
>
>That's odd, Jeremy, because the JavaHelp helpsets I produce with WWP have
>secondary index entries like Gayle's, and they seem to convert just fine. I
>haven't had a chance to try this with Mif2Go recently, but I don't see why
>this wouldn't work there, too. This doesn't appear to be a fundamental
>limitation in JavaHelp.

The point which you missed is that in Gayle's test case, she had
*one* secondary entry with *two* targets, on two separate pages.
There's no problem with multiple entries with *single* targets,
which is what you offered as an example of something that works
in your other post:

>I'm not sure why you're seeing this result. I have no trouble converting
>second-level index entries with multiple targets. Here is a snippet I just
>generated:
>
>  <indexitem text="Heidelberg">
>    <indexitem target="c022_html_1019677" text="documentation templates"/>
>    <indexitem text="template guidelines">
>      <indexitem target="c022_html_1019677" text="Overview "/>
>      <indexitem target="c0211_html_1021756" text="Tagging FrameMaker
>Documents "/>
>    </indexitem>
>  </indexitem>

Here you get around it by adding another level, with different text
for the two tertiary entries.  Not the same at all...  The issue 
Gayle raised is what to do when you have:
  primary entry
 	secondary entry 12, 15

The logical thing would be to produce:
  <indexitem target="primary target" text="primary entry">
     <indexitem target="secondary target on p12" text="secondary entry"/>
     <indexitem target="secondary target on p15" text="secondary entry"/>
  </indexitem>
but that's not what WWP did.  If you do it that way, you get the rather
ugly JH index:
  primary entry
 	secondary entry
 	secondary entry
What Sun said you had to do in such a case was:
  primary entry
 	secondary one 12
 	secondary two 15
so that you have:
  <indexitem target="primary target" text="primary entry">
     <indexitem target="secondary target on p12" text="secondary one"/>
     <indexitem target="secondary target on p15" text="secondary two"/>
  </indexitem>

In contrast, MS HTML Help deals with the same issue by showing:
  primary entry
 	secondary entry
and then bringing up a dialog with a list of referenced topics
to choose from when you click on the secondary, just like in
WinHelp.  Too bad Sun didn't do the same sensible thing...

>| >2. Display problems
>| >
>| >When I run the .hs file and click an entry in the TOC, the main panel
>| >displays 2 overlapping versions of the page. This happens even for pages
>| >that don't include an anchored frame. I'm using JH 1.1.1 and the Java 2
>| >run-time environment, build 1.3, which I thought was supposed to fix this
>| >problem.
>|
>| Well, a Sun person announced on the JavaHelp list that this Sun bug
>| was fixed in "JDK 1.3", which presumably is what you have.  It's not
>| the first time we've seen misleading statements or outright lies
>| from Sun.  As it happens, we discovered the cause of this bug, and
>| built a (proprietary) solution into Mif2Go's JavaHelp output, so
>| Mif2Go users are spared this particular frustration.
>
>This bug is resolved in JDK 1.3, or at least it appears to be based on the
>fact that neither we nor any user of one of our production JavaHelp systems
>has been able to duplicate it on 1.3. In any event, I don't think there's
>any need for a proprietary solution here. In fact, there are well known
>workarounds for this problem even on JDK 1.2.2.

Really?  Neither Sun nor anyone on the JavaHelp list knew of any such
"well known workarounds" when asked.  What are they, pray tell?  Even
if 1.3 is supposed to fix it, not everyone will have 1.3 installed...
and unless Gayle's installation was faulty, she just provided the
"smoking gun" report that it is not fixed there for everyone anyway.

-- Jeremy H. Griffith, at Omni Systems Inc.
  (jeremy@omsys.com)  http://www.omsys.com/

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **