[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

FrameMaker 7.0 and DocBook indexterm



[crossposted to docbook-apps]

A small question for someone with FM 7.0 and a minute
(well, maybe five minutes) to spare ...

I'm using FrameMaker+SGML 5.5.6 to compose an index.
The index author submit indexterms in a spreadsheet,
one indexterm per row. This get coverted into a
DocBook 2.2.1 along these lines:

<!DOCTYPE chapter PUBLIC "-//HaL and O'Reilly//DTD DocBook//EN" [
  <!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin 1//EN">
  %ISOlat1;
  <!ENTITY % ISOnum  PUBLIC "ISO 8879:1986//ENTITIES Numeric and Special
Graphic//EN">
  %ISOnum;
  <!ENTITY % ISOpub  PUBLIC "ISO 8879:1986//ENTITIES Publishing//EN">
  %ISOpub;
]>
<chapter>
  <title>junk</title>
  <para><indexterm>
      <primary sortas="primary sortas">primary</primary>
      <secondary sortas="secondary sortas">secondary</secondary>
      <tertiary sortas="tertiary sortas">tertiary</tertiary>
      <see>see</see>
    </indexterm></para>
  <para>5<indexterm>
      <primary>Befordringsudgifter</primary>
      <secondary>erhvervsmæssige befordringer</secondary>
    </indexterm></para>
  <para>149 &bull;<indexterm>
      <primary sortas="&#165;">\b</primary>
    </indexterm></para>
</chapter>


The DocBook application that comes with FrameMaker+SGML 5.5.6
converts these indexterm elements into Index markers, which
can then be used to generate an index. But the DocBook
application appears to have some shortcommings wrt. indexterm.

Before I try to mend the application, I'd like to know if
these issues are already resolved in FM 7.0:

- The generated text 'See' and 'See also' (used to prepend
  text from corresponding elements) is hardcoded into the
  application. Only good for one language.

- Both ordinary indexterms, 'See', and 'See also' indexterms
  get converted into the same marker type, 'Index'. In order
  to format proper 'See also' entries (below the entry on
  which they are based), they should get converted into a
  separate marker type.

- In the content of the 'primary', 'secondary', 'tertiary',
  'see', and 'seealso' elements, character entities do not
  get expanded/converted correctly into index marker text.

- In the 'sortas' attribute of the 'primary', 'secondary',
  'tertiary', 'see', and 'seealso' elements, character
  entities do not get expanded/converted correctly into
  index marker text.

- In the index marker, the values of 'sortas' attributes
  should get converted to a ':'-separated string inside
  square brackets _after_ the indexterm text, like this:

    primary:secondary:tertiary[primary sortas:secondary sortas:tertiary
sortas]

  But this is what happens:

    primary[primary sortas]:secondary[secondary sortas]:tertiary[tertiary
sortas]

- Even if I manage to get characters outside Latin1 into
  index markers, doing this:

  - for attributes, use a numeric character reference to
    the position in FrameMakers encoding
  - for PCDATA content, use the backslash codes for dialog
    entry

  the index marker doesn't work correctly until I manually
  open it, change a bit back and forth, and click the 'Edit'
  button.


Kind regards,
Peter Ring


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