RE: Trouble with WWP and JavaHelp

["David Knopf" <david@xxxxxxxxx>]

Jeremy H. Griffith wrote:

| 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?

Quite sure. Gayle was concerned because "the line containing the opening tag
isn't coming through at all." You stated that this "looks like a WWP bug."
Did you test it in WWP before making this assertion? I did, and I cannot
reproduce the behavior Gayle described, nor have I ever seen this behavior
in any helpset produced by WWP.


| You seem to have missed the point entirely, below.

Actually, I haven't missed the point at all. I may have failed to spell it
out clearly enough, though, so I'll try again.


| >| 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:

Actually, not. My example is parallel to Gayle's. I just failed to give you
both the original and the output. The FrameMaker index looks like this:

	Heidelberg
		documentation templates 2-1
		template guidelines 2-1, 2-6

Converting these index entries through WWP to JavaHelp results in the code I
posted earlier:

  <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>

Note that all opening and closing tags are present; that was the issue Gayle
raised and that you labeled a "WWP bug."

The index entries will display in JavaHelp as:

	Heidelberg
		documentation templates
		template guidelines
			Overview
			Installation

where "Overview" and "Installation" are the titles of the topics containing
the two markers for "template guidelines."

IOW, WWP handles *one* secondary entry with *two* targets by adding a
third-level entry with the topic titles for the target topics. This, by the
way, is parallel to the behavior of WinHelp and HTML Help, except that the
topic titles are displayed within the index instead of in a separate "Topics
Found" dialog box.


| Here you get around it by adding another level, with different text
| for the two tertiary entries.  Not the same at all...

Not the same as what? And what am I "getting around" here? I am presenting
an online index whose structure matches the structure of the printed index.
I thought that was the goal. Users have certainly had no difficulty with it.


| 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>

I fail to see how an index entry in an online index that references "p12"
and "p15" would be more logical, but perhaps I am missing your point.


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

Ah, perhaps I'm getting it now. If you define "JavaHelp bug" as any instance
in which Sun does not exactly follow the example set by Microsoft, then yes
I guess this is a bug. OTOH, many fine products do not exactly follow
Microsoft's example.



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

Again, I don't know whom you spoke with at Sun, but Roger Brinkley and Larry
Hoffman have both been aware of the cause of this problem and the
workarounds for many moons. The subject has been discussed frequently on the
JavaHelp-Interest mailing list. Btw, I've been subscribing to that list
since its inception, and I cannot remember a post from you posing the
question (nor can I find one in the list's archives).


| What are they, pray tell?

As I'm sure you know, Jeremy, the bug in JDK/JRE 1.2.2 is triggered only by
links to named anchors within the first scroll zone of a topic. It's quite
easy to avoid such links in helpsets produced with WWP, as I'm sure it must
be with Mif2Go. I am not aware of any need for a proprietary solution.


| Even
| if 1.3 is supposed to fix it, not everyone will have 1.3 installed...

Of course not. However, if an author is creating Help for a Java application
that requires JRE 1.3, it's quite reasonable to expect that users *will*
have 1.3 installed; mostly likely, it is packaged as part of the
application. As of today, we have only one client still developing on 1.2.2.


| and unless Gayle's installation was faulty, she just provided the
| "smoking gun" report that it is not fixed there for everyone anyway.

In our testing so far, 100% of the so-called 1.3 machines that demonstrate
this bug have had a faulty installation of 1.3 or still have remnants of
1.2.2 installed or referenced in the system registry. So far, 0% of machines
with JDK 1.3 properly installed have demonstrated this behavior. Have you
been able to demonstrate that this bug exists on a machine with a proper
install of  JDK/JRE 1.3? If so, I will be more than happy to ensure that a
proper bug report is filed with Sun. In the meantime, I think references to
a "smoking gun" are more alarmist than informative.

Regards,

David Knopf (mailto:david@knopf.com)
Knopf Online (http://www.knopf.com)
Tel: 415.550.8367

RoboHELP MVP & Certified RoboHELP Instructor
WebWorks Publisher Certified Trainer
Co-moderator, HATT & wwp-users




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