Indexing problems in PDF output with XMetaL 7.0.0.111

[Anonymous]

I am indexing a book and looking at the generated index in the PDF output (Distiller and RenderX). I see the following problems:

1. The second-level entries don't always sort alphabetically.
2. Page ranges are duplicated

Here is an example that shows both problems:

SQL commands 275–432
  275–432
  ROLLBACK 380
  BEGIN 297
  DELETE 345
  PREPARE 373

The range 275-432 is repeated as a blank second-level entry, and ROLLBACK is out of alphabetical order. As far as I know I am using standard indexterm tagging so both of these problems look like bugs. Has anyone else seen this behavior?

Reply

[Derek Read]

I don't seem to be able to reproduce this. Can you provide a sample? If you don't want to post something here then it would be best to submit a case to XMetaL Support.

Reply

[bobrum]

Derek, I think the unsorted entries come into play when you add new entries an regenerate the index. I don't think you will see the problem the first time you generate it. In any case, I will create a sample zip file and send it. Thanks.

Reply

[[email protected]]

We had that issue and turned it out it was due (for us) to an extra space entered at the beginning of the secondary . For example, Applered will sort differently than red.

It's easy to accidentally add a space if you use the Insert Index Marker dialog box and enter the terms in the Index term box as “Apple,red” vs. “Apple, red”. Easy to do with multiple writers contributing topics to an index.

That was the issue for us, so we just had to remove all the spaces at the beginning of the secondary term and the sort issues went away.

As far as the page range without a secondary entry, not sure, unless there's a empty secondary , or one that just contains a space.

RPalmer

Reply

[Derek Read]

With the files that were sent to XMetaL Support we found that to be the case. The DITA OT treats spaces at the start of an indexterm as significant for PDF output and sorts them at the top. Removing the spaces and then turning off pretty printing should resolve that (unless 3rd party software like a CMS is involved, in which case it might add white-space as well).

The other issue seems to be due to the fact that the OT doesn't handle the @start and @end (indexterm range) attributes well (at least for PDF).

Reply

[Derek Read]

Out of the box I believe the pretty printing settings should not be contributing to the sorting issue (XMetaL shouldn't be inserting extra white-space into index-term elements). In order for the particular CTM settings we have set for pretty printing to come into play (adding a newline before the closing tag) I believe the CSS for elements needs to be altered so that these elements are being rendered using “display:block” (1 indexterm element per line). However, the CSS settings we ship have this set to display:inline.

So, most people should not be affected by prettying printing unless they have modified the CSS files. That doesn't mean you still cannot introduce a space yourself so you still need to watch out for that.

However, if you suspect white-space is being introduced and you didn't put it there the easiest thing to do is to turn off pretty printing.

I think I have a handle on the CTM settings we should have (even with these CSS changes) so I'll investigate that to see if we can do something for the future so that you can have pretty printing on, change CSS to display:block for and still not have white-space introduced into the content of indexterm elements.

Reply

[Author]

Posts