This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
RE: Glossary in FO output: where should 'id' attributego?
- From: David Cramer <dcramer at motive dot com>
- To: "Paul A. Hoadley" <paulh at logicsquad dot net>, docbook-apps at lists dot oasis-open dot org
- Date: Sat, 08 Feb 2003 13:51:09 -0600
- Subject: RE: DOCBOOK-APPS: Glossary in FO output: where should 'id' attributego?
I'd noticed the same problem in 1.60.1. Looks like a bug was introduced in revision 1.15 of glossary.xsl. Nab 1.14 from cvs and add it to your customization layer (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/docbook/xsl/fo/glossary.xsl). I went ahead and logged it as a bug: http://sourceforge.net/tracker/index.php?func=detail&aid=683062&group_id=21935&atid=373747
David
-----Original Message-----
From: Paul A. Hoadley [mailto:paulh@logicsquad.net]
Sent: Saturday, February 08, 2003 4:10 AM
To: docbook-apps@lists.oasis-open.org
Subject: DOCBOOK-APPS: Glossary in FO output: where should 'id'
attribute go?
Hello,
I am using XSL stylesheets version 1.60.0, though the ChangeLog for
1.60.1 doesn't lead me to believe it would be different in that
version.
Following TDG, I have been placing 'id' attributes in the glossentry
elements within a glossary. This causes some peculiar rendering of
glosssee and glossseealso elements. This minimal example:
<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE article SYSTEM "/usr/local/share/xml/docbook/docbookx.dtd">
<article>
<glossary>
<glossentry id="g:foo">
<glossterm>foo</glossterm>
<glossdef>
<para>Foo bar baz.</para>
</glossdef>
</glossentry>
<glossentry id="g:text">
<glossterm>text</glossterm>
<glosssee otherterm="g:foo">foo</glosssee>
</glossentry>
</glossary>
</article>
causes the following output in the resultant PDF:
---
Glossary
foo Foo bar baz.
text See fooFoo bar baz..
---
The text within the glossdef element of the target is placed between
"foo" and the full stop. Placing 'id="g:foo"' in the glossterm
element rather than the glossentry produces the expected output. Is
this a bug with the XSL, or have I missed something obvious?
--
Paul.
mailto:paulh@logicsquad.net
mailto:paul.hoadley@student.adelaide.edu.au