DITA and XMetaL Discussion
XMetaL Community Forum › DITA and XMetaL Discussion › Index entries – too many page numbers at the highest level
-
Bill H March 31, 2009 at 6:07 pm
Index entries – too many page numbers at the highest level
March 31, 2009 at 6:07 pmParticipants 7Replies 8Last Activity 13 years, 10 months agoCan 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 87Example entry:
LEDs front
panelI 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…”
Bill H March 31, 2009 at 6:24 pm
Reply to: Index entries – too many page numbers at the highest level
March 31, 2009 at 6:24 pmCorrection: I'm using XMetaL 5.5!
Jill April 15, 2009 at 6:05 pm
Reply to: Index entries – too many page numbers at the highest level
April 15, 2009 at 6:05 pmI 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 term nested term (and I add the corresponding ending entry to the end topic)
Output looks like this:sample term
3-7
nested term 3-7I'm using 5.5 as well. I hope I'm not hijacking Bill H's thread! Thanks anyone for any suggestions.
JillSu-Laine Yeo May 8, 2009 at 9:08 pm
Reply to: Index entries – too many page numbers at the highest level
May 8, 2009 at 9:08 pmBill, 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-LaineJill May 8, 2009 at 10:32 pm
Reply to: Index entries – too many page numbers at the highest level
May 8, 2009 at 10:32 pmSu-Laine Yeo May 12, 2009 at 12:34 am
Reply to: Index entries – too many page numbers at the highest level
May 12, 2009 at 12:34 amHi 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 term nested 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-LaineJill May 12, 2009 at 12:57 am
Reply to: Index entries – too many page numbers at the highest level
May 12, 2009 at 12:57 amHi Su-Laine,
That worked on this end, too, hooray! Thanks again for your help, I really appreciate it. 🙂Jill
Bill H May 26, 2009 at 8:14 pm
Reply to: Index entries – too many page numbers at the highest level
May 26, 2009 at 8:14 pmHi 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.
Su-Laine Yeo June 4, 2009 at 7:06 pm
Reply to: Index entries – too many page numbers at the highest level
June 4, 2009 at 7:06 pmJust 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
-
AuthorPosts
- You must be logged in to reply to this topic.