Index entries – too many page numbers at the highest level

[Bill H]

Can anyone tell me why I get all these page numbers after a first-order index entry, for example:

(Output: PDF. Using XMetaL 5.1, OT, RenderX through XDocs)

IP address 19, 53, 55, 60, 78, 93, 101, 102, 110, 121, 122, 123
       available addresses for computers and other devices 101
       computer 101
       DHCP 93
       (and so on… numerous other entries)

Example entry:
IP address   class=”- topic/indexterm “>computer

But elsewhere in the same index I get what I really want–no page numbers with the main entry:

LEDs
       front panel 88
       LAN port 89
       purpose 87

Example entry:
LEDsfront
panel

I thought maybe the cause was an extra space after “- topic/indexterm “> as in (second line):

IP address   class=”- topic/indexterm “> public IP address

But I removed such spaces and still get the same result. Can anyone tell me what's going on here? As shown above, I see this behavior for some entries, but not others in the same index.

I took the example entries above, removed the text part, and did a character-by-character comparison. I see no difference.

“Someone out there in DITA Land will know…”

Reply

[Bill H]

Correction: I'm using XMetaL 5.5!

Reply

[Jill]

I don't know if this is related, but I'm getting those extra page numbers if I configure a start-end range on a nested entry. The page range is being applied to the nested term and its parent. 

For example, the code for a sample starting entry looks like this:

sample termnested term

(and I add the corresponding ending entry to the end topic)
Output looks like this:

sample term
3-7
    nested term 3-7

I'm using 5.5 as well. I hope I'm not hijacking Bill H's thread! Thanks anyone for any suggestions.
Jill

Reply

[Su-Laine Yeo]

Bill, could you please zip up your map and topic files in which you see the problem, and email them to me? Jill, if you could do the same that would also be helpful. I'm at syeo [at] justsystems.com .

I took a look through the Open Toolkit bug tracker on Sourceforge and couldn't find a description for either of the above problems. I'll try to reproduce the problems on my own machine.

Cheers,
Su-Laine

Reply

[Jill]

Hi Su-Laine,
Thanks so much for your help! I just emailed my .zip file.

Kind regards,
Jill

Reply

[Su-Laine Yeo]

Hi Jill,

Thanks for sending me your files. I believe this problem can be fixed by refactoring the index markers in your content. For example, you have this in one topic:

sample termnested term

and then in a second topic you have:

sample term

If you remove the parent index marker from the second topic, you should get the results you want. E.g. it should be a single index marker looking like this:

I've tried this with a few of your index terms, and it seems to solve the problem.

Cheers,
Su-Laine

Reply

[Jill]

Hi Su-Laine,
That worked on this end, too, hooray! Thanks again for your help, I really appreciate it. 🙂

Jill

Reply

[Bill H]

Hi Su-Laine,

I just saw your request to send zipped files. I've sent them. Looks like my problem may be the same as Jill's, but I'm not sure.

Reply

[Su-Laine Yeo]

Just so everyone knows: Using Bill's files, we weren't able to reproduce the problem with XMetaL 5.5, although the Bluestream team was able to reproduce it with XDocs.  As far as we can tell, the problem does not have anything to do with XMetaL.

Su-Laine

Reply

[Author]

Posts